Most design handovers are a set of screens. Approved, attractive, and silent on everything the build actually needs: what the list looks like when it is empty, what the error message says, what the button does while it is loading, what happens at 380 pixels wide.
So the developer invents it. Twenty small decisions get made under time pressure by someone who was not in the research, and the built product drifts away from the thing that was signed off.
The second failure is designing for the demo. Screens that look excellent with three tidy rows of data and fall apart with forty rows, long names, missing images and a user whose job title runs to nine words.
Then a year passes and there is no system. Every new feature gets designed from scratch, buttons multiply, and nobody can say which of the four greys is the correct one.
Sound familiar?
The design covers the happy path and nothing else.
Developers are guessing at spacing, states and breakpoints.
Four shades of grey in production and no rule for which is which.
Nothing was tested with a real user before it was built.
The design file and the live product diverged months ago.
Every new screen restarts the argument about how things should look.
Interviews, a competitive review and a look at what your analytics say people currently do. Enough to design against evidence instead of opinion, without turning into a research project.
Structure agreed in grey boxes, while changing it still costs an hour. Visual design starts after this is signed off, not alongside it.
Hover, focus, active, disabled, loading, empty, error, and the version where the content is twice as long as anyone expected.
Mobile, tablet and desktop each designed, not one desktop layout scaled down and hoped for.
On projects where a system is in scope, colour, type, spacing and components are delivered as named, reusable definitions that map directly to CSS variables, so your developers implement each one once.
Clickable enough to put in front of three users and learn something, before anyone writes code against it.
Most design rework comes from agreeing the visuals before agreeing the structure. Wireframes are deliberately plain so the conversation stays on what goes where.
Who uses it, what for, and where they currently get stuck. Analytics, support tickets and three to five interviews.
Output: a findings note and the problems worth solving.
Task flows, then grey-box layouts for every screen, reviewed and signed off before any colour is applied.
Output: approved wireframes and a screen inventory.
Interface design applied to the approved structure, assembled from components rather than drawn as one-off screens.
Output: designs for every screen and state.
A clickable prototype tested with three users, then a handover session with the developers and a written spec for what the file cannot show.
Output: the design file, tokens and dev notes.
Tooling matters less here than discipline, but the choices below are the ones that keep a design and a codebase from drifting apart.
Figma
One source of truth, with components and variables so a change propagates instead of being repeated across forty frames. Developers inspect it directly.
Figma variables and tokens
Colour, spacing and type as named values that map onto CSS variables, which is what keeps the built product and the design in step six months later.
Maze
Unmoderated testing on the prototype. Even three participants surfaces most of the serious usability problems, and surfaces them before anything is built.
Storybook
Where the system lives once it is code: every component in every state, reviewable in isolation by designer and developer together.
Lucide and Phosphor
Open icon sets that are consistent and complete, which avoids the mid-project scramble when a needed icon does not exist in the set you picked.
PostHog and Hotjar
Session recordings and heatmaps on the live product, so the next design round starts from behaviour rather than from what the team remembers.
Not fixed to these
This is what we reach for by default, not a limit. If your team works in Sketch, Adobe XD or Penpot, or your developers want tokens in a specific format, we deliver into that. The system matters more than the tool it was drawn in.
Design is scoped by unique screens rather than pages. A list, its detail view and its empty state are one design problem, not three.
| Engagement | Typical timeline | Best for |
|---|---|---|
| Audit of an existing product | 1 – 2 weeks | Deciding what to fix before committing to a redesign |
| Flows and wireframes only | 2 – 4 weeks | Teams with their own visual designer or brand |
| Full interface design, 10 – 20 screens | 4 – 8 weeks | A new product, or a redesign of an existing one |
| Design system | 3 – 6 weeks | Several products, or a team that keeps re-deciding |
| Ongoing design support | Ongoing | A product shipping new features every month |
Research and usability testing are included in the timelines above. Illustration, motion design and photography are quoted separately. If you already have a brand, we design inside it rather than charging you for a new one.
Every project is priced in writing after a scoping call. You get a fixed number, with what is included and what is not, so there is nothing to negotiate later.
Tell us what you need built and we will send a scope and a price. The reply comes from the person who would run the project.
Get a quote →This page describes how we prefer to work, not a fixed contract. Deliverables, stages and timelines vary with the size and shape of the project, and some of what is described here will not apply to yours. The written scope you receive after the scoping call is the version that counts. How we engage →
You probably know them better than we will. Research is short in that case: your analytics, your support tickets, and a conversation with whoever deals with customers daily. What it reliably catches is the gap between what a team believes users do and what the recordings show they do, and that gap is almost always there.
Yes, and most of our work does. Brand guidelines rarely cover what an interface needs though: focus rings, error styling, table density, disabled states. We extend the brand into those rather than inventing something parallel, and document what we added so it stays consistent.
A Figma file with components and variables, a written spec for anything the file cannot express, the icon set, exported assets, and a handover call. If we are building it too, the tokens go straight into code rather than being transcribed.
Two per stage, which is enough when the previous stage was signed off. Projects that run to five rounds are almost always projects where the structure was never agreed, so the visual reviews keep absorbing structural arguments.
On the prototype, before the build, with around three participants. Recruiting is straightforward for consumer products and harder for narrow B2B, where we sometimes test with your own customer-facing staff instead. That is less ideal and still far better than nothing.
That is fine, and we will tell you if the screens around it make the exercise pointless. A checkout step redesigned in isolation from the cart before it usually moves no numbers at all.
Every enquiry gets a reply within one working day, from the person who would run your project.