Product plan
Approaching product design with clarity, without losing velocity.
Identifying the right problems, priorities, context and goals from the get-go allows us to progress efficiently without losing focus and speed, while being aligned on what counts as success.
Product thinking
Problem framing
Stating the problem in terms of the customer's situation, before anyone proposes a screen.
Read moreAssumptions & risk
What has to be true for the idea to work, ordered by what it would cost to be wrong and how little anyone actually knows.
Read moreWhere AI helps
Whether AI belongs in the product at all, answered before anything is designed. It earns its place where somebody repeats a judgement by hand every week and can live with being wrong sometimes. Where there is no such task, it is a cost every later screen carries.
Read moreMVP scope
The smallest thing that tests the riskiest assumption on real users — often not a build at all, and never a smaller version of the whole thing.
Read moreJobs to be done
What the customer hires the product to do. It survives redesigns; features do not.
Read moreAI features
Intent, not commands
The customer says what they want done; the system works out the steps. What used to be the interface — the sequence of clicks that got you there — becomes something the product decides and then has to show its working for.
Read moreBeyond the chat box
The output arriving inside the thing the customer was already doing, rather than in a panel they have to go to and prompt. A chat box asks them to do the thinking first.
Read moreHuman in the loop
Which steps need a person, and whether that person can actually judge what they are approving. Review nobody has time for — a hundred approvals a day, or an answer it would take an expert an hour to check — is a rubber stamp with a name on it. The honest answer follows from the stakes and how reversible the action is.
Read moreProgressive delegation
Autonomy earned rather than granted. The feature drafts, then prepares, then acts — each step widened once it has a record at the one before.
Read moreConfidence & citation
Showing what the answer rests on, so a reader can check it in one move rather than trusting or rejecting the whole thing.
Read moreCalibrated friction
A confirmation where the action is expensive or hard to undo, and none where it is not. A clean, instant answer is the most convincing wrong one.
Read moreFailure & recovery
Designing the wrong answer: a hold before anything that cannot be taken back, and a way through that never needed the model.
Read moreSlow runs
A job that takes ten minutes needs what a spinner cannot give: what it will and will not do, readable progress, and something worth keeping if you stop it.
Read moreData boundaries
Whether it trains anything, and whether one customer's data can surface in another's answer. Both are design decisions before they are legal ones.
Read moreResearch
User interviews
Open questions about what someone actually did last time, not what they would like in future.
Read moreUsability testing
Five to eight people attempting a real task while you watch. The same problems start repeating before the round is out, which is the signal it has done its job.
Read moreCompetitor analysis
What the alternatives have taught your customer to expect, including the parts you would rather ignore.
Read moreResearch ops
Recruiting, consent, incentives, and a place the findings live. The unglamorous half that decides whether research happens twice.
Read moreInformation architecture
Sitemaps
Every page, and which page it sits under. The first place a product's confusion becomes visible.
Read moreTaxonomy
The categories content is filed under, in the customer's words rather than the org chart's.
Read moreLabelling
The two or three words on the button. Usually the highest-leverage copy in the product.
Read moreContent structure
What a page is made of, so the same shape survives a hundred instances of it.
Read moreInteraction & UX
User flows
The path from intent to done, with every branch drawn — including the ones that fail.
Read moreStates & edge cases
Loading, empty, partial, too much, offline, denied. Most of a designer's week.
Read moreForms
Field order, validation timing, error wording. The part of the product people type into and resent.
Read moreError handling
What the product says when it cannot do the thing, and what it offers instead.
Read moreEmpty states
Four different screens wearing one name: nothing yet, nothing matched, nothing left, and nothing loaded. Only the first is onboarding; the other three are where people decide the product is broken.
Read moreInterface & craft
Layout & grid
A column structure the whole product obeys, so a new screen looks like it belongs.
Read moreTypography
A scale, a measure, and a line height. Three decisions that carry most of the visual quality.
Read moreColour & contrast
A palette judged by ratio before mood: 4.5:1 for text, 7:1 where we hold AAA, and 3:1 for any mark that carries meaning without words.
Read moreAccessibility
Keyboard order, focus, labels, contrast. Built in, because retrofitting it costs more than building it in did.
Read moreDesign systems
Tokens
Colour, space, type and radius as named values, so one change lands everywhere at once.
Read moreComponents
A reusable unit with a fixed set of properties, every state it can be in — loading, empty, error, disabled — and the content rules that stop it breaking at a 40-character label. Owned by the people who ship it.
Read morePrototyping & validation
High-fidelity mockups
Screens at the quality they will ship at: real content, real states, real type. Enough that somebody is reacting to the actual thing rather than to a grey box.
Read moreInteractive prototypes
Those screens wired together so a flow can be walked rather than described — with real data and real waiting where the problem is one you have to feel. Clickable enough to test, cheap enough to throw away.
Read moreEvals
A scored set of real cases a model feature has to pass before it ships, and again after every change. Without one, better is a matter of opinion.
Read moreDesign QA
Comparing what was built with what was designed, on the branch rather than in production, while a 4px difference is still a comment and not a ticket.
Read moreExperiments
A change, a group that does not get it, a metric agreed in advance, and enough users to believe the difference.
Read moreNot sure which branch you are stuck in?
Tell us what is not working. We will say which part of this map it belongs to, and whether you need us for it.
Work with us