Design the product before you engineer it.
An interface is not a coat of paint on a working system. It is the decisions about what the product does, in what order, and what it deliberately refuses to do, and those decisions are far cheaper to make in a design file than in a schema migration.
We design flows first and screens second: what a person is trying to get done, the shortest honest path to it, and the states that path passes through when things go wrong. Then the high-fidelity interface, an interactive prototype, and a design system that keeps the fiftieth screen consistent with the first.
Because we also build, the handoff is written by people who have had to receive one. Tokens, component states, empty and error cases, and the motion and behaviour that a flat screen cannot describe.
What you get
UX flows, wireframes, high-fidelity UI, interactive prototype, design system, design-to-dev handoff.
How it runs
- 01
Understand
The job the product is hired to do, who is hiring it, and what success looks like for them. Existing analytics and support tickets if you have them, because real usage beats a persona document.
- 02
Structure
The flows, at low fidelity and at speed. This is the cheapest stage to be wrong in, so it is the stage where we argue.
- 03
Design
High-fidelity interface with a system underneath it: type, colour, spacing, and components defined once and used everywhere, not redrawn per screen.
- 04
Prototype
An interactive prototype you can put in front of real people before anything is engineered. What they do with it is the last cheap correction available.
- 05
Hand over
Handoff for implementation: tokens, states, edge cases, motion, and a walkthrough with the engineers who will build it.
This is for you if
- A product going into build that has not been designed yet.
- A working product whose interface has grown by accretion and now contradicts itself.
- A team without a design system, where every new screen restarts an old argument.
This is not for you if
- You want a set of screens delivered without any decisions attached to them.
- The engineering has already shipped and cannot change. That is a visual refresh, which is a smaller job.
- Nobody on your side can make a decision. Design surfaces choices; it cannot make them for you.
Work that proves it
Questions
- What is the difference between UX and UI design?
- UX is the shape of the thing: what the flows are, what happens in what order, what the product refuses to do. UI is what it looks and feels like once that is settled. Doing them in that order is what stops a beautiful screen from hiding a broken flow.
- How is product design priced?
- By what has to be designed: key flows and a prototype, a full product with a design system behind it, or a multi-surface product on an ongoing partnership. Fixed and agreed before the work starts, so the cost of a change is a conversation about scope rather than an argument about hours.
- Should we design before we build?
- Yes, and it usually saves money. Deciding what a screen does costs an afternoon in design and a fortnight in engineering. Products designed before they are built ship faster, because the arguments happen while they are still cheap.
- What do engineers actually get at the end?
- A design system, an interactive prototype, and a handoff built for the people who will implement it: tokens, states, empty and error cases, and the behaviour that a static screen cannot show. We build too, so the handoff is written by people who have received one.
- We already have a product. Can you redesign it?
- Often, yes. A redesign that starts from your existing product and its real usage is usually a better investment than one that starts from a blank canvas and a mood board.
A roadmap, not a pitch.
Skip the agency runaround. Thirty minutes with the people who would actually do the work. You leave with a clear next step, whether or not you hire us.