Founders come to this process at one of two points: either "I have an idea and roughly know who it's for," or "I have a spec, maybe even some engineering started, but no design." Both are fine starting points. What surprises most first-time founders is how much of the actual design work happens before anything looks like a real screen — and how much time that early, unglamorous work saves later. Here's how the process actually runs, end to end.
Before a single wireframe, the first real work is making sure the problem is defined precisely enough to design against. Not "we're building a marketplace for X" — that's a category, not a problem. It's: who specifically is underserved right now, what are they currently doing instead of your product (including "nothing," which is a real and common answer), and what would have to be true for them to switch. This sounds like founder-strategy work rather than design work, and in a sense it is — but design decisions made without this foundation tend to solve the wrong problem beautifully.
For NeighborSchools, this stage surfaced that the real bottleneck wasn't parents finding daycare options — it was qualified providers getting discouraged by regulatory complexity before they ever launched. That reframing changed which side of the marketplace got design priority first, and it came entirely from problem definition, before any screen existed.
Once the problem is sharp, the next step is mapping the core user journey in low fidelity — boxes, arrows, rough wireframes, nothing that looks finished. The entire point of staying ugly here is speed of iteration: it's much cheaper to realize a flow has an unnecessary step, or is missing a critical decision point, when it's a box on a whiteboard than when it's a polished screen someone's emotionally attached to.
This is also where I map every input, not just the primary happy path — what happens on a user's second visit, what happens if a step fails, what the empty state looks like before any data exists. For an MVP, you don't need every one of these fully designed, but you do need them identified, so nothing gets discovered for the first time mid-engineering-sprint.
This is the step founders most often want to skip, because it feels like it delays "real" progress. It's the opposite: five conversations walking real prospective users through the low-fidelity flow, watching where they hesitate or misunderstand, is the cheapest possible way to catch a fundamentally wrong assumption. Every hour spent here saves far more than an hour later, because the alternative is discovering the same misunderstanding after the MVP is built, tested by nobody, and already burning runway.
Validation doesn't need to be formal user research with a recruiting agency. It can be five candid conversations with people who match your target user, walking through rough screens, asking open questions, and genuinely being willing to hear that an assumption was wrong.
Only once the flow itself is validated does high-fidelity UI work start — real typography, real color, real component decisions, the layer most people think of when they picture "design." This is deliberately the last step, not the first, because polishing a flow before it's proven to work is the most common way design time gets wasted on an MVP.
This is also the point where brand identity — if it exists yet — actually gets applied to the product for the first time, rather than living only on a marketing site. Typography, color, and voice decisions made for the brand need to be tested against real, data-dense screens here: a color palette that looks elegant on a landing page can fail completely on a form with validation errors, and that's much cheaper to discover now than after engineering has built against it.
The final step is preparing files your engineering team (or engineering hire) can actually build from without a dozen follow-up questions: consistent naming, real content instead of lorem ipsum, states for loading/empty/error documented, and spacing/sizing that reflects real constraints rather than arbitrary pixel values. An MVP spec that looks great in a deck but leaves engineering guessing at edge cases will cost you the time you thought you saved.
A good gut check for whether files are actually handoff-ready: hand them to an engineer who wasn't in any of the earlier conversations and see how many questions come back. Zero questions usually means the documentation is genuinely thorough. A long list of questions about what happens when a field is empty, or what a button does on a second click, means the spec still has the earlier stages' thinking in the designer's head instead of on the page.
If you're sitting at either starting point — just an idea, or a spec with no design behind it yet — I'd rather talk through where you actually are before proposing a process. Get in touch and let's figure out the fastest honest path to something buildable.
Disconnected brand and product design creates a fractured user experience. The case for having both aligned under one design system from the start.
Read post
A practical, non-hype take on adding AI to your product — matching AI to a real user problem, designing for its imperfection, and avoiding the checkbox-feature trap.
Read post
Most design systems die quietly in a Figma file nobody opens. Lessons from 30+ product launches on what makes a system get adopted by engineering instead of ignored.
Read post
