Methods / Strategy
Question it answers
Is AI the right solution here and what genuine new value could it create beyond automating existing tasks?
When to use it
At the very start of a project before any solution direction is set.
How to run it
- Write a one sentence description of the problem you are trying to solve.
- List every way the problem is currently being solved: by humans, by non-AI software, or not at all.
- For each current solution ask what AI makes possible that was not possible before. If the answer is only cheaper or faster, challenge whether AI is justified.
- Map potential AI interventions against two axes: value created for the human versus value created for the business. Discard anything that only serves the business.
- Score each remaining opportunity by potential harm: low, medium or high.
- Prioritise opportunities that create genuine new human value and carry manageable harm potential.
Output
An AI Opportunity Map: a prioritised list of validated AI use cases with a harm potential score and a one line justification for each.
Question it answers
Who is affected by this AI system, how badly could it harm them, and what does the system do when it fails?
When to use it
Before any design work begins. Return whenever scope, model or user group changes.
How to run it
- Identify the direct user: the person actively using the product or system.
- Identify indirect stakeholders: people affected by AI outputs who never interact with it directly.
- Identify vulnerable populations within each group: people for whom a wrong decision causes disproportionate harm.
- For each group map what decisions the AI makes or influences that affect them and what happens if those decisions are wrong.
- List the ways the AI could produce a wrong output: hallucination, misclassification, out of distribution input, bias and adversarial input.
- For each failure mode, trace what happens downstream: what does the user see, what decision do they make and what is the consequence.
- Identify which failures are visible to the user and which are silent. Silent failures are the highest priority.
- For each potential harm assign a likelihood, severity and reversibility rating.
- Identify which harms are acceptable with mitigations and which are dealbreakers.
- Define a design response for each failure mode: a guardrail, a confidence signal, a fallback or a human escalation path.
Output
A Human Impact and Failure Map: a stakeholder diagram annotated with harm pathways, failure modes, severity scores, visibility ratings and mitigation requirements.
Question it answers - What type of AI problem is this and do the people using it understand what the AI is actually doing?
When to use it - Once a use case has been identified and before any design begins. Return after significant product changes or when onboarding data suggests persistent user confusion.
How to run it
- Write down what you want the AI to do in plain language.
- Map it to a problem type: classification, regression, recommendation, generation or sequencing and planning.
- Determine what form of human control is most natural for this problem type: validating a category, adjusting a value, ranking options or steering a process.
- Without showing the product, ask users to describe in their own words what they expect the AI to do in this context.
- Document the mental models that emerge: the metaphors, assumptions and expectations users hold.
- Map these against what the system actually does and identify where the mental model is accurate, optimistic or dangerously wrong.
- For each significant gap assess the risk: what does a user do when they have a wrong mental model?
- Define a design response for each gap: onboarding framing, in-product explanation, progressive disclosure or analogy.
Output - A Problem Type and Mental Model Report: documents the AI problem type, the most natural form of human control, and a side by side comparison of user mental models and system reality with design recommendations for closing each gap.
Principles - AI model meet mental model — Control not input — High autonomy and human control — Transparent interactions
Question it answers - Who does our training data represent and who does it fail?
When to use it - Before committing to a dataset or a pre-trained model. Return whenever the model or dataset changes.
How to run it
- List the populations your product or system is intended to serve.
- For each population ask whether they are represented in the training data and at what proportion relative to real world distribution.
- Identify groups that are underrepresented, misrepresented or entirely absent.
- For each gap assess what happens to a person from this group when the model encounters them.
- Document the geographic, demographic, linguistic and temporal coverage of the data.
- Identify what data collection or augmentation would be needed to close the gaps and whether that is feasible.
Output A Data Representation Report: a structured assessment of coverage gaps, failure modes for underrepresented groups and recommended mitigations.
Principles Ethics and data — Safety is imperative — Logging and observability
Question it answers How much should the AI do autonomously and where must the human remain in control?
When to use it Once the use case and problem type are established. Before designing any interaction or workflow.
How to run it
- List every decision or action the AI system could take within the product or workflow.
- Score each on stakes: what is the consequence if this decision is wrong, rated 1 to 5.
- Score each on reversibility: how easily can this decision be undone, rated 1 to 5.
- Plot each decision on a two by two grid. Low stakes and reversible means high autonomy is appropriate. High stakes and irreversible means a human must be in the loop.
- For decisions in the middle define the trigger condition for human involvement.
- Define the override mechanism for every autonomous action.
Output An Autonomy Spectrum Map: a decision inventory plotted by stakes and reversibility, with defined autonomy levels and override mechanisms for each.
Principles High autonomy and human control — Control not input — Reversible actions — Safety is imperative
Question it answers Where exactly does a human need to be involved in this AI workflow and what does that involvement look like?
When to use it After Autonomy Spectrum Mapping, to translate the map into a concrete workflow design.
How to run it
- Map the end to end AI workflow as a process diagram covering inputs, model steps, outputs and downstream effects.
- Mark every point where human involvement is required using the Autonomy Spectrum Map.
- For each human touchpoint define what information the human needs, how much time they have to act and what the consequences are if they do not act.
- Define what approve, override and redirect look like in the interface at each touchpoint.
- Identify any points where the AI could act without the human realising and add visibility mechanisms.
- Stress test the blueprint: what happens if the human is unavailable, slow or makes a wrong call?
Output A Human AI Blueprint: an annotated workflow diagram showing human touchpoints, information requirements, timing constraints and interface requirements at each point.
Principles High autonomy and human control — Control not input — Transparent interactions — Reversible actions
Question it answers Do the people with decision making power understand the HCAI implications of this product and are they genuinely committed to them?
When to use it Before any major build commitment. Return before any significant launch or scope change.
How to run it
- Identify the stakeholders whose decisions affect the HCAI outcomes of this product: legal, commercial, executive and operational leads as well as the product team.
- Present what the AI does in plain language with no jargon. Use the Problem Type and Mental Model Report and Human Impact and Failure Map as reference.
- Present what could go wrong using the Human Impact and Failure Map. Do not soften this.
- For each significant harm ask for an explicit commitment to the mitigation strategy, not passive acceptance.
- Document any harm or mitigation that stakeholders push back on. These are signals of misalignment that must be resolved before build begins.
- Agree a named escalation path: who has the authority to stop the product if an HCAI concern arises post launch.
Output A Stakeholder Alignment Record: a documented record of what was presented, decisions made, commitments given and the named escalation path.
Principles Transparent interactions — Safety is imperative — Ethics and data