UI and UX design that survives contact with engineering.
Design work delivered as decisions and components your developers can build from, not as screens that look finished and are not.
Building and running software since 2007Components delivered in the form your team already uses
States in the handover
- Default
- Empty
- Error
- Loading
- Overflow
- By role
Signed off, and engineering still has five questions before it can start.
Three ways a design project produces work instead of removing it.
Design is the wrong first step when the product decision itself is unsettled. Designing an interface for a process still being argued about encodes the argument.
The handover is a picture
Screens are approved, then engineering asks what happens on error, on empty, on slow, and the answers do not exist yet.
Every screen is bespoke
No shared components, so the tenth screen costs as much as the first and the product drifts visually as it grows.
It was never tested against the real task
The design suits a demo. The person doing the job fifty times a day needs a different thing entirely.
What we take on.
Six kinds of work, each named by the artefact it leaves behind rather than by the activity that produces it.
Product and interface design
Screens designed against the task, including the states that only appear once real data arrives.
Design systems and components
A shared set your developers build from, so the tenth screen costs less than the first.
Discovery and prototyping
Testing a direction before it is built, which is the cheapest point at which to be wrong.
Usability work on what exists
Where the product works and people avoid it, which is a different problem from a redesign.
Design-to-build handover
Specifications, states and behaviour written so engineering does not have to guess.
- Focus
Accessibility as build quality
Semantic structure, keyboard operation and readable contrast, tested rather than asserted.
Where the work is really about building the product rather than designing it, that sits with our software engineering practice.
What a design handover has to contain before engineering can build it.
Most delay after a design is approved comes from questions the design did not answer. These six recur, and are worth checking against any handover.
What does empty look like
The first-run and no-data state designed, not implied
Without it. Engineering invents it, and it is the state most new users see first.
What does wrong look like
Error and validation states per field, with the wording
Without it. Generic messages that name a problem without a fix.
What does slow look like
Loading and partial states for anything that waits on a system
Without it. A frozen interface that users interpret as broken.
What does too much look like
Long text, long lists and large numbers shown at realistic volume
Without it. Layouts that hold in the design and break in production.
Who sees what
Screens per role, not one screen with parts hidden
Without it. Permissions retrofitted into a finished interface, which is expensive.
What is reusable
Named components with their variants, not one-off screens
Without it. Visual drift, and a rising cost per screen as the product grows.
We answer these six as part of the work rather than after it. They are also a fair test of a design you already have.
How a design engagement runs.
The component set is built as the screens emerge, rather than designing screens and extracting a system afterwards.
Watch the task before drawing anything
Including the workaround people currently use, which is usually where the real requirement is.
Agree the six handover questions up front
So they are answered as design decisions rather than as engineering guesses.
Prototype the riskiest flow first
The one where being wrong costs most, tested before the rest is drawn.
Build the component set as the screens emerge
Rather than designing screens and extracting a system afterwards.
Review with the engineers who will build it
Early and repeatedly, because a design nobody can build is not finished.
Hand over states and behaviour, not just screens
Specification alongside the visuals, so the build does not stall on interpretation.
Engineers review before sign-off. An approved design nobody can build is a delay dressed as progress.
Closest available evidence, not equivalent.
We have no published design case study with a measured outcome. The engagements below involved interface work, and both published a result, but neither was measured as a design engagement.
- Fleet operations
Milo
A driver-facing interface where the task was performed repeatedly under time pressure.
Read the case study - Beauty and personal care
Conscious Chemist
A customer-facing product experience with a published response-time measure.
Read the case study
Labelled closest available, not equivalent. Neither result is attributable to design work specifically, and we are not going to present them as though it were.
Where this work usually starts.
Situations rather than industries. We hold no sector-specific design evidence and will not imply otherwise.
An operations tool people avoid
Where a system exists, works, and the team routes around it.
A product about to add a second team
Where the absence of a component set is about to become expensive.
A build stalled on unanswered states
Where engineering is waiting on decisions the design did not make.
A product that grew visually inconsistent
Where ten years of screens no longer look like one product.
How design work is judged, other than by whether people like it.
Design is the easiest work to review by preference and the hardest to review by evidence. These four make a review objective without turning it into a research project.
Task completion on the main path
- How it is taken
- A handful of real users attempting the actual task
- What it tells you
- Whether the design works, separately from whether it is admired.
Time on the repeated task
- How it is taken
- Measured on the thing done fifty times a day, not the thing done once
- What it tells you
- Where the daily cost sits, which demos never reveal.
Support contacts about the interface
- How it is taken
- Counted before and after, by type
- What it tells you
- Whether confusion moved or simply changed shape.
Component reuse rate
- How it is taken
- Share of new screens built from existing components
- What it tells you
- Whether the system is actually reducing the cost per screen.
We agree which of these matter before the work starts, because a design judged only in a review meeting is judged on taste.
What you have when the work ends.
Including the direction that was tried and dropped, which is often the more useful record.
The component set, in the tool your team uses
Named components with their variants, not a folder of screens.
The six handover questions, answered
Empty, error, loading, overflow, roles and reuse, written down per screen.
Design decisions with their reasons
So a later change is deliberate rather than an accident of a new designer's preference.
Whatever was tested, and what it showed
Including the direction that was tried and dropped, which is often the more useful record.
A written list of what was not designed
Deferred screens and states with the reason, so the next decision starts from the record.
Show us the screen your team complains about.
There is usually one. Describe the task people do most often and where it breaks, and we will tell you whether the answer is a redesign, a component set, or better handover.
What teams ask before they start.
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.