A flexible and universal guide to designing human-centred AI products.

Question it answers

At every point in this AI workflow does the human have the right information and the right controls to act if they need to?

When to use it

When designing any AI workflow where the system takes actions or produces outputs the user needs to respond to.

How to run it

• Map every moment in the product where the AI takes an action or produces an output.
• For each moment classify the control type required: an override to stop or reject the AI, a redirect to change its direction, an adjustment to modify its next action or an undo to reverse what it has done.
• For each control ask: does the user have enough information to make a meaningful decision here?
• For each control ask: is it visible and accessible without scrolling, searching or opening a menu?
• For each control ask: does the user have enough time to act before the moment passes?
• Write the control label in plain language that describes the action not the mechanism. Not edit or modify but something like change this or I disagree.
• Mark any moment where the answer to any of these questions is no as a control gap.
• Design kill switches for AI features as normal user actions not emergency stops.
• For each control gap define the minimum design change required to close it.

Output

A Control Moment Map: an annotated workflow showing every human decision point, the control type required at each, whether it meets information, visibility and timing requirements, and a prioritised list of control gaps to close.

Question it answers

How do you design AI outputs so that a user instantly understands how much to rely on them and what the system will do at each level of certainty?

When to use it

When designing any screen or component that surfaces an AI output to a user.

How to run it

• List every AI output that appears in the product and assign it a confidence band: high, medium, low or unknown.
• For each band design a distinct visual and linguistic treatment using at least two signals: colour, weight, language, iconography or layout position. Never rely on a single signal.
• For each band define what the system does: acts autonomously, flags for review, presents multiple options or declines to answer.
• Write the label or supporting copy for each band in plain language without technical terms.
• Design the unknown or I do not know state as a distinct treatment. This is the most important state and the one most products skip entirely.
• Place all treatments side by side and check they are clearly distinguishable from each other at a glance.
• Test with users who have not seen the designs before. Ask them to rank outputs by reliability and describe what each band means without prompting. If they cannot do it the treatments need reworking.

Output

A Confidence Rendering System: a defined visual, linguistic and behavioural treatment for each confidence band including the unknown state, validated with users.

Question it answers

How do you design undo and confirmation so that users feel safe letting the AI act on their behalf?

When to use it

When designing any AI feature that takes actions with consequences outside the immediate screen.

How to run it

• List every action the AI can take that changes something outside the product itself: sending, deleting, publishing, purchasing, submitting or modifying a record.
• Classify each action on two dimensions. Scope: does it affect only this user, a group of people or the world beyond the product? Reversibility: can it be undone easily, with difficulty or not at all?
• Assign each action a consequence level: low, significant or critical.
• For significant actions design a confirmation moment that describes exactly what is about to happen in plain language. Not just are you sure.
• For critical actions design both a confirmation moment and a persistent visible undo mechanism present before, during and immediately after the action.
• Define the undo window for each critical action. Make it as generous as technically possible and show it to the user as a countdown or a clear time reference.
• Design the post-undo state to confirm clearly that the action has been reversed.
• Document any critical action without a confirmation moment or undo mechanism as a launch blocker.
• Test the full sequence with users: action, confirmation, undo and post-undo state. Measure how many users successfully reverse an action without assistance.

Output

A Reversibility Design Specification: a consequence classification for every AI action, with confirmation moments, undo mechanisms, undo windows and post-undo states for significant and critical actions, validated with users and a list of unresolved launch blockers.

Question it answers

What does the product actually feel like at different levels of AI autonomy and which level is right for this user and context?

When to use it

When designing any product where the level of AI involvement is variable or user adjustable.

How to run it

• Define three distinct autonomy states for the product: the AI suggests and the human decides, the AI acts and the human reviews, the AI acts and the human is informed.
• Prototype each state as a separate flow. Do not describe the difference in words. Make it tangible.
• Put each prototype in front of users separately without telling them which state they are looking at.
• For each state ask: does this feel like you are in control? Does this feel like the AI is doing too much or too little? Would you trust this to work on your behalf?
• Identify which state users feel most comfortable with for which types of task.
• Use the findings to set the default autonomy level and define the conditions under which users should be offered more or less control.

Output

Three autonomy state prototypes with user research findings and a defined default autonomy level with rationale.

Question it answers

How do you introduce AI autonomy gradually so that users build an accurate and appropriate level of trust before the stakes get high?

When to use it

When designing the early experience of any AI product where trust needs to be established before the AI takes significant actions.

How to run it

• Map the full range of actions the AI can take in the product from lowest to highest consequence.
• Design the first use experience so the AI only takes the lowest consequence actions and makes everything it does visible and explainable.
• Define the trust signals you will look for before unlocking higher autonomy: number of sessions, explicit user approval or a demonstrated understanding of what the AI does.
• Design the transition moments where greater autonomy is offered. Frame them as an invitation not a default. The user opts in rather than having it imposed.
• Design a way for users to step back to a lower autonomy level at any point without penalty or friction.
• Test the full progressive sequence with new users over multiple sessions. Measure whether trust levels at each stage match the actual reliability of the AI at that stage.

Output

A Progressive Trust Design Specification: a staged autonomy design with defined trust signals, transition moments, step-back mechanisms and multi-session research findings.

Question it answers

What does the product show when the AI gets it wrong and does that response maintain trust rather than destroy it?

When to use it

When designing error and edge case states for any AI product.

How to run it

• Using the Failure Mode Map identify the three most likely failure modes a user will encounter.
• For each failure mode design a dedicated failure state. Do not use a generic error message.
• Write the failure state copy in plain language that tells the user what happened, what the AI is uncertain about and what they can do next. Never blame the user.
• Design a clear path out of each failure state: a way to try again, escalate to a human, provide more information or exit gracefully.
• Design the out of distribution state separately: what the product shows when a user asks the AI to do something it was not designed for. This is different from an error and needs a different treatment.
• Test each failure state with users in a scenario where the AI has genuinely failed. Measure whether users understand what happened and can find a path forward without assistance.

Output

A Failure State Design Specification: a dedicated design for each significant failure mode and the out of distribution state, with plain language copy, a clear path forward and usability test results.

Question it answers

How do you design the explanation of an AI decision so that it builds understanding without overwhelming the user?

When to use it

When designing any component that needs to communicate why the AI reached a conclusion.

How to run it

• Define the user literacy level for this context. A domain expert needs a different explanation from a first time user.
• Write three versions of the explanation for the same AI decision: one sentence, one short paragraph and one detailed breakdown. Each must be accurate and none can contradict the others.
• Design the component so the one sentence version is the default. The short paragraph and detailed breakdown are available on demand.
• For high stakes decisions add a counterfactual: a plain language statement of what would have needed to be different for a different outcome.
• Never use model internals, probability scores or technical parameters in the default explanation. These belong in the detailed breakdown for expert users only.
• Test each version with users at the appropriate literacy level. Ask them to explain the AI decision back in their own words. If they cannot do it accurately the explanation needs reworking.

Output

An Explainability Component Specification: three explanation versions for each AI decision type, a component design that surfaces them progressively, and user test results confirming comprehension at each level.

Question it answers

How do you set honest and accurate expectations of what the AI can and cannot do from the first use?

When to use it

When designing the onboarding experience for any AI product.

How to run it

• Using the Mental Model Gap Report identify the three most dangerous gaps between user expectation and system reality.
• For each gap write a plain language correction with no technical jargon.
• Design the moment in onboarding where each correction arrives. It must come before the user encounters the relevant feature, not after they have already been misled.
• Use analogy to explain AI behaviour in terms the user already understands from everyday life.
• Design a clear what this cannot do moment. This feels commercially counterintuitive but produces a significantly better experience and reduces misuse.
• Test with new users. Can they accurately describe what the AI does and does not do after completing onboarding?

Output

An Onboarding Experience Map: a content and design specification for onboarding including correction moments, analogies and limitation disclosures, validated with new users.

Question it answers

How do users tell the AI it was wrong and how does the system show it listened?

When to use it

When designing the feedback and improvement layer of an AI product or system.

How to run it

• Identify every AI output in the product that a user might want to correct, challenge or improve.
• Design a low effort feedback mechanism for each. The fewer taps or clicks required the more feedback you will receive.
• Define what happens to that feedback: retraining, human review or immediate adjustment.
• Design a visible response to feedback. When a user tells the system it was wrong something must visibly change.
• Design a richer interface for expert users to label, correct or annotate AI outputs.
• Embed feedback as a core product feature. Do not surface it as a periodic survey.

Output

A Feedback Loop Specification: a design document defining feedback entry points, processing logic, visible responses and expert interfaces.