Most designers open Figma before they understand the problem. It’s the single biggest mistake I see in product design — jumping into the tool because it feels like progress when what you’re actually doing is building confidence in the wrong direction. The screens look good. The problem hasn’t been solved yet.
When a client sends over a PRD or a brief, I read it once and then schedule a call to question it. Not to be difficult — to be useful. Clients think they know what they want to build. My job is to figure out what they actually need, which is almost always different. The questions I always ask: who is the primary user, and is that who you’re designing for or who you’re selling to? What does success look like in six months — not in features shipped, but in behavior changed? What’s the one thing this product has to do well, the thing that justifies its existence? And what have you already tried? That last question is the most revealing. The attempts that failed tell you more than the wish list ever will.
The brief almost never survives that conversation intact. New constraints surface. The actual problem gets sharper. Sometimes the product changes shape entirely before design has even come up. That’s not a detour — that’s the work.
Before I open any design tool, I spend time understanding. Not formal UX research with forty-page deliverables — the practical kind. I look at competitors not to copy them but to understand the conventions users already know. If you design against those conventions without a strong reason, you’re making users work harder for nothing. I identify the three to five core jobs the product needs to do — the things a user can’t accomplish without it. Then I map the critical flows on paper. Not wireframes yet. Just paths. This is where most of the real design thinking happens, before any pixel gets placed.
The clarity you get from this phase is what makes everything after it faster. When I know what the product has to do and how users will move through it, decisions become obvious instead of arbitrary.
I start in low fidelity deliberately. Wireframes or rough flows that force decisions about structure and logic before anyone gets attached to visual details. When founders see color and type and spacing, they respond to aesthetics. When they see boxes and labels, they respond to decisions. That’s the conversation I want to have early.
Founders sometimes push back on this. They want to see something polished — something they can show investors or post online. I understand the impulse. But I explain it this way: polished screens built on wrong structure means doing the whole thing again. Low fidelity alignment now means the high fidelity work builds on a foundation that’s already been stress-tested. Most founders who’ve been burned by the other approach don’t need much convincing.
By the time I open Figma, most of the hard thinking is done. The flows are mapped, the structure is agreed on, the core jobs are defined. What I’m solving for in the tool isn’t what the product should do — that’s been decided. It’s how it should feel to do it.
I build components from day one, not because I’m optimizing for handoff, but because designing in a system forces consistency. It also makes exceptions visible, and exceptions usually mean the underlying logic needs another look. The first screens I design are never the hero screens — not the dashboard that ends up in the pitch deck. I start with the hard ones: empty states, error states, edge cases. What does the product look like when there’s no data yet? When something fails? When a user lands somewhere they weren’t expecting? Those screens reveal the actual complexity of the product. Design the happy path first and you find out too late that the product is broken in every other state.
I stay involved through development. Reviewing builds in real time, answering engineer questions fast, making calls on what to cut when something is too complex to ship on schedule. The designer who hands over a Figma file and disappears isn’t doing product design — they’re doing illustration. Good collaboration with engineers means being present when decisions have to be made, and making them quickly enough that the build doesn’t stall. The product that gets shipped is always a negotiation between what was designed and what was possible. Being part of that negotiation is the job.
The designers who consistently ship great products aren’t necessarily the most creative people in the room. They’re the most disciplined about doing things in the right order. Talent gets you the ideas. Process is what gets the ideas built. Opening Figma is easy. Understanding the problem first — that’s the hard part, and it’s the only part that matters.
