User Models and Experience Mapping

Introduction and Context

User research produces evidence about people, but evidence becomes useful for design only when it is organized into models that support decisions. User models and experience maps translate observations, interviews, behavioural data, and contextual inquiry into representations of users and their interactions with products or services. They help a team ask practical questions: Who is trying to achieve what? What obstacles occur? Which moments create value or frustration? What must the organization change behind the interface?

These models are interpretive tools, not photographs of reality. A persona is not a real individual; a journey map is not a complete record of every experience. Each is a reasoned, research-grounded abstraction. Their quality therefore depends on the quality of the evidence, the transparency of interpretation, and the discipline with which uncertainty is handled.

This chapter focuses on six connected artefacts: personas, empathy maps, jobs-to-be-done statements, scenarios, user journey maps, and service blueprints. It also addresses ethical representation, validation, collaborative use, and common failure modes.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the purpose and limitations of major user-modelling artefacts.
2. Construct evidence-based personas without stereotyping or inventing unsupported details.
3. Distinguish goals, tasks, needs, motivations, and jobs-to-be-done.
4. Create scenarios and journey maps that represent context, emotions, touchpoints, and pain points.
5. Extend a journey map into a service blueprint showing frontstage and backstage activity.
6. Use models to identify design opportunities and testable hypotheses.
7. Apply ethical and inclusive practices when representing users.

1. User Models as Evidence-Based Abstractions

A user model simplifies a complex field of human behaviour so that a design team can reason consistently. It should answer a particular design question and identify the evidence on which it rests. A useful model has four qualities:

• Traceability: important claims can be linked to research observations or data.
• Relevance: the model addresses a current product or service decision.
• Internal coherence: goals, behaviours, constraints, and context do not contradict one another.
• Actionability: the model helps the team generate or assess design responses.

Models should not be treated as permanent truths. New research, changed technology, or a different service context may require revision. Teams should record the model's date, scope, research sources, and unresolved assumptions.

Segmentation and modelling

Demographic categories such as age, gender, occupation, or income may be relevant, but they rarely explain behaviour by themselves. Behavioural and contextual variables are often more useful: frequency of use, task urgency, digital confidence, access conditions, authority to make decisions, or consequences of failure. Segmentation should reflect meaningful differences in needs and behaviour rather than convenient labels.

A segment is not automatically a persona. A segment describes a group; a persona gives a concise, evidence-based representation of a significant pattern within that group. A good persona is therefore selective. It includes information that affects design and excludes biography that merely makes the character feel realistic.

2. Personas

A persona is a research-based archetype representing a recurring pattern of goals, behaviours, constraints, and contexts. It helps a team maintain a shared focus on users during prioritization and design critique.

Components of a useful persona

A practical persona normally includes:

• a descriptive name or identifier, preferably a pseudonym;
• the research basis and date of creation;
• relevant context, such as environment, device access, or role;
• primary goals and desired outcomes;
• behaviours and coping strategies;
• barriers, constraints, and accessibility requirements;
• representative quotations, clearly attributed and not fabricated;
• confidence notes identifying strong evidence and open questions;
• design implications and excluded assumptions.

A persona need not contain a stock photograph. Photographs can encourage teams to stereotype users or treat the persona as an individual biography. An illustration, neutral icon, or no image may be more appropriate.

From research to persona

The construction process is best understood as a chain of reasoning:

1. Collect evidence. Gather interview statements, observed actions, support records, analytics, diary entries, and relevant survey findings.
2. Code patterns. Identify recurring goals, behaviours, contexts, barriers, and workarounds.
3. Compare cases. Look for meaningful similarities and differences, rather than averaging all participants into one imaginary user.
4. Form candidate groups. Group people by design-relevant patterns, not by demographic convenience.
5. Check representation. Ask whether important minority or high-risk experiences have disappeared through aggregation.
6. Draft and label uncertainty. Separate observed behaviour from interpretation and hypothesis.
7. Validate. Compare the draft with source material and, where feasible, ask participants or subject experts whether it is recognizable and fair.

A statement such as “Priya dislikes technology” is weak because it is vague, evaluative, and unsupported. A stronger statement is: “In observed appointment-booking sessions, Priya switched from the mobile site to telephone support when error messages did not explain which fields needed correction.” The latter identifies behaviour, context, and a possible design opportunity without assigning a personality defect.

Primary, secondary, and negative personas

A primary persona represents the main design target for a product decision. Secondary personas have important needs that should also be accommodated, although they may not determine every priority. A negative persona describes a group outside the intended scope, helping prevent uncontrolled feature expansion. These categories must not imply that some users are less worthy; they describe scope and design responsibility.

3. Empathy Maps

An empathy map organizes what the team knows or hypothesizes about a person in a situation. Common quadrants are says, thinks, does, and feels. Some versions add pains, gains, influences, or needs.

The map is useful for noticing contradictions. A user may say that speed is important, think that a service is risky, do extensive checking, and feel anxious. Such a pattern suggests that the visible request (“make it faster”) may coexist with a deeper need for confidence.

Empathy maps can be dangerous when treated as invitations to guess. “Thinks” and “feels” are not permission to invent mental states. They should be based on expressed statements, observed indicators, validated interpretation, or clearly marked hypotheses. Use notes such as “reported concern about payment security” rather than “is paranoid.”

Empathy maps are usually situation-specific. The same person may have different concerns when buying a routine item, reporting a safety issue, or using a service under time pressure. A map should therefore name the situation and evidence sources.

4. Jobs-to-be-Done Statements

The jobs-to-be-done (JTBD) perspective focuses on the progress a person is trying to make in a particular circumstance. It shifts attention from product features and demographic identity to desired outcomes and context.

A useful job statement follows this form:

When [situation], I want to [motivation or action], so I can [expected outcome].

For example: “When I receive a prescription renewal reminder while travelling, I want to confirm the request quickly, so I can avoid an interruption in medication.”

A job is not simply a task such as “click the renewal button.” It includes the underlying outcome and circumstances. Jobs may be:

• Functional: accomplish an observable result.
• Emotional: feel confident, reassured, or in control.
• Social: present oneself in a desired way to others.

JTBD statements are not replacements for personas. A persona describes a pattern of user context and behaviour; a job describes the progress sought in a situation. Several personas may share a job, and one persona may have multiple jobs.

To evaluate a job statement, ask whether it specifies a real situation, avoids naming a particular solution, expresses an outcome, and can guide research or design. “When I need to renew a prescription, I want to complete it without uncertainty, so I can maintain treatment” is more useful than “I want a better app.”

5. Scenarios

A scenario is a short narrative describing how a user, with a goal, interacts with a product or service in a specific context. It connects abstract models to concrete use. A scenario should identify:

• actor and relevant capability or limitation;
• trigger and goal;
• physical, social, and technological context;
• sequence of important actions;
• decisions, interruptions, and recovery attempts;
• desired outcome and consequences of failure.

Scenarios may be current-state descriptions, future-state design stories, or evaluative test scenarios. A current-state scenario should not quietly include the proposed solution. A future-state scenario should label assumptions and remain open to alternative designs.

Illustrative scenario

A patient receives a reminder to renew medication during a train journey. Network connectivity is intermittent, the patient has limited time, and the medication is important. The patient opens the reminder, checks the pharmacy, encounters a missing insurance field, saves progress, and later completes the request through a desktop device. This scenario reveals requirements for clear status, recovery, accessible error messages, and continuity across devices. It also exposes a service question: what happens if the request is not completed before the supply runs out?

6. User Journey Maps

A user journey map represents experience across time. It may describe a single episode, such as booking an appointment, or a longer lifecycle, such as discovering, adopting, using, and renewing a service. Typical lanes include stages, user goals, actions, questions, emotions, touchpoints, pain points, opportunities, and evidence.

A map should declare its scope. “The patient journey” is too broad unless the map defines the beginning and end, the user perspective, and the journey being studied. The same service can produce different journeys for a first-time user, a returning user, a carer, or a staff member.

Mapping procedure

1. Define the persona or user group, job, start trigger, end point, and journey scope.
2. Gather evidence from interviews, observation, support data, analytics, and service records.
3. Break the experience into stages meaningful to the user, not merely internal departments.
4. Record actions and touchpoints, distinguishing direct evidence from inference.
5. Add goals, questions, emotional responses, barriers, and workarounds.
6. Identify moments of truth: interactions that strongly affect trust, continuation, or abandonment.
7. Add opportunities as testable propositions, such as “Users may continue more often if saved progress is visible.”
8. Validate the map with users and staff, then prioritize opportunities by impact, feasibility, and evidence strength.

A journey map is not a process map. A process map emphasizes organizational activities and flow; a journey map emphasizes the user's experience. Both may be needed, and the service blueprint connects them.

Figure: A service blueprint places visible and invisible service activity beneath the user journey.

7. Service Blueprints

A service blueprint expands the journey map to show how an organization delivers an experience. Its central elements are:

• Customer actions: what the user does.
• Frontstage actions: visible employee or interface interactions.
• Backstage actions: activities hidden from the user but necessary for delivery.
• Support processes: systems, partners, policies, and resources.
• Physical or digital evidence: messages, screens, receipts, spaces, or status indicators.
• Lines: the line of interaction, line of visibility, and sometimes line of internal interaction.

For example, in an appointment service, the customer submits a request; the interface confirms receipt; a scheduling system checks availability; staff resolve exceptions; and a notification provider sends a reminder. If the reminder fails, the blueprint can reveal whether the cause is a data problem, an integration failure, a policy constraint, or an unclear interface.

Blueprints are valuable because many user problems originate behind the interface. A redesign of a form cannot solve a policy that requires duplicate data entry, nor can clearer messaging compensate for an unavailable appointment capacity. The blueprint supports cross-functional conversation and helps assign ownership.

8. Integrating the Models

These artefacts answer different questions:

A coherent workflow may begin with research synthesis, develop personas and jobs, write current-state scenarios, map journeys, and then blueprint the service. The sequence is iterative rather than rigid. A blueprint may reveal a missing user group; a journey map may reveal that the original persona combined two distinct contexts.

9. Evidence, Uncertainty, and Validation

Every model should distinguish at least three kinds of content:

• Observed or reported: directly supported by research.
• Interpreted: a reasoned synthesis of several observations.
• Hypothesized: plausible but requiring further investigation.

Use an evidence register containing the claim, source, date, sample or context, confidence, and design consequence. Quantitative data can indicate frequency or drop-off, while qualitative research can explain meaning and context. Neither automatically substitutes for the other. A high abandonment rate does not prove a particular cause; an eloquent interview does not establish prevalence.

Validation is not a vote on whether users “like” a persona. It asks whether the representation is recognizable, relevant, and consistent with evidence. Review models with participants where safe and practical, with frontline staff who understand service variation, and with stakeholders who can challenge organizational assumptions. Revise rather than defend a model when contradictory evidence appears.

10. Ethics, Inclusion, and Governance

User models can influence investment, policy, and access; they therefore have ethical consequences. Researchers and designers should:

• obtain appropriate informed consent and protect confidential information;
• use pseudonyms and remove unnecessary identifying details;
• avoid deficit language that locates problems in people rather than systems;
• represent disability, culture, language, age, and socioeconomic conditions without tokenism;
• include people affected by exclusion, not merely average or convenient users;
• avoid inferring sensitive traits from weak evidence;
• document who was not included and how that limits use of the model;
• provide an accessible format for collaboration;
• set review dates and retire outdated models.

A persona should never be used to deny service to a real person. It is a design aid, not an eligibility rule. Where automated systems use profiles or behavioural data, teams must consider privacy, discrimination, explainability, data minimization, and applicable data-protection law. AI-generated personas require particular caution: language models can produce plausible but invented details and reproduce cultural stereotypes. AI may help cluster or summarize de-identified material, but humans must verify source traceability, uncertainty, and representational fairness.

11. Common Failure Modes and Best Practices

The demographic stereotype: “Older users cannot use digital services.” Replace it with observed differences in access, confidence, motor ability, or task context.

The celebrity persona: A dramatic story based on one participant is presented as representative. Preserve the case as a case study or gather more evidence before generalizing.

The fictional quote: A polished sentence is placed in quotation marks although no participant said it. Use paraphrase labels or a verified quotation.

The solution-first job: “Users need a dashboard.” Ask what progress the dashboard is meant to support.

The happy-path journey: The map shows successful completion only. Include interruptions, errors, waiting, handoffs, and recovery.

The touchpoint inventory: A list of channels is called a journey map. Add user goals, actions, outcomes, and emotional or practical consequences.

The frontstage-only blueprint: The screen is redesigned while staffing, policy, or system constraints remain invisible. Map backstage dependencies and ownership.

The wall artifact with no decision: A visually attractive map is never used. Connect each model to a decision, hypothesis, design requirement, or research question.

Good practice is to keep artefacts concise, cite their evidence, use plain language, expose uncertainty, and revisit them at major product or service changes. Models work best when embedded in workshops, design critiques, usability testing, and prioritization—not when displayed as static decoration.

Applied Case: Illustrative Community Clinic Renewal Service

Background

The following is a fictional illustrative case. A community clinic wants to improve prescription renewal because patients report missed renewals and staff spend substantial time answering status enquiries.

Problem

An initial assumption is that patients need a simpler renewal form. Research instead includes interviews with patients, observation at the reception desk, review of call reasons, and a walkthrough with pharmacists. The evidence shows several contexts: routine renewals, travel-related urgency, carers acting for relatives, and patients with limited connectivity. The main difficulty is not always form completion; it is uncertainty about whether the request was received and when medication will be available.

Analysis through models

A primary persona represents a patient managing recurring medication while working irregular hours. It records intermittent mobile access, a goal of continuity, and a reported need for reliable status—not an assumption that the patient is “bad with technology.” A secondary persona represents a carer who manages several people's requests and needs clear identity and authorization boundaries.

A JTBD statement is: “When I need a renewal and cannot easily contact the clinic, I want to submit and track the request, so I can maintain treatment without repeated calls.” A current-state scenario includes a reminder, an attempted submission, an unclear error, a telephone call, and a staff lookup. The journey map identifies the highest-friction moments as submission confirmation, exception handling, and waiting. The blueprint reveals that pharmacists manually reconcile requests from two systems and that some medication types require a clinical review.

Approach and solution

The team proposes a confirmation reference, explicit status states, accessible error recovery, saved progress, a clear explanation of clinical review, and a staff queue that exposes unresolved exceptions. The design does not promise immediate fulfilment when policy or capacity prevents it. Instead, it communicates the next action and escalation route. Research then tests whether users understand status labels and whether staff can manage the queue without duplicating work.

Outcome and learning points

In this illustrative case, the important outcome is not a claimed numerical improvement but a change in problem definition: the service must support confidence and continuity across interface, staff, and system layers. The case demonstrates why a journey map should lead to a blueprint, why jobs should be expressed as outcomes rather than features, and why evidence should challenge the initial design brief.

Chapter Summary

User models are selective representations that help design teams reason about recurring patterns, situations, experiences, and service operations. Personas synthesize evidence about relevant users; empathy maps organize expressed and observed experience; jobs-to-be-done describe desired progress in context; scenarios narrate goal-directed use; journey maps show experience over time; and service blueprints connect visible interactions with backstage work. None is a substitute for research, and none should be treated as a literal or permanent description of people.

Strong practice requires traceable evidence, explicit uncertainty, contextual segmentation, inclusive representation, validation, and ethical handling of personal data. The most useful models are linked to decisions and testable hypotheses. They expose interruptions, handoffs, policy constraints, and system dependencies rather than presenting an idealized happy path. Used responsibly, they turn research into shared understanding and actionable service improvements.

Key Terms

Persona: An evidence-based archetype representing a recurring user pattern.

Archetype: A generalized pattern used to support reasoning, not a literal individual.

Empathy map: A structured representation of what users say, think, do, and feel in a situation.

Jobs-to-be-done: The progress a person seeks in a particular circumstance.

Functional job: A desired practical outcome.

Emotional job: A desired feeling or psychological outcome.

Social job: A desired outcome concerning identity or relationships.

Scenario: A contextual narrative of goal-directed use.

User journey map: A time-based representation of user experience across stages and touchpoints.

Touchpoint: A point of contact between a user and a product, service, or organization.

Moment of truth: An interaction that strongly influences trust, continuation, or evaluation.

Service blueprint: A map linking user actions to frontstage, backstage, and support activities.

Frontstage: Service activity visible to the user.

Backstage: Service activity hidden from the user but necessary for delivery.

Line of interaction: Boundary between user actions and organizational interaction.

Line of visibility: Boundary between visible and hidden service activity.

Evidence traceability: The ability to connect a model claim to its research source.

Current-state map: A representation of how an experience operates now.

Future-state map: A proposed representation of a redesigned experience.

Negative persona: A defined out-of-scope user group used to clarify design boundaries.

Review Questions

Short Answer Questions

1. What is the main purpose of an evidence-based persona?
2. How does a job-to-be-done differ from a product feature?
3. Why should an empathy map identify its situation and evidence sources?
4. Name two layers commonly included in a service blueprint.
5. What is the difference between a journey map and a process map?

Long Answer Questions

1. Explain a rigorous process for constructing and validating a persona.
2. Discuss how scenarios and journey maps complement one another in UX research.
3. Explain how a service blueprint can reveal causes of problems that an interface redesign cannot solve.
4. Describe ethical risks in representing users and propose safeguards.
5. Compare personas, empathy maps, and jobs-to-be-done statements, including the design question each answers.

Analytical / Application Questions

1. A university library sees many abandoned online renewal attempts. Design a research-grounded persona, JTBD statement, and current-state scenario for one relevant user pattern. Identify which claims require further evidence.
2. Map the journey of a first-time user applying for financial aid. Identify three moments of truth and convert one into a testable design hypothesis.
3. A service has a clear interface but repeated customer complaints about delayed fulfilment. Explain how you would use a service blueprint to investigate the problem and assign improvement opportunities.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a persona?

A. A fictional biography created to make a presentation engaging

B. An evidence-based archetype representing a recurring user pattern

C. A complete record of every individual user

D. A demographic table used to set legal eligibility

Correct Answer: B. An evidence-based archetype representing a recurring user pattern

Question 2

Which is the strongest jobs-to-be-done statement?

A. I need a dashboard.

B. I want modern software.

C. When travelling, I want to confirm a prescription renewal quickly so I can avoid interrupting treatment.

D. I am a busy professional who likes technology.

Correct Answer: C. When travelling, I want to confirm a prescription renewal quickly so I can avoid interrupting treatment.

Question 3

What is a major risk of an empathy map's “thinks” section?

A. It cannot contain user statements

B. It may encourage unsupported assumptions about mental states

C. It focuses only on organizational processes

D. It excludes all emotional information

Correct Answer: B. It may encourage unsupported assumptions about mental states

Question 4

What should a journey map primarily represent?

A. Only internal departmental responsibilities

B. The user's experience across time, stages, and touchpoints

C. The database schema supporting a service

D. A list of demographic categories

Correct Answer: B. The user's experience across time, stages, and touchpoints

Question 5

Which activity is backstage in a service blueprint?

A. A customer clicking Submit

B. A visible confirmation message

C. A pharmacist reconciling requests in an internal system

D. A user reading a reminder

Correct Answer: C. A pharmacist reconciling requests in an internal system

Question 6

Why should a model distinguish observed evidence from hypotheses?

A. To make all research quantitative

B. To prevent interpretations from being mistaken for established facts

C. To eliminate the need for validation

D. To ensure every persona has the same content

Correct Answer: B. To prevent interpretations from being mistaken for established facts

Question 7

Which segmentation variable is most likely to be directly relevant to a digital service design?

A. Favourite colour, without supporting evidence

B. Frequency of use and connectivity conditions

C. A stereotype associated with age

D. Astrological sign

Correct Answer: B. Frequency of use and connectivity conditions

Question 8

What is a key difference between a current-state and future-state scenario?

A. A current-state scenario describes existing experience; a future-state scenario describes a proposed experience

B. A current-state scenario must be quantitative; a future-state scenario cannot use evidence

C. A current-state scenario concerns staff only; a future-state scenario concerns users only

D. There is no meaningful difference

Correct Answer: A. A current-state scenario describes existing experience; a future-state scenario describes a proposed experience

Question 9

Which practice supports ethical user modelling?

A. Inventing quotations that sound representative

B. Using sensitive traits whenever they make a persona vivid

C. Documenting who was not included and how that limits the model

D. Treating a persona as an eligibility rule

Correct Answer: C. Documenting who was not included and how that limits the model

Question 10

A blueprint shows that a delayed notification results from manual reconciliation between two systems. What does this illustrate?

A. All service problems are caused by visual design

B. Backstage dependencies can shape the user's frontstage experience

C. Journey maps should exclude organizational activity

D. Personas replace operational research

Correct Answer: B. Backstage dependencies can shape the user's frontstage experience