Understand the job the product does
Who uses it, what they are trying to finish, and where they currently give up. We would rather spend two days on this than redesign a flow that was solving the wrong problem beautifully.
Interface and experience design, from first flows through to a design system your team can build on.
Interface design that holds up once it is built. We work in flows and states rather than pretty screens, and we hand over a system — tokens, components, rules — so the tenth screen looks like the first without us in the room.
What happens after you say yes, in order. Every step produces something you can see rather than a status update.
Who uses it, what they are trying to finish, and where they currently give up. We would rather spend two days on this than redesign a flow that was solving the wrong problem beautifully.
Information architecture and user flows first, as diagrams. Cheap to change here and expensive to change once it is in code — most of what looks like a visual problem later turns out to have been a structural decision made early.
Every screen has an empty state, a loading state, an error state and a version where the user lacks permission. Designing only the populated happy path is the single most common reason developers end up inventing interface decisions at build time.
Tokens for colour, type, spacing and radius; components with their variants and rules for when to use which. This is what makes the tenth screen look like the first without us in the room, and what lets your developers move quickly without asking.
Interactive prototypes for the flows that carry real risk — signup, checkout, anything with money or data loss in it. Testing five people on the two flows that matter beats testing nobody on all of them.
Specifications developers can build from, and we stay available while they do. Handover as a one-way document is how design intent quietly drifts; the questions that come up in week three are the ones worth answering.
We choose per project rather than fitting every problem to the same tools. These are what we work across most.
If you already have a design system, we work inside it and extend it rather than replacing it with our own preferences. If you have a component library your developers build with, the design is delivered against those components so nothing has to be reinvented in code. Where the existing system is genuinely holding the product back we will show you specifically where, not simply propose starting again.
Projects where ui design was part of the engagement.
Tell us what you are trying to build and we will scope it with you.