Design before code: why we start with screens
Code is the most expensive place to discover a misunderstanding. Why we start every project with screens people can click.
The short answer
The most expensive place to discover that a business and a builder imagined different things is in code, after it has been written. The cheapest is on a screen that took an hour to draw. That is the whole argument for designing before coding, and it is why every software project we run starts with screens people can click. The design phase produces clickable prototypes of the main flows, tested with the people who will use them, and the component and token set the build will reuse. Skipping it does not save the design work; it moves it into code, where each iteration costs days instead of hours and every misunderstanding is discovered by a developer instead of a user.
What the design phase produces
| Output | What it is | What it does for the build |
|---|---|---|
| Flows | The paths users take to complete each task, from the user stories | Developers build paths, not isolated screens |
| Clickable prototype | The main flows as linked screens, testable on a phone | Misunderstandings surface before code exists |
| Tested findings | What users hesitated on, misread or could not complete, and the fixes | The build starts from screens that worked for real people |
| Component set | The buttons, forms, cards, tables and layouts, defined once | Consistency, speed, accessibility built in |
| Tokens | Colours, spacing, type, radii, in configuration | One source of truth for the look |
| Edge and empty states | What each screen shows when there is no data, an error, a long list, a slow connection | The states developers otherwise invent under time pressure |
| Content | The actual words: labels, errors, instructions | No placeholder text shipping to production |
Why it shortens the build
- Developers build from agreed screens instead of interpreting text, which removes a whole category of rework.
- Changes happen in the prototype, in hours, rather than in code, in days.
- Components are defined once and reused, so the twentieth screen is faster than the second.
- Edge and empty states are designed, not improvised, so the last week of the build is not spent on them.
- Content exists, so nothing ships with placeholder text.
How the phase runs
From the user stories, the main flows are sketched, then designed as screens with the component set, then linked into a prototype. The people who will use the software are given tasks and watched. Findings change the screens; the cycle repeats until the tasks are completed without help. Technical spikes run in parallel for anything risky. The build starts with a prototype as the reference, the components as the kit and the findings as the reasons.
What this means for you
Expect a software project to begin with screens you can click on your phone, tested with your own people, before code is written. Use that phase to change your mind freely; it is the last time doing so is cheap. The build that follows is faster, calmer and closer to what you wanted, because the discovering happened where it belonged.
Frequently asked questions
Does designing first not add weeks to the project?
It adds a short phase at the start and removes a longer one from the middle. Projects that go straight to code spend their weeks rebuilding screens as misunderstandings surface. Projects that design first build once from agreed screens. In our experience the total is shorter, and the part that is longer is the part where changes are cheap.
What if we do not know what we want until we see it working?
That is exactly the argument for prototypes: they let you see it, click it and change your mind in hours, before it works for real. The screens are as close to "seeing it" as you can get without paying for code, and most of what people learn from working software they learn just as well from a prototype they can tap through.
Is this only for apps with a lot of screens?
It matters for anything a person will use. Even a small internal tool has flows, states and edge cases that are cheaper to get right on a screen than in code. The phase scales with the project: a day for a small tool, weeks for a large platform. It is never zero.