UX Documentation Series
Back to Writings
Episode 01

Before I Opened Figma

April 22, 2026 5 min read Vivek Singh
UX Process IBM Capstone Building in Public Product Design

Most designers open Figma before they understand the problem. I used to do that too.

This is the first post in a public documentation of my IBM UX Capstone: a real project, real deliverables, real process. No skipping steps, no showing only the polished parts. Every decision, every insight, every mistake, documented as it happens.

The Client

Sarah Chen runs ArtisanCrafts, a business that sells handcrafted goods made by independent artisans. She's been doing it through offline seasonal markets, Instagram and it worked. But she wants to grow, and that means going online.

The ask: a responsive website for both mobile and desktop. Looks authentic. Trust-building. Something that justifies the pricing and supports the artisans behind every product.

What the Brief Actually Said vs. What It Meant

I didn't just read the brief but analysed it and tried to understand more than what was explicitly stated.

Sarah said she wants the site to justify the premium pricing of her products. But if you sit with that for a moment, what she actually needs is for strangers on the internet to trust her enough to pay above-average prices for products they can't touch.

Justifying premium pricing is one of the business goals. Building trust with strangers online. That is the real design problem.

The stated needs were clear: responsive, easy to browse, easy to purchase. But the implied needs were more interesting. Users probably want to know who made the product and how. They want the story behind the craft, not just a product photo and a price tag. That's what builds trust online when you can't replicate the feeling of a physical market.

Scoping: Deciding What This Project Actually Is

Before touching any tool, I defined exactly what's in and what's out. This is the step that saves weeks of wasted work later.

In Scope
  • 4 screens for desktop + 4 for mobile
  • Full design system and style guide
  • Low-fi and hi-fi wireframes
  • Interactive prototype
  • Developer handoff setup
  • Personas and research notes
Out of Scope
  • Payment gateway and backend
  • Admin / inventory dashboard
  • User account creation
  • SEO and marketing strategy

One thing worth noting: UX research hasn't happened yet at this stage; it comes in a later module. So right now the design decisions are assumption-based. That's not a permanent constraint, it's just the sequence. The assumptions get validated later, which is actually how a lot of real projects work.

The 4 Screens I Decided On

With only 4 screens per platform, every choice has to carry weight. Here's what I landed on and why:

  • 01 Home: First impression, product browsing, immediately builds trust and signals quality
  • 02 Product Detail: Where trust is built or lost. This screen does the heaviest lifting
  • 03 Cart: Seamless path to purchase, reduce drop-offs
  • 04 Artisan Story: Not in the brief, but necessary. in the brief, but necessary. This is what makes a stranger trust a product they've never held

That fourth screen was my own call. The brief didn't ask for it. But the real problem, building trust, demanded it.

The Real Challenge

It's not about aesthetics alone. It's making a stranger feel confident enough to spend real money on something handmade, from someone they've never met, through a screen. Note: This is an assumed problem statement a better one will be stated in the Define phase later in this course.

That's the problem I'm designing for. Everything else is just execution.

Module 1 taught me something I already knew but hadn't applied with this much intention: the brief is never the whole picture. The real problem is always one layer deeper. Finding it before you open any tool is what separates a designer who solves problems from one who just makes screens.

Coming Soon: Episode 02
Empathize and Define: Learning from Competitors and Users
Competitive analysis, user interviews, empathy maps, personas, and writing a problem statement. The full research phase, documented.

If something here made you think differently about how you approach a brief, or if you have been through a similar process and did it another way, I would genuinely like to hear it. Message me at hello@uixvivek.in