How a project runs
The same three steps whether it is a marketing site or the first version of a product.
Understand the problem
What the product does, who it is for and the one thing you need someone to do. Design decisions get much easier once that is written down.
Structure, then surface
Layout and flow settled first, visual design after. Moving a box in a wireframe costs nothing, moving it in a finished screen costs a day.
Handed over ready to build
Components, states and spacing defined in one Figma file, so the person building it is not guessing at what you meant.
What usually goes wrong
It looks good, and still nobody signs up.
Pretty is not the same as clear. I design around the one action you need from a visitor, so every screen is pushing towards it rather than just sitting there looking tidy.
Every screen looks like a different product.
That is what happens when screens get designed one at a time. A design system settled early means colours, spacing and components stay consistent as the product grows.
The design falls apart the moment it gets built.
Usually because only the happy path was drawn. Empty, loading, error and long-content states get designed too, so a developer is never inventing them on the fly.
Rounds of feedback that never quite end.
Reviews happen at each stage rather than all at the end, so decisions get made while they are still cheap to change.
Designed to be built
A design is only finished when someone can build it without guessing. Because I build as well as design, that is the standard every file gets held to.
- One design system, not a pile of one-off screens
- Every state designed, not just the happy path
- Figma files a developer can actually navigate
- Drawn by the person who can build it too