Process · four stages
The working build.
Most design engagements end with a file and a meeting. This one ends with a URL your team can open, a repository they can run, and a Figma library that matches both.
01
Scope
Two days, free
We spend thirty minutes on the problem. I go away, look at the surface myself, and come back with what I think is actually wrong. If your problem is not one I can solve well, this is where I say so.
What this stage produces
- A written scope with a fixed price and a delivery date
- An honest read on whether the thing you asked for is the thing you need
02
Spec
Week one
Research sized to the engagement, then decisions written down. Your data, your support tickets, your users where they exist. Every screen-level decision gets traced to a participant, a metric, or a principle.
What this stage produces
- A findings document, prioritized by impact against engineering effort
- Flows and states, including the empty, loading and error cases
- The list of things I decided not to do, and why
03
Build
Weeks two to four
I design and build at the same time, in code, working in Claude Code and Figma together. You see a running URL from the first week, so feedback lands on something you can click.
What this stage produces
- A working front-end, deployed somewhere you can open on your phone
- Tokens and components with every state built
- A weekly call against the live build, never against a slide
04
Handover
Final week
Your engineers get a repository they can run and read. Your designers get a Figma library bound to the same tokens, so the two do not drift apart the week after I leave.
What this stage produces
- The repository, with a README written for someone who has never seen it
- Storybook, so nobody rebuilds a component that already exists
- A Figma library matching the code
- Two weeks of corrections included after handover
Three rules the process is built on
Decisions get traced.
Every screen-level decision should trace to a participant, a metric, or a principle. If it traces to none of those it is an opinion, and opinions do not survive a six-engineer team.
The build is the deliverable.
A Figma file transfers a picture of a decision. Running code transfers the decision itself, along with all the states nobody remembered to draw.
Untested is said out loud.
Where a claim has been tested I give you the number and the sample. Where it has not, I say that plainly rather than dressing an opinion up as a finding.
Three client slots this quarter
Stage one is two days and costs nothing. You get a scope, a price, and an honest read on whether I am the right person.