Wireframe, prototype, design system, build. Here is what actually happens between a brief and a front end, and which step people skip.
Front-end work looks linear on a proposal and never is. This is the flow we actually run, and the step teams most often try to skip.
1. Structure before surface
We start with the content and the hierarchy — what has to be on the page, in what order, and what a visitor is trying to do. Colour and type come later. Getting this wrong is expensive; getting the colour wrong is an afternoon.
2. Low-fidelity wireframes
Deliberately ugly, because ugly invites criticism. A polished mock-up gets approved out of politeness; a grey box gets argued with, which is the point.
3. A design system, not a set of pages
This is the step that gets skipped. Designing twelve individual screens produces twelve inconsistent screens and a front end nobody can extend. Designing the components — button, field, card, table — produces a system that covers the thirteenth screen you had not thought of.
4. Prototype the risky flow
One clickable path through the hardest journey, tested with five people. Five is enough to find the problems that matter and cheap enough to do before the build.
5. Build against the system
If the design system is real, the build is assembly. If it is not, every screen becomes a negotiation and the front end drifts within a month.
The whole flow takes three to five weeks for a mid-sized product. Skipping step three saves about a week and costs considerably more than that later.
