"The product works. Engineering is solid. But users are dropping off somewhere between signup and the first time they actually get value - and nobody knows exactly where or why."
Product Design / service detail
Decision-led interface work
01
ProductDesign
SITUATIONS WE KNOW WELL
"We've validated the idea. The team is ready. But nobody has clearly defined what the product must do for the user at each moment - and that ambiguity is about to become expensive."
"We're rebuilding a legacy tool for a new type of user. The old logic doesn't map to new behavior. We need someone who can hold both simultaneously without losing either."
"We have a design team. What we don't have is someone who can step back and tell us whether the thing we're building is actually the right thing to build."
HOW WE WORK
Four phases. No shortcuts.
Four phases. No phase is skipped. Each one produces something you can use, not just something that enables the next phase.
Phase 01 / 04
01
Direction
Phase 01 of 04What happens
We map the user's decision path before we sketch anything. We run structured sessions with your team to understand the user's situation, their existing mental model, and the moment your product must change their behavior. We surface the assumptions your team is holding about the user that have never been tested.
What you do
Bring your team, your data, and your honest uncertainty. This phase runs best when people say what they actually think, not what sounds good.
What you leave with
A product direction document that defines what the product must do, for whom, in what order - before a single interface element is drawn.
02
Structure
Phase 02 of 04What happens
We translate the direction into a structural model - the core flows, decision points, and content hierarchy that the interface must support. No visual design yet. Only logic.
What you do
Review and pressure-test the structure against real user scenarios you know from your own experience. Push back where something doesn't match what you know about your users.
What you leave with
A validated product structure that engineering can begin planning against - and that you can show stakeholders without embarrassment.
03
Interface
Phase 03 of 04What happens
We design the interface across all critical flows. Every screen is connected to the decision logic defined in the structure phase. Nothing exists because it looked good in isolation.
What you do
Review in rounds. We show our reasoning, not just our output. You push back on what doesn't serve your user.
What you leave with
A fully designed, annotated interface ready for development - with a design system built for your product's scale, not borrowed from a generic library.
04
Validation
Phase 04 of 04What happens
We put real users in front of the interface before a single line of production code is written. We watch where they hesitate, where they misread, and where they succeed. We revise based on what we see - not what we think.
What you do
Help us recruit the right users. Be present for testing if you can. The best decisions come from watching your own users struggle.
What you leave with
A tested product that enters development with evidence behind it - not assumptions.
WHAT YOU GET
Deliverables are only useful if you know what they change.
Each output needs a commercial consequence. These rows show what the work changes, not just what gets handed over.
Product direction document
Eliminates scope ambiguity before engineering starts. Saves revision cycles before they're created.
Product structure model
Gives engineering a logical foundation to build against. Prevents architecture decisions that have to be reversed later.
Designed and annotated interface
Removes interpretation gaps between design and development. Every screen includes the reasoning behind it.
Product-specific design system
Your next feature ships faster because the decisions are already made. Consistency is structural, not manual.
Validation report
You enter development with tested evidence. Your stakeholder conversations are grounded in user behavior, not assumptions.
COMMON QUESTIONS
Common questions
Not as much as you might think. You need a clear sense of the problem you're trying to solve and access to the people in your organisation who understand your users best. You do not need a finished brief, a complete spec, or a resolved product direction - that's part of what the first phase produces.
Meaningfully involved, not constantly available. The direction phase requires real sessions with the people who understand your users and your business. After that, the heaviest demand is in reviews - where your judgment on what's right for your user matters more than ours. We work in structured cycles so your involvement is concentrated, not continuous.
You do. All source files, documentation, and design assets are transferred to you at the end of the engagement with no conditions.
A full engagement - covering all four phases - typically runs eight to fourteen weeks depending on product complexity and the pace of your team's availability. Projects with tighter timelines can be scoped around specific phases rather than the full process. We'll tell you clearly what's possible in the time you have.
START A CONVERSATION
Tell us what you're building and where you're stuck.
We respond with a perspective, not a proposal. If there's a fit, we'll suggest a short call. If there isn't, we'll say that too.
product design inquiryFour fields. Nothing else.