Users, Contexts and Experience Requirements

Introduction

Interaction design begins with an understanding that products are used by people situated in particular circumstances. A user is not simply a demographic profile or an abstract “target market”; a user is a person with goals, abilities, expectations, constraints, emotions and prior experience. Context includes the physical, social, cultural, organisational and technological conditions surrounding use. Experience requirements translate this understanding into actionable statements about what a product must enable, communicate and accommodate.

A poorly researched interface may be visually attractive yet fail because it solves the wrong problem, assumes unreliable connectivity, excludes users with disabilities or demands attention at an unsafe moment. Conversely, a well-defined set of requirements gives designers and developers a reasoned basis for deciding what to build, what content to provide, which interactions to prioritise and how the experience should adapt across devices and situations.

This chapter presents a practical research-to-requirements process. It introduces research findings, personas, scenarios, user stories, jobs-to-be-done and task analysis, then shows how to convert them into functional, content, accessibility and responsive experience requirements.

Learning Objectives

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

• distinguish users, stakeholders, contexts and experience requirements;
• select appropriate qualitative and quantitative research methods;
• synthesise findings into insights and evidence-based design implications;
• create useful personas, scenarios, user stories and jobs-to-be-done statements;
• analyse tasks, dependencies, errors and user effort;
• write functional, content, accessibility and responsive requirements;
• prioritise and validate requirements ethically and collaboratively.

1. From Design Assumptions to Evidence

Design teams often begin with assumptions: “users will understand this icon,” “most customers have fast internet,” or “older people do not use mobile services.” Such statements may be plausible but are not reliable requirements. Research reduces uncertainty by collecting evidence from representative users, existing data and real contexts of use.

A useful distinction is:

• Observation: what was directly seen or recorded.
• Statement: what a participant said or reported.
• Interpretation: a reasoned explanation of evidence.
• Insight: a meaningful pattern that suggests a design opportunity or risk.
• Requirement: a testable condition that the product should satisfy.

For example:

• Observation: Five participants repeatedly returned to the delivery page to find the estimated arrival date.
• Statement: “I want to know whether I need to stay at home.”
• Insight: Delivery information is being used for planning, not merely tracking.
• Requirement: The order screen must clearly present an estimated delivery window and explain what happens if delivery is missed.

The final requirement is stronger than a preference such as “make tracking better” because it identifies information, location and purpose.

Users and stakeholders

A user directly interacts with the product. A stakeholder has an interest in the product or is affected by it, even if they do not use it directly. In a healthcare service, for example, patients, clinicians, carers, administrators, regulators and support staff may all be stakeholders. Their needs can conflict. A patient may want a short form, while a clinician requires sufficient information for safe treatment. Requirements therefore involve negotiation, evidence and ethical judgement.

Context of use

Context can be analysed through several dimensions:

Context is dynamic. A banking app may be used calmly at home, hurriedly at an airport or with assistance from a family member. Requirements should address important variation rather than designing only for an ideal desk-based situation.

2. User Research for Interaction Design

Research methods should be selected according to the question being asked. No single method reveals everything.

Qualitative methods

Interviews explore goals, experiences, motivations and language. Good interviews use open questions, probing and concrete examples rather than asking participants to predict future behaviour. “Tell me about the last time you booked an appointment” is generally more informative than “Would you use an appointment feature?”

Contextual inquiry combines observation and questioning in the user’s environment. It can reveal workarounds, interruptions, physical constraints and informal practices that participants forget to mention in a conventional interview.

Usability testing asks representative participants to attempt realistic tasks using an existing or proposed design. The researcher observes success, hesitation, errors, questions and recovery behaviour. Testing should not be treated as a performance examination of the participant; difficulty often indicates a design problem.

Diary studies collect entries over time and are useful for infrequent, recurring or emotionally changing experiences. They can reveal when a need arises rather than only what users remember in an interview.

Quantitative and behavioural methods

Surveys can identify patterns across a larger sample, but their value depends on clear wording, appropriate sampling and response options. Analytics can reveal abandonment, search terms, device distribution and common paths. Such data describes behaviour at scale but rarely explains why it occurs. A high abandonment rate may result from cost, confusion, technical failure, lack of trust or a change in circumstances.

Accessibility evaluations, support logs, search logs and complaint records are also valuable sources. Research should combine methods where possible: behavioural data indicates what happens, while qualitative research helps explain why.

Sampling and research quality

Certificate-level practitioners do not need to conduct complex statistical studies for every project, but they must avoid obvious bias. Recruit participants who reflect important user groups, tasks and access conditions. Include people who use assistive technologies or have relevant access needs rather than treating accessibility as a later inspection.

Researchers should record method, participant characteristics, setting, prompts and limitations. A finding from three participants is not automatically a population statistic; it may nevertheless reveal a serious usability or accessibility issue. Evidence should be described proportionately.

Ethical practice

Obtain informed consent, explain how data will be used, minimise collection of personal information and protect recordings and transcripts. Avoid coercive recruitment. Participants should be able to withdraw where practicable. Sensitive domains require additional care: health, finance, identity, location and children’s data should not be collected casually. Accessibility research should respect participants as experts in their own experience, not as “problems” to be fixed.

3. Synthesising Research Findings

Raw notes are not requirements. Synthesis involves organising evidence and identifying patterns. A practical process is:

1. Capture observations and quotations separately from interpretation.
2. Group similar evidence into themes such as trust, navigation, timing or terminology.
3. Compare themes across user groups and contexts.
4. Identify needs, barriers, opportunities and contradictions.
5. Record supporting evidence and confidence.
6. Translate prioritised insights into design principles and requirements.

An affinity map can cluster observations, but clustering alone is not analysis. Each theme should answer: What is happening? For whom? In what context? Why does it matter? What evidence supports it?

A useful insight format is:

When [context], [user group] needs to [goal], because [underlying reason or consequence].

Example: “When commuters have weak connectivity, travellers need essential ticket details available without a continuous connection, because platform access may be unreliable and delays create time pressure.”

This insight can generate requirements for offline access, clear status information and rapid retrieval.

4. Personas: Useful Models, Not Fictional Facts

A persona is a research-based representation of a significant user pattern. It helps a team maintain attention on goals, behaviours, abilities and contexts. A persona is not a claim that every user fits one individual, nor should it become a stereotype.

A concise persona may include:

• name and representative image or identifier;
• role and relevant background;
• goals and desired outcomes;
• behaviours and current workarounds;
• frustrations and barriers;
• technical environment and accessibility considerations;
• a quotation grounded in research;
• evidence sources and confidence.

Avoid unnecessary details such as invented favourite colours or elaborate biographies. Such details make a persona appear realistic without improving design decisions.

Personas are most useful when they influence prioritisation. If one persona frequently works one-handed in bright outdoor conditions, that should affect control size, contrast, interaction sequence and error recovery. Teams should revisit personas when research changes and should maintain several when needs genuinely differ.

5. Scenarios and Experience Narratives

A scenario describes a user, goal, context, trigger, sequence and outcome. It explains how a product fits into life or work. Scenarios are broader than task steps because they include circumstances and motivation.

Example scenario:

A commuter receives a notification that a train is cancelled while walking through a crowded station. Using one hand and a poor connection, they need to find an alternative route, confirm whether their existing ticket remains valid and save the relevant information for inspection.

This scenario implies more than “provide journey planning.” It raises questions about notification clarity, one-handed use, offline behaviour, speed, status communication and content hierarchy.

A journey map can extend the scenario across stages such as anticipation, search, decision, use and follow-up. It may show actions, touchpoints, emotions, pain points and backstage processes. The map is a communication and analysis tool, not a substitute for evidence.

6. User Stories and Acceptance Criteria

A user story expresses a need from the user’s perspective:

As a [type of user], I want [capability], so that [benefit].

For example:

As a commuter with limited connectivity, I want to save my ticket details, so that I can show them when the network is unavailable.

A good story is valuable, understandable, negotiable, estimable, small enough to implement and testable. The common format is useful but not mandatory; clarity is more important than ritual.

Acceptance criteria define observable conditions. For the story above, criteria might include:

• the user can save a valid ticket from the ticket screen;
• saved details remain available without network access;
• the screen identifies when information was last updated;
• sensitive payment information is not displayed unnecessarily;
• the user can remove saved information.

Acceptance criteria are not the same as visual specifications. They state required behaviour and quality; designers can explore several interface solutions.

7. Jobs-to-be-Done

The jobs-to-be-done (JTBD) perspective focuses on the progress a person is trying to make in a situation. A job is not simply a product feature. People “hire” products to achieve functional, emotional or social outcomes.

A job statement can be written as:

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

For instance: “When I am preparing for a meeting, I want to find the latest approved version of a document, so I can contribute confidently without presenting outdated information.”

JTBD helps teams avoid feature-led thinking. The job may be served by search, version labels, notifications, permissions or a shared workspace. It also reveals competing alternatives, including paper notes, memory, asking a colleague or doing nothing.

Jobs should be grounded in research. They do not eliminate the need to understand accessibility, culture or detailed tasks. A broad job such as “feel in control of travel” must still be translated into concrete interactions and content.

8. Task Analysis

Task analysis decomposes an activity into goals, subtasks, decisions, information, tools, errors and outcomes. It is particularly useful for complex, frequent, regulated or safety-related work.

A hierarchical task analysis might represent a goal as:

1. Start an application.
2. Identify the required service.
3. Enter personal details.
4. Upload supporting evidence.
5. Review and correct information.
6. Submit and receive confirmation.

For each step, ask:

• What triggers the step?
• What information does the user need?
• What decision is made?
• What can go wrong?
• How does the user recover?
• What system feedback is required?
• Is the step performed by the user, system or another person?

Task analysis can expose hidden work. A user may need to locate a document, convert its format, check its expiry date and obtain permission before uploading it. Designing only the upload control ignores the complete task.

Cognitive and physical effort

Users have limited attention and working memory, especially under stress. Interfaces should support recognition rather than require unnecessary recall, show progress for long processes, preserve entered data and make system status visible. Physical effort matters too: repeated typing, precision pointing, awkward reach and prolonged scrolling can create barriers. Responsive design must consider how input changes across keyboard, mouse, touch, voice and assistive technologies.

Errors and recovery

Errors should be anticipated rather than treated as user failure. Prevent invalid actions where appropriate, but do not hide important choices. Provide specific messages, identify the affected field, explain how to fix the problem and preserve valid input. For destructive actions, provide confirmation or undo according to risk. Recovery is part of the task, not an optional enhancement.

9. Translating Evidence into Experience Requirements

A requirement should be sufficiently specific to guide design and sufficiently testable to support evaluation. Four categories are especially important.

Functional requirements

Functional requirements state what the system must do.

Examples:

• The service must allow a user to filter appointments by date and location.
• The system must save a draft when the user leaves a multi-step form.
• The interface must display a confirmation reference after successful submission.

Avoid prematurely prescribing implementation unless a technical constraint is established. “The system must support draft recovery” is a requirement; “use a particular database table” is an implementation decision.

Content requirements

Content requirements specify information, language, structure and communication needs.

Examples:

• The product must explain eligibility before collecting detailed personal information.
• Error messages must state the problem and the corrective action.
• Delivery estimates must include date, time range and relevant uncertainty.
• Headings and labels must use terms familiar to the intended audience.

Content is part of interaction design. A control cannot be considered usable if its label is ambiguous, and a successful transaction is not communicated by a decorative animation alone.

Accessibility requirements

Accessibility requirements ensure that people with varied abilities can perceive, operate, understand and use the service. They should be included from discovery through testing. Relevant considerations include:

• keyboard access and visible focus;
• logical heading and landmark structure;
• sufficient text contrast and non-colour cues;
• meaningful labels and accessible names;
• captions, transcripts and alternatives for media;
• compatibility with screen readers and magnification;
• scalable text and reflow without loss of content;
• error identification, instructions and recovery;
• adequate touch target spacing and alternatives to complex gestures;
• time limits that can be extended or avoided.

Accessibility conformance should be tested against an appropriate standard and with disabled users where possible. Automated tools detect only some issues; manual keyboard testing, semantic inspection and assistive-technology testing remain necessary.

Responsive experience requirements

Responsive design is not merely shrinking a desktop layout. Requirements should describe how content, hierarchy and interaction adapt to viewport, input method, orientation, density, network and device capability.

Examples:

• The primary task must remain available at narrow widths without horizontal scrolling.
• Essential content must be prioritised before secondary detail on small screens.
• Navigation must remain understandable when expanded or collapsed.
• Controls must support touch and keyboard operation.
• Images and media must not impose unnecessary data costs.
• A network interruption must preserve entered information and communicate status.
• Orientation changes must not cause loss of task progress.

Do not define requirements only by named devices. Breakpoints should respond to content and layout failure, while testing should include a range of real conditions.

10. Prioritising Requirements

Not every desirable requirement can be implemented immediately. Prioritisation should consider user value, risk, evidence, effort, legal obligations and strategic importance. A simple classification is:

This classification should not place accessibility in a lower category merely because it serves a minority group. Barriers affecting access, dignity, safety or legal rights require serious priority. Requirements should also be traceable: link each to research evidence, a user or stakeholder need, design decisions and a test method.

A requirement quality check asks whether it is clear, necessary, consistent, feasible, testable, prioritised and free from unjustified assumptions. Teams should identify conflicts explicitly rather than hiding them. For example, collecting more data may improve administrative efficiency but increase user burden and privacy risk.

11. Applied Case: Community Clinic Appointment Service

The following is an illustrative case, created for learning purposes.

Background

A community clinic wants to replace a telephone-heavy appointment process with a responsive web service. Patients include people using older phones, screen readers, translation support and shared devices. Staff report that many calls concern appointment availability, preparation instructions and cancellation rules rather than clinical questions.

Problem

An initial project brief requests “an online booking form.” Research reveals that the actual experience is broader. Patients must determine which service they need, find a suitable time, understand preparation requirements, provide contact information and know what to do if they cannot attend. Some users abandon the existing form because it asks for information before explaining appointment types. Others miss appointments because preparation instructions are difficult to locate.

Analysis

Interviews and contextual observation identify three recurring patterns:

1. Patients are uncertain which appointment category applies to them.
2. Many users book on mobile devices while distracted or sharing a device.
3. Users need clear confirmation and reminders, but some have limited digital access.

Task analysis shows that the booking task includes preparation, selection, identity information, review, confirmation and follow-up. A persona representing a mobile user with limited confidence highlights the need for plain language, visible progress, saved drafts and non-digital alternatives.

The JTBD statement is: “When I need a clinic appointment, I want to understand the right service and secure a suitable time, so I can prepare correctly and avoid a wasted visit.”

Approach and solution requirements

The team defines the following requirements:

• The service must explain appointment types in plain language before asking for detailed information.
• Users must be able to search or filter available times by service and location.
• The form must show progress and preserve entered data during ordinary navigation or temporary connection loss.
• Preparation instructions must appear in the confirmation and remain accessible afterward.
• Confirmation must include date, time, location, cancellation instructions and a reference number.
• All functions must be keyboard accessible and compatible with semantic labels and screen-reader announcements.
• The layout must reflow on narrow screens without hiding essential instructions.
• Users must be offered a telephone or in-person alternative if online booking is unsuitable.

Acceptance testing includes keyboard-only booking, screen-reader review, small-screen testing, slow-network testing and usability sessions with representative patients. Staff also review whether the service collects only information necessary for booking.

Outcome

The redesigned service reduces confusion by presenting service explanations before the form, separates essential questions from optional information and makes preparation guidance prominent. The project does not assume that digital self-service is appropriate for everyone; it integrates assisted alternatives. The outcome is therefore an improved service experience rather than merely a new interface.

Learning points

The case demonstrates that requirements emerge from the complete situation, not from a feature request. Personas focus attention, scenarios reveal context, JTBD clarifies the desired progress and task analysis exposes hidden steps. Accessibility and responsive behaviour are fundamental requirements, not final-stage visual adjustments.

12. Contemporary Practice and the Role of AI

Design teams increasingly use automated analytics, transcription, clustering and generative AI to accelerate research operations. These tools can help organise large datasets, draft interview summaries or identify recurring terms, but they do not replace researcher judgement. Automated summaries may omit hesitation, context, minority experiences or uncertainty. Sensitive research data should not be uploaded to a service without appropriate contractual, privacy and security review.

AI-generated personas and user stories are especially risky when they are based on stereotypes or invented evidence. A responsible process labels generated material as a draft, verifies every claim against source data and involves diverse reviewers. Requirements concerning automated decision-making should also address explanation, human review, bias monitoring, data minimisation and routes for appeal. The principle is simple: automation may support synthesis, but evidence and accountability remain human responsibilities.

Challenges and Limitations

Research and requirements work has unavoidable limitations. Participants may alter behaviour when observed; memory is incomplete; samples may exclude marginalised groups; organisational priorities may distort findings; and requirements can become obsolete as technology or policy changes. Personas can oversimplify intersectional identities, analytics can privilege measurable actions and stakeholder opinions can be mistaken for user evidence.

These limitations are managed through triangulation, transparent documentation, iterative validation and humility about certainty. Requirements should be revisited after usability testing and after significant changes in technology, service policy or user circumstances. A requirement is a reasoned design commitment, not an unquestionable truth.

Best-Practice Checklist

Before approving an experience requirement, ask:

• Is the need supported by research, policy or a clearly documented constraint?
• Which users and contexts does it concern?
• Does it describe an outcome rather than prematurely prescribe a solution?
• Can the requirement be observed or tested?
• Does it include content, accessibility and responsive implications?
• What happens under interruption, error, low bandwidth or assistive-technology use?
• Is personal data necessary and appropriately protected?
• How will success and unintended consequences be evaluated?

Chapter Summary

Effective interaction design starts with evidence about users, stakeholders and contexts rather than assumptions. Research methods reveal behaviour, motivations, barriers and environmental constraints; synthesis converts those observations into insights. Personas represent significant research patterns, scenarios explain use in context, user stories express capabilities and benefits, jobs-to-be-done focus on the progress people seek, and task analysis exposes steps, decisions, errors and recovery needs.

These tools become valuable when they produce clear requirements. Functional requirements define system behaviour, content requirements define information and communication, accessibility requirements support people with varied abilities, and responsive requirements describe adaptation across devices, input methods, networks and environments. Good requirements are evidence-based, testable, prioritised and traceable. Ethical research, privacy protection, inclusive practice and cautious use of AI are essential to responsible design. The central professional skill is connecting human evidence to decisions that can be designed, built and evaluated.

Key Terms

Accessibility: The extent to which people with varied abilities can perceive, operate, understand and use a product or service.

Acceptance criteria: Observable conditions used to determine whether a requirement or user story has been satisfied.

Context of use: The physical, social, organisational, technological and cultural circumstances surrounding use.

Contextual inquiry: A research method combining observation and questioning in the user’s natural environment.

Experience requirement: A testable statement describing what an interaction or service must enable or communicate.

Functional requirement: A statement of behaviour or capability the system must provide.

Insight: A meaningful, evidence-supported interpretation that reveals a need, barrier or opportunity.

Jobs-to-be-done: A perspective that focuses on the progress a person seeks in a particular situation.

Journey map: A representation of stages, actions, touchpoints and experiences across a service or task.

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

Qualitative research: Research concerned primarily with meanings, experiences, behaviours and explanations.

Quantitative research: Research involving measured data, counts or patterns that can be compared numerically.

Responsive design: Designing an experience to adapt appropriately to changing screens, devices, inputs and conditions.

Scenario: A narrative describing a user pursuing a goal within a particular context.

Stakeholder: A person or organisation affected by, responsible for or interested in a product or service.

Synthesis: The process of organising evidence and developing patterns, themes and implications.

Task analysis: The systematic examination of goals, subtasks, decisions, resources, errors and outcomes.

User research: The systematic study of users, their needs, behaviours and contexts.

User story: A concise statement of a user type, desired capability and expected benefit.

Usability testing: Evaluation in which representative users attempt realistic tasks while researchers study the interaction.

Review Questions

Short Answer Questions

1. Distinguish an observation, an insight and a requirement.
2. What are the main dimensions of context of use?
3. What purpose does a persona serve in interaction design?
4. Define a job-to-be-done and give one example.
5. Why must accessibility and responsive behaviour be addressed during requirements definition?

Long Answer Questions

1. Compare interviews, contextual inquiry and usability testing. Explain the kinds of knowledge each method can provide.
2. Explain how research findings can be synthesised into evidence-based design requirements.
3. Discuss the relationship between scenarios, user stories and acceptance criteria.
4. Describe how task analysis can reveal hidden work and error-recovery needs in a digital service.
5. Explain why responsive design is more than reducing the size of a desktop interface.

Analytical / Application Questions

1. A university enrolment form has high abandonment on mobile devices. Propose a research plan, identify likely contextual factors and write three testable requirements.
2. Create a persona, scenario, JTBD statement and three acceptance criteria for a person arranging a medical appointment online.
3. A product team wants to use AI to generate personas from interview transcripts. Analyse the benefits, risks and governance controls you would recommend.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes an insight from an observation?

A. An insight is a raw record of what a participant did.

B. An insight is an evidence-supported interpretation that reveals a need or opportunity.

C. An insight is always a numerical measurement.

D. An insight is a technical implementation decision.

Correct Answer: B. An insight is an evidence-supported interpretation that reveals a need or opportunity.

Question 2

Which research method combines observation and questioning in the user’s natural environment?

A. Survey research

B. Contextual inquiry

C. A/B testing

D. Card sorting

Correct Answer: B. Contextual inquiry

Question 3

What is the primary purpose of a persona?

A. To represent a research-based pattern of user goals, behaviours and constraints

B. To describe the complete biography of one real customer

C. To replace all usability testing

D. To specify the database structure

Correct Answer: A. To represent a research-based pattern of user goals, behaviours and constraints

Question 4

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

A. Users need a blue booking button.

B. The application must use a particular framework.

C. When preparing for travel, I want reliable ticket information so I can board confidently.

D. The homepage should contain six cards.

Correct Answer: C. When preparing for travel, I want reliable ticket information so I can board confidently.

Question 5

Which item is an acceptance criterion for a saved-ticket user story?

A. The interface should feel modern.

B. The user can access saved ticket details without a network connection.

C. The product team will use responsive design.

D. The persona is a frequent commuter.

Correct Answer: B. The user can access saved ticket details without a network connection.

Question 6

Which is a content requirement?

A. The system must store a draft.

B. The page must use a three-column grid.

C. Error messages must explain the problem and how to correct it.

D. The server must use a specified database.

Correct Answer: C. Error messages must explain the problem and how to correct it.

Question 7

Which practice best supports accessible interaction?

A. Communicating status through colour alone

B. Requiring complex gestures for essential actions

C. Providing keyboard access, visible focus and meaningful labels

D. Disabling text enlargement to preserve layout

Correct Answer: C. Providing keyboard access, visible focus and meaningful labels

Question 8

Why should responsive requirements consider network conditions?

A. Network conditions can affect loading, data costs, interruption and task completion.

B. Network conditions determine the brand colour.

C. Network conditions eliminate the need for accessibility testing.

D. Network conditions matter only on desktop computers.

Correct Answer: A. Network conditions can affect loading, data costs, interruption and task completion.

Question 9

What does task analysis primarily examine?

A. Only the visual style of an interface

B. Goals, subtasks, decisions, resources, errors and outcomes

C. The organisation’s advertising budget

D. The number of colours in a design system

Correct Answer: B. Goals, subtasks, decisions, resources, errors and outcomes

Question 10

Which statement reflects responsible use of AI in user research?

A. AI-generated personas can be accepted without checking source evidence.

B. Sensitive transcripts can always be uploaded to public AI tools.

C. AI may assist synthesis, but claims should be verified and privacy and bias risks governed.

D. AI eliminates the need to involve representative users.

Correct Answer: C. AI may assist synthesis, but claims should be verified and privacy and bias risks governed.