02 / AI & Product Design
Products aren't screens. They're systems of decisions.
Every interface is the visible residue of a hundred choices made earlier: what to model, what to automate, what to expose, what to refuse. That is as true of an AI product as any other, and it is where a product is actually won or lost.

We turn complex product problems into simple, useful digital experiences.
What we do
- Work out which problem the product should solve next, and which it should stop trying to solve.
- Run user research on real usage, not personas invented in a workshop, and let it change the roadmap.
- Design the structure, the flows and the interface, in that order.
- Design AI capabilities as products: what the system decides alone, what it shows its working for, and how a person stays in control.
- Test it with real users before it ships, then build the system and specifications engineering needs.
Problems we solve
The situations clients arrive with
If more than one of these sounds familiar, they are probably the same problem seen from different seats.

- 01
Usage does not match the roadmap
Features ship on schedule and adoption stays flat. The backlog is full of requests, and none of them explain why the core workflow still takes eleven steps.
- 02
The product has grown by accretion
Five years of additions, each reasonable in isolation. Now there are three ways to do the same thing and new users cannot find any of them.
- 03
The AI pilot worked and nothing changed
A model performs well in evaluation and dies on contact with the workflow it was meant to improve. The failure is almost never the model. It is the experience around it and the process it was dropped into.
- 04
Users do not trust what the system tells them
It is often right and occasionally confidently wrong. Without visible evidence, a cheap correction path and sensible defaults, people either stop using it or, worse, stop checking it.
- 05
Onboarding leaks
People sign up and never reach the moment the product becomes useful. The funnel says drop off, and nobody can say what the user was actually trying to do.
- 06
Design and engineering disagree at the last mile
Handoff is a negotiation. Specs are ambiguous, states are missing, and the shipped product is a lossy compression of the design.
Who this is for
- SaaS teams moving from product market fit to scale
- Enterprise platforms where the real user is a busy specialist, not a browser
- Teams designing their first agentic or assistive experience
- Consumer products where the first ninety seconds decide everything
- Teams rebuilding a legacy product without repeating its structural mistakes
Capabilities
Research
- User research
- Contextual enquiry
- Product discovery
- Usability testing
- Concept testing
- Analytics review
Design
- Product design
- Information architecture
- Interaction design
- Prototyping
- Mobile app design
- SaaS & enterprise design
AI product work
- AI product strategy
- AI experience design
- AI UX
- Conversational UX
- Agentic experience design
- AI prototyping
- Human + AI workflow design
Delivery
- Design systems
- Accessibility
- Design specification
- Design QA
- Product optimisation
Our approach
How we work on this
Four positions we hold consistently, including the ones that occasionally make a first meeting uncomfortable.
Model before you draw
Most interface confusion is a data model leaking through. We get the objects, relationships and states right on paper before anyone opens a design file.
Design the unhappy path
Empty, loading, partial, failed, permission denied, offline, too much data. Products feel unfinished because these states were an afterthought. We treat them as the brief.
For AI, start with the cost of being wrong
Every AI feature has an error profile. What a mistake costs, who absorbs it and how fast it surfaces decides how much autonomy the system gets, and that decides the interaction design.
Test at the level of the real question
A static mock cannot answer whether a flow feels fast, or whether an expert trusts a generated answer. When that is the question, we build something clickable and put it in front of someone.
Ship with engineering, not at them
We work inside the delivery rhythm, with specs that include every state, tokens in code, and review during the sprint rather than after it.
Process
Six stages, each a decision point
Every stage produces something you could act on if you stopped there. That is deliberate. It keeps the engagement honest.
- 01
Discover
Product analytics, support tickets, sales objections, user research interviews and a walkthrough of the current experience with the people who built it. Where AI is in scope, we map where expert attention actually goes.
Outputs
- Research findings
- Current state experience map
- Opportunity list
- 02
Define
We convert findings into a small number of sharply worded problem statements, with the business consequence attached to each. This is where scope gets decided, and where most AI feature ideas should die.
Outputs
- Problem statements
- Success measures
- Prioritised scope
- 03
Explore
Divergent structural options, different information architectures and different mental models, evaluated against effort, risk and how well each survives the edge cases. For AI features this is where the autonomy model is set.
Outputs
- Concept directions
- Information architecture
- Autonomy & control model
- 04
Design
Flows, wireframes, interface design and every state that matters, including how the system discloses evidence, expresses uncertainty and lets a user disagree with it.
Outputs
- End-to-end flows
- Interface design
- Interaction & motion specs
- 05
Test
Usability testing on prototypes, accessibility review against WCAG 2.2 AA, and, for AI work, testing against the cases the system handles badly rather than the ones it handles well.
Outputs
- Usability findings
- Failure mode testing
- Measurement plan
- 06
Scale
Design system components, documented patterns, contribution model and the handover that lets an in-house team keep going without a quality drop.
Outputs
- Component library
- Pattern documentation
- Team handover
What changes as a result
Fewer steps
In the core workflow
The measure that moves everything downstream: time, error rate, support load.
Faster
Time to first value
New users reaching the moment the product proves itself.
Trusted
AI features people use
Adoption follows cheap verification and cheap correction, not raw accuracy.
In their words
What clients say after the work ships.
FAQ
About ai & product design engagements
Both, usually in sequence. Discovery and definition run as a focused track because they need continuity. Once direction is set, design moves into your delivery rhythm and works a sprint or two ahead of engineering.
Related reading
The thinking behind ai & product design
Also in the studio
Our other capabilities
Most engagements draw on more than one practice. These are the ones that usually sit next to this one.
Clients who trust us.











