Every published product design process is a tidy arrow: discover, define, ideate, prototype, test, launch. No project has ever run like that, and pretending otherwise is why the diagram gets ignored by the third week.
What actually happens is a sequence of questions, each of which sends you backwards when the answer is bad. Here is the process described that way — as the questions, and what going backwards costs at each point.
The six questions, and what a bad answer costs
| Question | Bad answer found here costs | Bad answer found after launch costs |
|---|---|---|
| Whose problem is this? | A week | The whole product |
| Is it a problem worth money? | A week | A quarter, then a pivot |
| What is the smallest version? | Days | Months of scope |
| Does the flow make sense? | Days | Support load, forever |
| Can we build it? | Days | A rewrite mid-project |
| Does it work in the real world? | Weeks | Churn you cannot explain |
Question one is the one people skip
Whose problem is this? — and the honest answer is often “a stakeholder’s”, not a user’s.
That is not automatically fatal. Plenty of legitimate work exists because a regulator requires it or a sales team cannot close without it. But naming it correctly changes the design. A feature that exists to close deals should be designed to be demonstrable; a feature that exists because users are struggling should be designed to disappear into the workflow. Confusing the two produces something that serves neither.
Ask it out loud in the kickoff. The silence that sometimes follows is itself the finding.
Prototype at the fidelity of the question
The most common waste in the middle of the process is building a polished prototype to answer a question that a sketch would have settled.
- “Is this the right structure?” — paper, or boxes. Twenty minutes. Polish actively hurts here, because people comment on the visuals instead of the structure.
- “Does this flow make sense?” — clickable greyscale screens. Half a day.
- “Will people trust this enough to enter card details?” — full fidelity, real copy. Two days, and worth it.
- “Does this feel fast enough?” — has to be built. No prototype answers this honestly.
Matching fidelity to question is the single biggest efficiency gain available in design work, and it is almost entirely a discipline problem rather than a skill one.
Bring engineering in before you are ready
The instinct is to present a finished design. The result is a conversation that starts with “we cannot do that because of how the data is stored” — after the design is finished.
Fifteen minutes at the sketch stage, asking “is anything here expensive?”, routinely saves a week. Engineers are also, in most teams, an under-used source of ideas — they know which constraints are real and which are just habit.
What launch actually is
Not the end of the process — the point at which the answers stop being guesses. Three things belong in the plan before anything ships:
- What number would tell us this worked? Decided in advance, or every result becomes a story that confirms whatever people already believed.
- What would tell us it went wrong? Support tickets on a specific topic, drop-off at a specific step. Name it now.
- When do we look? A date in the calendar. Without it, nobody looks, and the team learns nothing from having shipped.
That third one is the one teams skip, and it is why the same mistakes repeat across projects.
Common questions
How much process does a small team need?
The six questions, asked out loud, and nothing else. Ceremony is for coordinating people who cannot talk to each other easily. Three people in one room do not need it.
What if there is no time for research?
There is always time for five people and a task. What there is no time for is a formal study — and those two get conflated to justify skipping the cheap version.
Where do design systems fit?
After the flow is settled, not before. A design system speeds up execution; it does not tell you what to build, and reaching for components early tends to shape the solution around what already exists.
How do I know when a design is done?
When every state has a screen — empty, loading, error, partial, full — and someone unfamiliar can complete the task without help. Not when it looks finished.
Leave a Reply