IndexLoading Index
Four phases, always in this order. The order is the whole point — every phase closes a set of questions so the next one does not have to keep reopening them.
Most projects go wrong in the same place: someone starts choosing colours before anyone has agreed what the screen is for. It feels productive, and it is the most expensive possible order to work in, because every structural decision afterwards has to be re-litigated against a visual that already exists.
So I go the other way. Understand the job, then draw the structure, then build it against real data, then — only then — spend time on how it feels. Each phase hands the next one a smaller, better-defined problem.
It is not a rigid methodology and there is no ceremony to it. It is just the sequence that produces the least rework, which on a fixed timeline is the same thing as producing the most product.
2 — 5 days
Before anything gets drawn, I need to know who opens this, on what device, and what they are trying to finish.
Most bad interfaces are not badly designed — they are designed for the wrong person doing the wrong thing. So this phase is mostly questions: who is the primary user, what is the one job they open this to do, and what happens when they cannot.
I also want the unglamorous constraints early. What data actually exists, what the API can return, what the deadline really is. A design that ignores those is a design that gets redrawn.
1 — 3 weeks
Figma first — structure, states, and the awkward cases. Colour is the last decision, not the first.
I start in greyscale at 390px wide. Mobile forces the hierarchy to be honest: there is no room to hide a weak layout behind whitespace, so whatever survives at phone width is usually right at every width.
Every screen gets its full set of states — empty, loading, error, one item, too many items. The states are where products actually fall apart, and drawing them is far cheaper than discovering them in code.
Colour and motion come at the end, once the structure is settled. A layout that only works in one palette is not finished.
2 — 8 weeks
Real components against real data, deployed from week one so there is always something to look at.
The token layer goes in before the first screen — colours, spacing, and type as CSS variables — so theming and consistency are decided once rather than negotiated per component.
I build against real data as early as possible. Placeholder content hides every problem that matters: the name that is too long, the empty list, the number that does not fit.
There is a live preview URL from the first week. Reviewing a deployed page beats reviewing a screenshot, and it means feedback arrives while it is still cheap to act on.
3 — 7 days
Motion, loading states, keyboard paths, and the numbers. The pass most projects skip, and the one users feel.
Motion goes in last, deliberately. Added early it hides structural problems; added last it can only clarify what is already working. Every transition has to answer a question — what changed, where did it go — and anything that answers nothing gets cut.
Then the measurements: load time on a throttled connection, layout shift, keyboard navigation, contrast, and behaviour with reduced motion turned on. These are pass or fail, not opinions.
A preview URL from week one, updated on every push. No month of silence followed by a reveal — by the time it ships you will have watched it get there.
What is included, what is not, and what a change would cost. Written before we start, so neither of us is guessing halfway through.
If something will hurt the product — a pattern that confuses, a feature that does not earn its complexity — I will say so once, clearly. Then it is your call and I build it properly.
Responsive, accessible, fast, and documented. Not a demo that needs a week of cleanup before anyone outside the team can see it.
A full front-end build in React or Next.js — design, components, data wiring, and deployment. Dashboards, platforms, and marketing surfaces.
Cross-platform React Native with Expo. One codebase for iOS and Android, with navigation, auth, and caching set up properly.
An existing product that works but does not feel right. Layout, spacing, motion, and responsiveness brought up to standard without a rewrite.