Flows before screens
We map what someone is trying to achieve and the path there, then design the screens that path needs. Designing screens first is how products end up with twelve of them and no journey.
Software Development
Get the product right before you pay to build it.
Design is the cheapest place to be wrong. We turn an idea into flows, screens, and a clickable prototype you can put in front of real users, while changing your mind still costs an afternoon rather than a sprint.
Every expensive rebuild started as a design decision nobody tested.
Changing a screen in Figma costs an hour. Changing it after it is built, tested, integrated, and shipped costs a fortnight and a difficult conversation. Yet most projects rush design to reach development sooner, which reliably produces the opposite of speed.
The other failure is design that looks beautiful and cannot be built as drawn: no empty states, no error states, no idea what happens on a narrow screen or when a name is forty characters long. Engineers then invent those answers under time pressure, and the product ends up designed by accident.
We design the whole system, including the unglamorous states, and hand over something a developer can build without a single round of guessing.
What design covers here
A prototype people can actually use
Clickable and realistic enough to put in front of real users, so you learn where they hesitate before that hesitation is expensive.
The states nobody remembers
Empty, loading, error, offline, permission-denied, and too-much-content. These are most of the real experience and almost none of the average design file.
Accessibility built in from the start
Contrast, focus order, keyboard operation, and screen-reader semantics designed in rather than retrofitted, which is both cheaper and the only approach that actually works.
A design system, not a pile of screens
Reusable components with defined behaviour, so the twentieth screen is fast to design and consistent with the first.
Handover engineers do not have to interpret
Specs, tokens, spacing, and behaviour notes, including the interactions that are obvious in your head and invisible in a static file.
Everything handed over.
Listed explicitly so there is no argument later about what was in scope.
- User flows for every core journey
- High-fidelity designs across mobile and desktop breakpoints
- Clickable prototype
- Design system with reusable components and tokens
- Accessibility notes covering contrast, focus, and semantics
- Developer handover file with specs and behaviour documentation
Honest scope
Is this right for you?
We would rather lose the enquiry than take on work we are the wrong people for.
A good fit if…
- You are about to commission a build and want to de-risk it first
- Your existing product works but people get lost or drop out
- You have developers but no designer
- You need something testable with users before committing budget
Not for…
- Logo or brand identity work on its own. That is a brand studio's job, not ours
- Marketing site design disconnected from a product; plenty of specialists do that better
- Teams who want visuals without discussing user behaviour. That is decoration, and it will not fix a conversion problem
- Print or packaging design of any kind
Ways to start
Pick an entry point.
Larger engagements vary enough that a headline number would mislead, so those are quoted after a free call. We always tell you what drives the number.
Design Sprint
Turning one idea or problem area into something testable, fast.
Quoted
Priced on the number of journeys
2 weeks
- Flows for the core journey
- High-fidelity screens for that journey
- Clickable prototype
- One round of user testing with five participants
- Full design system
- Development
Product Design
Designing a complete product ahead of a full build.
Quoted
Priced on how many journeys and platforms
4-10 weeks
- All core journeys mapped and designed
- Complete design system
- Mobile and desktop breakpoints
- Accessibility documentation
- Full developer handover
Design System
Teams whose product has drifted into visual inconsistency.
Quoted
Priced on the size of your existing interface
4-6 weeks
- Audit of existing interface inconsistencies
- Token set: colour, type, spacing, elevation
- Documented component library
- Adoption guide for your team
Questions, answered.
Can you design something for our own developers to build?
Yes. A good share of our design work is handed to in-house or third-party teams. Handover includes specs, tokens, breakpoints, and written behaviour notes for interactions a static file cannot convey. We stay available during the build for the questions that inevitably surface once someone starts implementing.
Do you do user research, or just the interface?
Both, proportionate to the decision. A Design Sprint includes testing the prototype with five participants, which is usually enough to expose the serious problems. For larger engagements we run interviews and analyse existing behaviour first. We will not sell you a research programme when a week of testing would answer the question.
What does a design system actually get us?
Speed and consistency that survive staff turnover. Instead of every new screen being a fresh set of decisions, your team assembles known components with defined behaviour. It pays for itself once you are past roughly twenty screens or more than two people making interface decisions.
Start with a free conversation.
Thirty minutes, no pitch. We will tell you what we would do, what it would take, and whether you need us at all.