Problem Definition and Experience Modelling

Introduction

User research does not automatically produce a good design. Interviews, observations, surveys and support records generate evidence, but evidence becomes useful only when it is interpreted carefully and translated into a clear design direction. Problem definition and experience modelling provide that translation.

Problem definition identifies the human need, the context in which it occurs, its consequences and the opportunity for improvement. Experience modelling represents how people think, feel and act across a task or service. Together, these practices help designers move from broad observations—such as “users find the service difficult”—to precise, actionable statements such as “first-time applicants need a way to understand which documents are required before beginning an application.”

This chapter presents a practical sequence: synthesising research, identifying needs and insights, constructing personas and empathy maps, applying jobs-to-be-done, mapping journeys and scenarios, writing problem statements, and defining measurable design requirements. The objective is not to produce attractive documentation. It is to improve design decisions by making assumptions visible, grounding decisions in evidence and defining what success means.

Learning Objectives

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

1. Distinguish observations, needs, insights, assumptions and design opportunities.
2. Organise qualitative research into meaningful themes without losing evidence.
3. Create evidence-based personas and empathy maps.
4. Use jobs-to-be-done to describe user motivation and desired progress.
5. Model experiences with journey maps and scenarios.
6. Write focused problem statements and “How might we?” questions.
7. Translate user problems into measurable, testable design requirements.
8. Recognise ethical, methodological and practical limitations of experience models.

From Research Evidence to Design Direction

Research evidence may be qualitative, quantitative or behavioural. A usability observation, for example, may reveal that a participant repeatedly opens the help page. A survey may show that 62% of respondents are uncertain about delivery dates. An interview may reveal that people fear making an irreversible mistake. Each item is useful, but none alone is a complete problem definition.

Several terms should be kept distinct:

A need is not the same as a requested feature. A participant might request a “calendar button,” but the underlying need may be confidence that an appointment has been recorded correctly. Starting with the need keeps the design open to better solutions.

Triangulation and Evidence Quality

Triangulation means examining a question through more than one source or method. For example, interview claims about difficulty can be compared with observed behaviour, task-completion data and customer-support records. Agreement across sources increases confidence, although it does not prove that an interpretation is universally true.

A useful evidence record includes the source, date, participant or segment, context, direct evidence, interpretation and confidence level. Designers should preserve quotations and behavioural details rather than recording only conclusions. This creates an audit trail from research to design decision.

Research synthesis should also distinguish frequency from importance. A problem mentioned by only one participant may be critical if it creates serious harm or blocks access. Conversely, a frequently mentioned preference may have little effect on task success. Prioritisation should therefore consider prevalence, severity, user impact, strategic relevance and confidence in the evidence.

Synthesising Research into Insights

Synthesis is the process of finding patterns and relationships in research material. It is not simply summarising each interview. A common approach is affinity mapping:

1. Extract concise observations or quotations from the raw data.
2. Put one idea on each note or record.
3. Group items that appear related.
4. Name each group with a descriptive, neutral label.
5. Compare groups across participants and contexts.
6. Form interpretations and test them against the original evidence.

Labels should describe a pattern rather than prescribe a solution. “Users need a dashboard” is a solution-oriented label. “Users struggle to see the status of several requests” describes a problem more usefully.

An insight often has the structure:

When [context], [user] needs [need] because [underlying reason or barrier], which results in [consequence].

For example: “When residents apply for several permits, they need a clear view of progress because confirmation messages are scattered across channels, which results in repeated calls to the council.” This statement connects context, need, cause and consequence. It can guide several possible solutions rather than prematurely selecting one interface element.

Avoiding Common Synthesis Errors

Designers can distort research through confirmation bias, overgeneralisation and premature solutioneering. Confirmation bias occurs when evidence is selected mainly because it supports an existing idea. Overgeneralisation occurs when a small or unusual experience is treated as typical. Premature solutioneering occurs when the team jumps from a quotation to a feature.

To reduce these risks, teams should record contradictory evidence, identify the limits of the sample, invite multiple researchers to review themes and return to original data during synthesis. A theme should be supported by evidence, but it should not be presented as a universal fact when the research only covers a particular group or context.

Personas: Representing Relevant User Patterns

A persona is a research-based representation of a meaningful user pattern. It is not a fictional biography created to decorate a presentation. A useful persona describes goals, behaviours, capabilities, constraints, motivations and context relevant to the design problem.

A persona may include:

• a role or descriptive name;
• context of use and important environmental conditions;
• goals and desired outcomes;
• behaviours and current workarounds;
• abilities, access needs and technical confidence;
• frustrations, risks and constraints;
• representative evidence and confidence level.

Personas should be based on behavioural or needs-based patterns, not stereotypes. Age, occupation or gender may be relevant in some studies, but demographic detail should not be used as a substitute for evidence. A persona should answer: “What design decisions will this representation help us make?”

A primary persona represents the user whose needs the product must serve especially well. Secondary personas have legitimate needs that should also be considered. Anti-personas describe groups outside the intended scope; they can clarify boundaries but must not be used to justify exclusion from essential services.

Personas are hypotheses that can be revised. They should include a research basis, such as “constructed from six interviews and three observation sessions,” and should be retired or updated when new evidence contradicts them. Teams should never treat a persona as permission to ignore real users.

Empathy Maps: Understanding Experience, Not Performing Empathy

An empathy map organises evidence around what a person says, does, thinks and feels. Some versions also include pains and gains. It helps a team consider the difference between public behaviour and private interpretation.

The “thinks” and “feels” sections require care. Designers must not invent internal states merely because they sound plausible. Such statements should be supported by direct language, behaviour, contextual knowledge or explicit research questions. An empathy map is a synthesis aid, not a psychological diagnosis.

Jobs-to-be-Done

Jobs-to-be-done (JTBD) focuses on the progress a person is trying to make in a situation. A job is not necessarily a product function. For example, a person may “hire” a banking application to transfer money, but the broader job is to make sure a family member receives funds on time and with minimal uncertainty.

A useful job statement is:

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

Example: “When I arrive at an unfamiliar clinic, I want to find the correct department quickly, so I can attend my appointment without asking strangers for help.”

JTBD can be examined at three levels:

• Functional job: the practical task, such as comparing plans.
• Emotional job: how the person wants to feel, such as confident or in control.
• Social job: how the person wants to be perceived, such as responsible or competent.

The framework is useful because it separates the desired progress from the current product. It can reveal competition between different solutions: a person may use a spreadsheet, a reminder, a colleague or an application to accomplish the same job. However, JTBD should not be treated as a complete theory of human behaviour. Social relationships, identity, accessibility, institutional power and cultural context may be equally important.

Journey Maps

A journey map represents an experience over time. It may cover a single task, a service episode or a longer relationship. A typical map includes stages, user actions, goals, thoughts and feelings, touchpoints, pain points, backstage processes and opportunities.

A journey map is most useful when it has a defined:

• actor or user group;
• scope and start and end points;
• scenario or goal;
• evidence base;
• level of detail.

For example, “using the library” is too broad. “Finding and borrowing a reserved book as a new student” is more specific. Stages might be search, reservation, arrival, identification, collection and follow-up.

The map should include the whole service, not only the screen under the design team’s control. A poor digital experience may be caused by a missing email, an unclear staff procedure, a policy constraint or a physical environment. Mapping frontstage and backstage activity helps identify such dependencies.

A simple prioritisation model can help teams decide which moments merit further investigation. One practical, non-mathematical method is to rank each moment from low to high on user impact and organisational feasibility. This is a decision aid, not an objective measurement. Scores should be explained and revisited when evidence changes.

Journey maps can be current-state maps, showing what happens now, or future-state maps, showing a proposed experience. They must be labelled clearly. Confusing an aspirational future state with observed reality can conceal unresolved problems.

Scenarios and Story-Based Modelling

A scenario is a concise description of a user, situation, goal and sequence of activity. Scenarios provide context for design and usability evaluation. A strong scenario includes:

• who is acting;
• what has happened before the interaction;
• the user’s goal;
• relevant constraints;
• the desired outcome.

For example: “Mina is travelling by bus to a new workplace. Her phone has 15% battery remaining and intermittent connectivity. She needs to find the entrance and save directions before leaving the bus.” This scenario exposes constraints that a generic instruction such as “find directions” would omit.

Scenarios should avoid prescribing interface controls. “Tap the blue button labelled Save” tests whether a particular procedure works, whereas “save directions for later use” describes the user goal. The former may be appropriate for a detailed test script, but the latter is better for early design exploration.

Task flows complement scenarios by showing decisions and actions. They can reveal loops, hand-offs, failure states and points where users need information. Designers should model normal, alternative and error paths. A service that works only when every condition is ideal is not a robust service.

Problem Statements and Opportunity Questions

A problem statement defines a user-centred problem without dictating the solution. It commonly includes the user, context, need and consequence:

[User group] needs a way to [achieve need] when [context], because [evidence-based reason or consequence].

Example: “First-time renters need a way to understand the total move-in cost before submitting an application, because separate fees are revealed at different stages and unexpected costs cause them to abandon the process.”

A strong problem statement is specific enough to guide design but broad enough to permit alternative solutions. It should not embed an unsupported solution, such as “users need a larger button.” It should also avoid blaming users: “users fail to read instructions” may conceal a communication problem.

“How might we?” questions turn a problem into an opportunity for exploration. The question should be neither too narrow nor so broad that every idea fits. For the example above: “How might we help first-time renters understand the full financial commitment before they apply?”

Problem statements should be checked against four tests:

1. Is the affected user or group clear?
2. Is the context and consequence clear?
3. Is the statement supported by evidence?
4. Does it avoid prescribing a particular solution?

From Problems to Measurable Design Requirements

Design requirements translate needs into conditions that a product or service should satisfy. Requirements may be functional, content-related, accessibility-related, performance-related or service-related.

A requirement should identify the actor, required capability, conditions and success criterion. Compare:

• Weak: “The interface should be simple.”
• Stronger: “A first-time applicant should be able to identify the documents required for their application before entering personal information.”
• Measurable: “In moderated usability testing, at least 8 of 10 first-time applicants should identify all required documents within two minutes without facilitator assistance.”

The last statement is measurable, but its threshold is a design decision rather than a universal law. The team must justify the sample, task, time limit and success definition. Measures should fit the risk and maturity of the project.

Useful requirement categories include:

Requirements should be prioritised. A simple method is to classify them as essential, important or desirable, while recording rationale and dependencies. More formal methods, such as weighted scoring, can be used when several stakeholders must compare options. Scores are not facts; they express assumptions and should be transparent.

Measuring Experience

Potential measures include task success, error rate, time on task, abandonment, confidence, satisfaction, repeat contact and accessibility barriers. A measure is meaningful only when its operational definition is clear. “Success” might mean completing the task independently, not merely reaching the final screen.

Quantitative measures should not replace qualitative understanding. A high completion rate may hide confusion, workarounds or unequal outcomes between user groups. Designers should examine disaggregated results where ethically and statistically appropriate, especially for accessibility and inclusion. Do not collect sensitive demographic data unless it is necessary, proportionate and governed responsibly.

Worked Application: Improving a Community Clinic Appointment Service

The following is a fictional illustrative case.

Background

A community clinic reports that patients frequently call reception after using its appointment website. The calls concern uncertainty about appointment confirmation, required documents and arrival location. The clinic wants to reduce avoidable calls while improving patient confidence.

Research Evidence

The design team observes eight appointment attempts, interviews six patients and two receptionists, reviews 120 support-call records and conducts a content audit. Evidence shows that:

• confirmation messages use different wording across email and text;
• the arrival location is shown only after booking;
• patients are unsure whether an interrupted session was saved;
• receptionists maintain a separate internal process for correcting booking errors;
• patients with limited English proficiency rely on family members to interpret instructions.

These findings do not mean every patient has the same problem. They indicate several recurrent points of uncertainty and an operational dependency.

Synthesis and Model

A primary persona is “Leila,” a patient who books appointments for herself and sometimes for a parent. Her relevant characteristics are limited time, moderate digital confidence, a need to coordinate transport and a preference for clear confirmation. Her persona is based on observed behaviours, not on an assumed demographic profile.

Her job statement is: “When arranging a clinic visit, I want to know that the booking is secure and understand where and when to arrive, so I can organise transport without contacting reception.”

A current-state journey includes:

1. Need arises: Leila receives a referral.
2. Search: She finds the clinic website and looks for appointment information.
3. Booking: She enters details but cannot tell whether progress is saved.
4. Confirmation: A message confirms the time but not the entrance or documents.
5. Preparation: She calls reception to verify requirements.
6. Arrival: Signage does not clearly distinguish the clinic entrance.

The central problem statement is: “Patients arranging clinic appointments need a reliable way to understand booking status and arrival requirements before the visit, because fragmented messages and late-revealed information create uncertainty and unnecessary calls.”

Requirements and Proposed Direction

The team defines initial requirements:

• The service must display appointment status after each completed booking step.
• The confirmation must state date, time, location, entrance information and required documents in plain language.
• Users must be able to retrieve confirmation later without repeating the booking process.
• The service must provide an accessible text alternative to any visual directions.
• Staff must be able to correct booking information and trigger a consistent confirmation message.

The proposed direction is not merely a redesigned confirmation page. It includes consistent content, a retrievable appointment record, clearer service ownership and staff support for corrections. A prototype is tested with patients who have different levels of digital confidence and language support needs.

Outcome and Learning Points

In this illustrative case, the first prototype improves understanding of arrival requirements, but testing reveals that some users interpret “confirmed” as “the clinic has approved all documents.” The team therefore changes the content to distinguish appointment confirmation from document verification. This demonstrates why wording must be tested, not assumed.

The case illustrates five principles: map the whole service, distinguish user needs from requested features, include backstage processes, test interpretations of content, and define success before claiming improvement.

Ethical and Professional Considerations

Experience models influence decisions and can therefore create harm if they misrepresent people. Designers should obtain informed consent for research, explain recording and use of data, protect identities and limit collection to what is necessary. Sensitive information should not be copied into personas or journey maps merely because it is available.

Researchers should consider power relationships. Patients, employees, children, migrants and people receiving public services may feel unable to refuse participation. Compensation, recruitment and consent procedures should be appropriate to the context. Accessibility should be built into research activities rather than treated as a later adjustment.

AI tools can assist with transcription, clustering or draft synthesis, but they introduce risks of inaccurate interpretation, privacy breaches, hidden bias and fabricated quotations. Human researchers must verify outputs against source data, avoid uploading confidential material to unapproved systems and disclose meaningful use of automated analysis. AI-generated personas are not evidence-based unless grounded in real research.

Models can also reinforce stereotypes. A persona that describes a disabled person only through limitations, for example, may lead to deficit-oriented design. Inclusive practice represents capabilities, goals, environments and barriers, and involves affected people in evaluating interpretations.

Limitations and Best Practices

No model captures the complete human experience. Personas simplify variation; empathy maps can overstate emotions; journey maps may imply a linear process; JTBD can underrepresent identity and social power; requirements can create false precision. These tools should be used as shared working models, not as reality itself.

Best practices include:

• connect every significant claim to evidence;
• label facts, interpretations and assumptions separately;
• define the scope and audience of each model;
• include edge cases and failure states;
• represent accessibility and environmental constraints;
• invite stakeholders and users to challenge interpretations;
• revise models when new research appears;
• link requirements to validation methods and owners;
• distinguish current-state evidence from future-state aspiration;
• use models to make decisions, not to produce documentation for its own sake.

Contemporary Practice

Modern product teams increasingly combine qualitative research with behavioural analytics, service blueprints, accessibility testing and continuous discovery. Digital products can reveal patterns at scale, but analytics cannot explain why an action occurred and may systematically exclude people who do not use the tracked channel. Conversational interfaces, personalisation and automated decision systems make problem definition more important because users may not know which system is acting or how to correct an error.

Designers must therefore define not only interface requirements but also transparency, human escalation, data governance and accountability. A successful experience is one that supports meaningful user goals fairly and safely, not merely one that increases clicks or reduces contact with staff.

Chapter Summary

Problem definition translates research into a focused account of who experiences a problem, in what context, why it matters and what opportunity exists for improvement. Effective synthesis distinguishes observations, needs, insights, assumptions, opportunities and requirements. Personas represent evidence-based user patterns; empathy maps organise what users say, do, think and feel; and jobs-to-be-done describe the progress people seek in a situation.

Journey maps show experiences across time and touchpoints, while scenarios and task flows provide context for design and evaluation. A good problem statement is user-centred, evidence-based and solution-neutral. Measurable requirements convert needs into testable conditions, including functional, content, accessibility, performance, safety and service requirements.

These models are simplified and potentially biased. They must be grounded in evidence, ethically produced, inclusive, revised over time and connected to validation. The professional goal is not to create impressive artefacts, but to improve the quality, fairness and measurability of design decisions.

Key Terms

Observation: Directly seen, heard or measured evidence.

Need: A condition or capability a user requires to achieve a meaningful outcome.

Insight: An evidence-based interpretation explaining a pattern and its significance.

Assumption: A belief that has not yet been adequately verified.

Opportunity: A possible area for improving a user or service experience.

Triangulation: Comparing multiple sources or methods to examine the same issue.

Affinity mapping: Grouping related research observations to identify patterns.

Persona: A research-based representation of a relevant user pattern.

Primary persona: The user representation whose needs receive central design priority.

Empathy map: A framework organising evidence about what users say, do, think and feel.

Jobs-to-be-done: A framework describing the progress a person seeks in a situation.

Functional job: The practical task a person is trying to accomplish.

Journey map: A time-based representation of actions, thoughts, feelings and touchpoints.

Scenario: A contextual story describing an actor, situation, goal and constraints.

Task flow: A representation of actions, decisions and paths through a task.

Problem statement: A focused description of a user problem without prescribing a solution.

How-might-we question: An opportunity-oriented question that opens design exploration.

Design requirement: A condition a product, service or system should satisfy.

Current-state map: A representation of an existing experience.

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

Review Questions

Short Answer Questions

1. What is the difference between an observation and an insight?
2. Why should a persona be based on behavioural patterns rather than stereotypes?
3. What three elements are commonly included in a jobs-to-be-done statement?
4. How does a journey map differ from a scenario?
5. Why should design requirements include measurable success criteria?

Long Answer Questions

1. Explain a research-synthesis process from raw observations to a validated insight. Include methods for reducing confirmation bias.
2. Describe the purposes, contents and limitations of personas and empathy maps.
3. Explain how current-state and future-state journey maps can support service design.
4. Discuss how a problem statement can remain solution-neutral while still guiding design activity.
5. Describe the ethical responsibilities involved in constructing and using experience models.

Analytical / Application Questions

1. A university portal has a high rate of incomplete scholarship applications. Users say the form is “too long,” but observations show that they repeatedly search for eligibility information. Construct a need, insight, problem statement and one measurable requirement.
2. Create a current-state journey outline for a person returning an online purchase. Identify at least two frontstage touchpoints, one backstage dependency and one possible design opportunity.
3. A team proposes an AI-generated persona based only on website analytics. Evaluate the proposal and recommend the additional evidence and governance controls required before using the persona in design decisions.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a user need from a requested feature?

A. A need describes the underlying outcome or condition; a feature is one possible solution.

B. A need is always quantitative; a feature is always qualitative.

C. A need is supplied by managers; a feature is supplied by users.

D. A need applies only to physical products; a feature applies only to services.

Correct Answer: A. A need describes the underlying outcome or condition; a feature is one possible solution.

Question 2

What is the primary purpose of triangulation in UX research?

A. To replace interviews with analytics

B. To compare multiple sources or methods when examining an issue

C. To ensure every participant gives identical answers

D. To convert qualitative data directly into requirements

Correct Answer: B. To compare multiple sources or methods when examining an issue

Question 3

Which item is most appropriate for a research-based persona?

A. An invented celebrity quotation

B. A detailed biography unrelated to the design problem

C. Relevant goals, behaviours, constraints and evidence

D. A guaranteed prediction of every user’s behaviour

Correct Answer: C. Relevant goals, behaviours, constraints and evidence

Question 4

Which statement is a jobs-to-be-done formulation?

A. The application must contain a calendar icon.

B. Users prefer blue buttons.

C. When travelling, I want to save directions so I can find the entrance without connectivity.

D. The service should reduce its number of screens.

Correct Answer: C. When travelling, I want to save directions so I can find the entrance without connectivity.

Question 5

What should a well-scoped journey map define?

A. Only the colours used in the interface

B. The actor, scenario, scope and start and end points

C. Only the organisation’s internal workflow

D. A final solution before research begins

Correct Answer: B. The actor, scenario, scope and start and end points

Question 6

Which problem statement is most solution-neutral?

A. Users need a larger red submit button.

B. Users need a chatbot on every page.

C. First-time applicants need to understand total costs before submitting because fees appear at different stages.

D. The design team should rebuild the checkout.

Correct Answer: C. First-time applicants need to understand total costs before submitting because fees appear at different stages.

Question 7

Which requirement is the most measurable?

A. The interface should be intuitive.

B. The service should feel modern.

C. Users should like the confirmation page.

D. At least 8 of 10 first-time users should identify all required documents within two minutes without assistance.

Correct Answer: D. At least 8 of 10 first-time users should identify all required documents within two minutes without assistance.

Question 8

Why should “thinks” and “feels” in an empathy map be supported by evidence?

A. To prevent designers from presenting speculation as user fact

B. To make the map longer

C. To ensure all users have the same emotions

D. To eliminate the need for interviews

Correct Answer: A. To prevent designers from presenting speculation as user fact

Question 9

What is a key limitation of journey maps?

A. They cannot represent time or touchpoints.

B. They always provide statistically representative results.

C. They simplify experience and may incorrectly imply a linear process.

D. They can only be used for physical services.

Correct Answer: C. They simplify experience and may incorrectly imply a linear process.

Question 10

What is an important governance practice when using AI for research synthesis?

A. Accepting generated quotations without checking source data

B. Uploading all confidential research to any free AI tool

C. Verifying outputs against source data and protecting sensitive information

D. Allowing AI to define the final problem without researcher review

Correct Answer: C. Verifying outputs against source data and protecting sensitive information