ServicesUX
Decided in Figma,not in review
Flows · wireframes · component library
Flows and screens agreed before anyone writes code, in a file a developer can build straight from.
Best whenYou know what it should do, not yet what it should look like.
- Starts with
- Flows, not screens
- Delivers
- A buildable file
- States
- All of them, drawn
- Checked
- WCAG 2.2 contrast
Four steps
Design that ends at a pretty screenshot gets argued about in code review. Ours ends at a component library a developer can build from without asking what the empty state looks like.
01
Flows before pixels
What the user is trying to finish, and the shortest honest path to it. Settled on a whiteboard while it is still cheap to change.
02
Wireframes for structure
Grey boxes, real copy. Hierarchy and content length get decided here, where nobody is distracted by a colour or a corner radius.
03
A component library
One Figma file with real components and tokens, so a change to a button changes every button — and the developer builds the same set in code.
04
Every state, and the handover
Empty, loading, error, and too much content. Contrast and type sizes checked against WCAG 2.2, then a walkthrough with whoever is building it.
What lands in your accounts
The file is yours, editable, with the library intact. If we build it too, this is the same file the front end gets scoped from.
- User flows and wireframes settled before any visual design
- A Figma file with a real component library, not a pile of frames
- Every state drawn — empty, loading, error, too much content
- Contrast and type sizes checked against WCAG before handover
PricingPriced from the written scope — one figure, agreed before code. No hourly billing, no change-request desk.
The screens nobody designs
A design file usually holds the screen on the day everything went right. These four are where products actually feel broken, and every one of them is drawn before handover — a developer should never have to invent one at build time.
Empty
First run, nothing created yet. The most important screen in the product and the one most often skipped: it either teaches the next action or it reads as a bug.
Loading
What holds the layout while the data is in flight. Skeletons where the shape is known, a spinner only where it is not — so the page does not jump when the content lands.
Error
What broke, whether the work was lost, and what to press. An error that only apologises sends the user to support.
Too much
A name three times longer than the mock-up, forty rows instead of four. Drawn at the size real data arrives in, not the size that fits.
Next step
Tell us what
you need built
Send the idea in whatever shape it is in — a document, a sketch, or two sentences. You get a written scope and a fixed figure back before anything is committed to.