Designing AI products people can understand and trust
When a product starts generating, recommending or acting on its own, the interface has to explain what the system is doing, how sure it is, and how to correct it. We design AI features and agentic experiences that people can rely on, not just demo.
What changes when a product becomes AI-powered?
When a product becomes AI-powered, its output stops being fully predictable: the same input can produce different results, results can be confidently wrong, and the system may act on the user's behalf. Design has to make that uncertainty visible, checkable and correctable.
Traditional interface design assumes software does exactly what it is told. AI breaks that assumption, so the design work moves from arranging screens to managing expectations: what the system can do, what it just did, how much to rely on it, and what to do when it gets something wrong.
That is why AI features so often demo well and disappoint in daily use. The happy path was designed; the uncertain, slow and wrong paths were not.
AI product problems we solve
- Nobody trusts the output, so people redo the work by hand
- People over-trust it, and errors reach customers
- The AI feature goes unused because nobody knows what to ask it
- A blank prompt box where the product should guide the task
- Results are hard to correct, so one mistake means starting again
- Nobody can tell what the agent did, or why
- Slow responses feel broken rather than in progress
- AI bolted onto an existing UI that was never designed for it
AI interaction patterns
The pattern should match how costly a wrong answer is, not what is fashionable.
Suggest and accept
The system proposes; the person decides. Right for low-stakes, high-frequency tasks.
Draft, then edit
The AI produces a first version the user shapes. Editing must be easier than regenerating.
Ask to clarify
When a request is ambiguous, a short question beats a confident guess.
Streaming with control
Partial results as they arrive, with stop, retry and edit always within reach.
Sources and grounding
Show what an answer is based on, so people can verify rather than believe.
Scoped automation
Agents that act within explicit permissions, with a clear record of what they did.
Designing for uncertainty
Show confidence only when people can act on it differently. A percentage nobody can act on is decoration; a visual cue that says "check this one" changes behaviour.
Prefer showing the basis for an answer, such as its sources, the data it used or the rule it applied, over a generic disclaimer. People calibrate trust from evidence, not from warnings they have learned to ignore.
Design the wrong answer first. If the interface cannot gracefully handle a confident mistake, it is not ready, however good the model is.
Designing AI feedback and system state
AI work takes time and happens out of sight. People need to know whether the system is thinking, working through steps, waiting on them or finished, and what context it is using. Long-running tasks need progress that means something, partial results where they are useful, and a way to stop.
State also includes memory: what the system remembers about the user and the task, and how to change or clear it.
Human approval and agent actions
We design autonomy as a dial, not a switch: suggest, draft, act with approval, and act then report. Where an action sits on that dial depends on how reversible it is and what a mistake costs.
Irreversible or external actions, such as sending, paying, deleting or publishing, get an explicit approval step with a preview of exactly what will happen. Routine actions can be batched for review, so approval does not become a click-through habit.
Error recovery
Every AI path needs a way back: undo, edit the result, regenerate with guidance, or switch to doing it manually. Dead ends teach people not to use the feature at all.
Errors should be reportable in the moment, from the place they happened. That feedback is also how the product team finds the failures worth fixing.
Trust and explainability
Trust comes from consistency and honesty more than from explanation. Behave the same way in the same situation, say plainly what the system cannot do, and show what changed when it acts.
Explanations should answer the question the user actually has, usually "why this?" or "what did you use?", in one line, with depth available on request.
AI onboarding, dashboards and agentic experiences
Teach what it can do, and what it can't
Example tasks instead of a blank prompt, honest limits up front, and a first success that shows the value within the first session.
Oversight for work you didn't do yourself
Activity feeds, review queues, audit trails and usage views, so teams can supervise AI and agent output at scale.
Delegation people can follow
Task hand-off, step-by-step status, approval points and a clean handoff to a human when the agent is stuck.
AI product discovery
AI product discovery tests whether a problem genuinely benefits from AI before a model or vendor is chosen: is the task frequent enough, tolerant enough of error, and checkable enough for AI to help rather than add risk?
We prototype with realistic outputs, including wrong ones, and test them with the people who will rely on them. That shows early whether users will trust the feature, over-trust it or ignore it, while changing direction is still cheap.
AI product design process
Frame the task
Which job the AI does, for whom, and how much error that job can tolerate.
Map autonomy and risk
Where each action sits on the autonomy dial, and which ones need approval.
Prototype with real outputs
Realistic model output, including failures, so the design is tested against what the system actually does.
Test trust calibration
Usability testing focused on whether people rely on the AI the right amount.
Specify states and guardrails
Every loading, partial, error, refusal and approval state documented for engineering.
Measure after launch
Adoption, correction rates and abandonment, fed back into the next iteration.
AI product design FAQs
How should an AI agent communicate what it is doing?
With meaningful status rather than a spinner: what step it is on, what it is waiting for, what it has already done and what it plans next. Long tasks should show partial results where useful and always offer a way to stop.
How should users approve an agent's action?
With a preview of exactly what will happen before anything irreversible or external, such as sending, paying, deleting or publishing. Routine, reversible actions can be batched for review so approval does not become a reflex.
How much autonomy should an AI agent have?
As much as the cost of a mistake allows. We place each action on a dial (suggest, draft, act with approval, act and report) based on how reversible it is and who is affected if it goes wrong.
What happens when an AI agent fails?
It should stop safely, say what it could not do and why, keep the work it completed, and hand off cleanly to a person or a manual path. Silent failure is the worst outcome because people stop trusting everything the agent does.
How do users recover from AI mistakes?
Through undo, editing the result, regenerating with guidance, or switching to a manual path, all available from where the mistake appears. Recovery should be faster than starting over.
How should AI explain uncertainty?
By showing the basis for an answer, such as sources or data used, and flagging items that need checking, rather than generic disclaimers or confidence numbers nobody can act on.
How do you design the handoff from AI to a human?
The handoff carries context: what the user asked, what the AI tried and where it got stuck, so the person taking over does not start from zero and the user does not have to repeat themselves.
How should agent permissions work?
Permissions should be explicit, scoped to the task and visible to the user, with a clear record of what the agent accessed and changed. Expanding an agent's permissions should be a deliberate step, never a side effect.
Do you build or train AI models?
No. We design the product experience around the model and work with your engineering and ML teams on behaviour, states and guardrails, so the interface matches what the system can actually do.
Tell us what your AI should do, and what happens when it's wrong
Much AI product work sits under NDA, so we walk through relevant work on a call. Bring the feature or agent you're designing and we'll tell you where we'd start.