Fewer things on the screen
Most interfaces improve by subtraction. We work out what the screen is genuinely for and cut what is competing with it.
Most Design Files Are Not Finished
They look finished. They present beautifully. Then a developer opens them and starts making decisions the designer never made: what this looks like with no data, with forty items, with a name that runs to three lines. The design was a picture of the best case, and the product ships as something else.
-
Only the perfect screen exists
Six neat items, ideal names, everything loaded. No empty state, no error, no spinner, no user with a hundred entries.
Missing states -
It was drawn, not decided
Beautiful screens with no flow behind them. Nobody can say what happens after the button, or how a user got here.
No journey -
Every screen is slightly different
Four button styles, five greys, spacing that never repeats. No system, so consistency depends on whoever is building today.
No system -
Nobody checked it can be used
Grey on grey, invisible focus, tap targets too small, a flow that cannot be completed by keyboard at all.
Inaccessible
A design is not done when it looks right.
It is done when someone can build it without guessing.
We design and build software, so we have been on the receiving end of a great many handovers. That is the whole reason our files are shaped the way they are.
Decisions First, Pixels Second
Good interface design is mostly the work of removing choices: deciding what this screen is for, what comes off it, and what happens next. The visual layer is the last part, and it is much easier once everything underneath has been settled.
Flows before screens
How someone arrives, what they are trying to finish, and where they go next, mapped before any layout is drawn.
A system, not a pile of screens
Components and tokens, so the tenth screen costs a fraction of the first and the hundredth still matches.
Handover that answers questions
Specified closely enough that a developer who has never spoken to us can build it correctly.
What You Actually Receive
Not a slide deck of mockups. A set of files a development team can build from, and that your own designers can extend after we are gone.
01
Understanding
Who this is for, and what they are actually trying to do.
Research- User interviews and stakeholder sessions
- Personas grounded in real conversations
- Review of your current product's drop-off points
- Competitor and convention review
- Jobs, tasks and priorities
- The constraints design has to respect
02
Structure
The shape of the product, before anything is styled.
Architecture- Information architecture and navigation
- User flows for every key journey
- Low-fidelity wireframes
- Content hierarchy per screen
- Interactive prototype for the main paths
- Early usability testing on the prototype
03
Interface
The visual layer, applied to a structure that already works.
Design- High-fidelity screens at real breakpoints
- Colour, typography and spacing scales
- Iconography and imagery direction
- Motion and transition guidance
- Dark mode where it is wanted
- Accessibility built into every screen
04
Handover
The part that decides whether the build matches the design.
Build-ready- Component library with variants and states
- Design tokens ready for code
- Empty, loading, error and no-permission states
- Long text, long lists and overflow behaviour
- Written interaction and validation specs
- A walkthrough with your developers
How A Design Project Runs
Cheap decisions first, expensive ones last. Everything gets tested at the point where changing it still costs almost nothing.
-
01
Week 1
Understand
Conversations with you and with the people who will use it, plus a hard look at what already exists and where users currently give up.
-
02
Week 1
Map the flows
Every journey drawn end to end before a single screen is styled. Most of the real design arguments happen here, which is exactly where they are cheapest.
-
03
Week 2
Wireframe & prototype
Grey-box screens wired into something clickable, so you can walk the journey rather than imagining it from a static image.
-
04
Early
Test the prototype
A few real people attempting real tasks. Watching someone hesitate for four seconds tells you more than any amount of internal debate.
-
05
Ongoing
Visual design & system
The interface layer, built as components and tokens from the start so consistency is structural rather than something anyone has to police.
-
06
Handover
Specify & support
States, edge cases and behaviour documented, a walkthrough with the developers, and we stay reachable for the questions that always come up mid-build.
Tools We Use
Figma for almost everything, because it is what your developers and any future designer will already have. The file is yours, editable, with nothing locked behind our account.
Design
Prototyping
Research & Testing
Handover
Designers Who Have Had To Build It Afterwards
Our design work sits next to our engineering work, and that shows up in the files. We do not draw interactions we know are unreasonable to implement, and we do not leave the awkward states for somebody else to invent.
10+ years
Hands-on experience per person, across agencies, product companies and enterprises. No juniors learning on your budget.
Design and build
The same studio does the development, so a design can go straight into components instead of into a document that drifts.
Built, shipped, maintained
We have lived with our own interfaces long after launch, which is where you learn which clever idea becomes a support ticket. See how we work.
The files are yours
Editable source, full ownership, and a design system your team or any future designer can pick up without asking us for access.
Your idea stays yours
We will sign a mutual Non-Disclosure Agreement any time you want one, at no cost. You can read the exact document we use before you ask for it.
Frequently Asked Questions
Do you design for products you are not building?
Yes, and a good share of our design work is handed to another team to build. That is exactly why the handover is specified as carefully as it is: spacing, states, breakpoints, behaviour and edge cases documented, so the developers are not guessing at intent. We are also happy to answer their questions during the build.
How much research do we really need?
Less than agencies usually sell, more than most teams do. For a product with existing users, a handful of interviews and a look at where people currently drop off will tell you most of what matters. For something new, a few conversations with people who have the problem beats a long study. We scope research to the decisions it will actually change.
Can you redesign our existing product?
Yes, and redesigns need more care than new work because you already have users with habits. We look at what is genuinely broken against what is merely dated, and we will tell you when a full visual overhaul is the expensive way to fix three specific flows. Rolling changes out in stages is usually kinder to everyone.
What do developers actually receive?
A Figma file with components, tokens for colour, type and spacing, every screen at its real breakpoints, and each state drawn: empty, loading, error, partial data, long text and permission-restricted views. Plus a written spec for interaction behaviour. The states are the part most handovers miss, and they are where build time gets lost.
Do you build the frontend as well?
We can. When we design and build, the design system becomes real components rather than a document that slowly diverges from the code, and the whole thing stays consistent. If you already have a frontend team, we work to their stack and their conventions instead.
Is accessibility included or extra?
Included. Contrast, focus states, target sizes, keyboard paths and screen reader labelling are part of designing a screen, not a separate audit afterwards. Retrofitting accessibility onto finished designs is far more expensive than doing it as you go, and in many markets it is also a legal requirement.
- Free first call, no obligation
- An honest read on how much design you actually need
- Mutual NDA on request, before the first call
- Editable source files, owned by you