Key question: Do users want this?
Start with the people and work the project is meant to improve. For the Canvas, treat a system that intended users do not use as unable to deliver its intended user-facing value. Customer Understanding makes the team test whether it has identified a real problem, for a specific group of people, in a specific working context.
This domain has three elements: Customer/User Segments, Jobs to Be Done, and Pains & Gains. Complete them before deciding what the solution should be.
1. Customer/User Segments
A segment is more than a department or job title. It describes people who share a working context, a responsibility, and a stake in the outcome.
For each project, identify the people in at least these roles:
- Primary user — the person who would use the output in their day-to-day work.
- Affected person — someone whose experience, opportunity, or outcome may change because of the system, even if they never use it directly.
- Approver or risk owner — the person accountable for a decision, compliance obligation, security concern, or operational consequence.
- Business owner or change champion — the person responsible for adoption and for making the new way of working stick.
Describe each group using the details that change the design decision: their role, the work context, how often the situation occurs, their observed experience using AI tools at work, what happens if the output is wrong, and what they regard as a good outcome.
Illustrative weak answer: “Everyone in operations.”
Illustrative stronger answer: “Level-1 operations analysts handling high-volume exception cases during month-end peaks. They work against time-sensitive service targets and use a shared case-management system. Team leads review escalations and approve exceptions; they are secondary users because they need to understand and trust the recommendation before acting on it.”
Define a usable segment
Each Canvas names one Primary User Segment. Add one Secondary User Segment only when that group’s needs or interaction with the system would materially change the design. Record affected people, approvers, and other stakeholders separately rather than treating them as additional primary users.
For each user segment, record the existing tools and workarounds, reporting line, frequency of the situation, consequence of error, and — where it changes the work or adoption approach — industry and organisation size.
Assess AI literacy from observed behaviour, not a confidence rating. Use the following AI Value Canvas (AVC) AI-literacy rubric. It is an operational guide, not a validated or regulatory scale. EU AI Act, Article 4 requires measures to ensure sufficient AI literacy but does not prescribe a 1–5 scale.
- 1 — has not used AI tools in work.
- 3 — uses an approved AI tool for bounded tasks and checks its output.
- 5 — independently selects, tests, and documents AI-supported workflows.
Record the evidence for the score and design the support, explanation, and approval flow accordingly.
Evidence to gather
Do not rely only on a project sponsor’s description of the user. Speak to people in the segment and observe or reconstruct recent examples of the work. Ask:
- Who performs the task, who is affected, and who can stop or approve the change?
- What is different about a busy period, unusual case, new employee, or high-risk decision?
- What tools, workarounds, and sources of advice do people use now?
- What level of explanation or control would each role need before relying on an AI-supported output?
Record what you observed, what a participant reported, and what remains an assumption. The distinction will matter when the team decides what to test next.
2. Jobs to Be Done
A Job to Be Done describes the progress a person is trying to make in a particular situation (Christensen Institute, “Jobs to Be Done Theory,” 2024). It is not a feature request, a system requirement, or a list of tasks.
“HR needs a chatbot” and “the manager wants an AI dashboard” already assume a solution. They do not explain the situation, the obstacle, or the outcome that matters. A useful job leaves room for an AI solution, a simpler tool, a process change, or additional human support.
Use this structure:
When _ happens, and I am trying to _, but I struggle because _, help me _, so I can _ without _.
Illustrative weak answer: “HR needs an AI chatbot.”
Illustrative stronger answer: “When employees ask repeated policy questions during peak cycles, HR staff need a reliable way to resolve common queries quickly without increasing response workload or giving an incorrect interpretation of policy.”
Each Canvas has one primary Job to Be Done. Document its current baseline using measures that suit the work, such as median handling time, weekly volume, handoffs, rework, or escalation rate. Also record the end-to-end steps, tools, and owners. This gives the team a starting point for testing whether the proposed support improves the outcome.
Ground each job in recent episodes. Ask a participant to describe the last three times the situation occurred. Capture the trigger, steps taken, people involved, handoffs, tools used, time pressure, and what made the episode difficult. Also record the current workaround: the spreadsheet, shared inbox, WhatsApp group, or colleague people turn to for help. Treat existing behaviour as a hypothesis about what the work requires, then validate it through observation and participant accounts.
A job statement is ready to use when the team can explain the desired outcome without naming a preferred technology.
3. Pains & Gains
Pains are the costs, frustrations, risks, or limitations in the current experience. Gains are the improvements that would be meaningful to the people involved. Both need to be specific enough to observe or test.
Look for several kinds of pain:
- Workflow pain — delays, rework, handoffs, duplicate entry, or repetitive manual effort.
- Decision pain — inconsistent judgement, missing information, uncertainty, or low confidence in a decision.
- Risk pain — an incorrect outcome, misinformation, privacy exposure, unfair treatment, or a missed compliance obligation.
- Change pain — fear of replacement, a training burden, loss of control, or disruption to a routine that currently works well enough.
Avoid gains such as “faster” or “more efficient” without context. State the improvement in terms the segment can recognise: fewer cases returned for rework, more consistent decisions, fewer unnecessary escalations, faster handling of a defined case type, or the ability to take on complex cases without adding avoidable strain.
For every pain or gain, record the current baseline, the evidence for it, and the improvement sufficient for the project’s Horizon: Experiment, Pilot, or Scale. A team does not need to know every number at this stage, but it should know what it needs to measure or learn before claiming value.
Name the highest-priority pain, the observed behaviour or evidence behind it, and how the AI Opportunity Fit is expected to address that pain. If the opportunity does not directly address that pain, narrow the job or revisit the opportunity before designing a solution.
Trust and adoption barriers
Trust is part of desirability, not only a compliance or technical-risk issue. Test whether explanation, correction options, perceived consequences, and prior errors affect use of the AI-supported service in this context.
Ask these questions while defining Pains & Gains:
- What would make a person hesitate to try the system?
- What would make them stop using it after an error or unexpected answer?
- Which decisions require an explanation, an option to correct the output, or a clear route to human help?
- When should the system recommend, and when must a person approve before an action is taken?
- How will the team know whether people are using the system by choice, work around it, or use it only because they have no alternative?
The answers should influence the Solution Concept. For example, a group with little tolerance for a wrong answer may need a recommendation-and-approval flow rather than an automated action.
Illustrative weak answer: “Users will appreciate the time savings.”
Illustrative stronger answer: “Analysts currently reopen cases when a recommendation lacks the policy reference used to reach it. They need a recommendation linked to the relevant policy source and the ability to override it. For the Pilot, the team will test whether this reduces rework without increasing escalations.”
Before moving on
Before you move to AI Opportunity Fit, be able to answer in plain language:
For executives evaluating a proposal: do not approve Solution Concept work until the proposal identifies the Primary User Segment, behaviour-anchored AI literacy, one evidence-backed Job to Be Done, a current baseline, and the principal trust or adoption barrier.
- Who is the primary user, who else is affected, and who is accountable for the change?
- In what situation is the user trying to make progress, and what outcome matters to them?
- What do they do today, where does it break down, and what evidence supports that view?
- Which pains and gains are important enough to test at the current Horizon?
- What would make people trust, adopt, avoid, or work around the proposed support?
If the team cannot answer these questions with observed examples or clearly labelled assumptions, pause before designing the AI solution. The next useful step may be a few more conversations, observation of the current workflow, or a small test of the riskiest assumption — not more solution detail.
Next, test AI Opportunity Fit. See The AI Value Canvas at a Glance to compare AI with rules, a simpler model, a process change, or additional human support.