Design is the cheap place to be wrong
Changing a wireframe takes minutes. Changing a prototype takes an hour. Changing a shipped feature takes a sprint, a migration and an apology. The whole point of a design process is to make mistakes while they are still cheap.
Each stage below has a concrete output. If a stage ends and you have nothing to look at, something has gone wrong.
1. Discovery — what are we building, and for whom?
What happens: conversations with the people who will use the product, a look at how they solve the problem today, and a review of what competitors do.
What you get: a short document naming the users, the jobs they are trying to get done, and what success looks like. One or two pages. If it is forty, nobody will read it.
2. User flows — how does someone get from A to B?
What happens: every key task is mapped as a sequence of steps, before any screens exist.
What you get: flow diagrams. This is where you discover that "sign up" is actually nine steps, and decide which four can go.
3. Wireframes — what is on each screen?
What happens: low-fidelity layouts in grey boxes. No colour, no brand, no real copy.
What you get: the structure of every important screen. The lack of polish is deliberate: it keeps feedback on what is here and in what order, not on the shade of blue.
4. Visual design and prototype — how does it look and feel?
What happens: the brand, type, colour and components are applied, and the screens are linked into something you can click through.
What you get: a prototype that runs on a real phone or browser. It should be good enough that someone unfamiliar with the project believes it is the product.
5. Usability testing — does it actually work?
What happens: a handful of real users are given tasks and watched, without help.
What you get: a list of the places people got stuck. A small number of sessions is enough to surface the big problems — and there are always some.
6. Handoff — can it be built as designed?
What happens: components, spacing, states and edge cases are documented.
What you get: a design system and specifications — empty states, error states, loading states, long names, small screens. The unglamorous screens are the ones that get improvised during build if nobody designed them.
Where the time comes back
Teams sometimes skip straight to stage four because it feels faster. It is, for about three weeks. Then the questions start — what happens when this list is empty? where does this button go? — and they are answered in code, by whoever happens to be writing it.
A design process moves those decisions to the front, where changing your mind is free. It is also why a design system pays for itself: each new screen starts from decisions already made.
This is the process behind our UI/UX design work, and because the same team builds what it designs, stage six is usually a conversation rather than a document.
Working on something like this? See how we approach UI/UX design.