ISO/DIS 25063:2026(en)

ISO/TC 159/SC 4/JWG 28

Secretariat: BSI

Date: 2025-12-05

Systems and software engineering — Systems and software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability: Context of use description

© ISO 2026

All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.

ISO copyright office

CP 401 • Ch. de Blandonnet 8

CH-1214 Vernier, Geneva

Phone: +41 22 749 01 11

Email: copyright@iso.org

Website: www.iso.org

Published in Switzerland

Contents

Foreword v

Introduction vi

1 Scope 1

2 Normative references 1

3 Terms and definitions 1

3.1 Context of use and its components 1

3.2 Other relevant definitions 3

4 Conformance 5

5 Introduction to the Context of use description 5

5.1 Purposes of a context of use description 5

5.2 Inputs to a context of use description 5

5.2.1 General 5

5.2.2 Domain knowledge for a context of use 5

6 Elements of a context of use description 6

6.1 Subject of the context of use description 6

6.1.1 The interactive system (to be designed or evaluated) 6

6.1.2 Business-related objectives 6

6.1.3 Human-centred quality objectives 6

6.1.4 Constraints 7

6.1.5 Relationship between current and intended context of use 8

6.2 User groups 8

6.2.1 Identification of the user groups 8

6.2.2 Task-relevant characteristics of a user group 8

6.2.3 Roles and responsibilities of a user group 9

6.3 Tasks and task-related goals for each user group 9

6.3.1 Tasks 9

6.3.2 Task-related goals 10

6.4 Resources utilized by the user 11

6.5 Environment of users 11

6.5.1 The effect of multiple environments 11

6.5.2 Technical environment(s) 11

6.5.3 Physical environment(s) 12

6.5.4 Social, cultural, and organizational environments 12

6.6 Relationships between components of the context of use 13

6.6.1 General 13

6.6.2 Complexity within the context of use 13

Annex A (informative) Examples for showing relationships within the context of use 15

A.1 General 15

A.2 Relationships illustrated by means of diagrams 15

A.3 Relationships illustrated by means of as-is scenarios 17

Annex B (informative) Approaches to gather context of use information 19

B.1 General 19

B.2 Contextual inquiries and observations 19

B.3 Interview and survey techniques 19

Annex C (informative) Intended context of use 20

Annex D (informative) Structured documents serving as research resources for context of use information 21

Bibliography 23

Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).

ISO draws attention to the possibility that the implementation of this document may involve the use of (a) patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights in respect thereof. As of the date of publication of this document, ISO [had/had not] received notice of (a) patent(s) which may be required to implement this document. However, implementers are cautioned that this may not represent the latest information, which may be obtained from the patent database available at www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.

This document was prepared by Technical Committee ISO/TC 159, Ergonomics, Subcommittee SC 4, Ergonomics of human-system interaction.

This second edition cancels and replaces the first edition (ISO/IEC 25063:2014), which has been technically revised.

The main changes are as follows:

— xxx xxxxxxx xxx xxxx

Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at www.iso.org/members.html.

Introduction

The human-centred design approach of ISO 9241‑210^[4] is well established and focuses specifically on making systems usable. Usability can be achieved by applying human-centred design and testing throughout the life cycle. In order to enable a human-centred approach to be adopted, it is important that all the relevant types of information related to usability (information items) are identified and communicated. This identification and communication enables the usability of a system to be designed and tested.

This International Standard provides a framework and consistent terminology for describing the context of use of an interactive system. This document is intended to be used by requirements engineers, product designers, product evaluators, business analysts, UX researchers, product managers, product owners, and people acquiring interactive systems from third parties.

The Common Industry Format (CIF) for Usability family of International Standards is described in ISO/IEC TR 25060^[19] and is part of the SQuaRE series (ISO/IEC 25000^[17] to ISO/IEC 25099) of standards on systems and software product quality requirements and evaluation.

The CIF family of standards uses definitions that are consistent with the ISO 9241 series of standards (Ergonomics of human system interaction), as this is the terminology that is normally used for this subject matter.

CIF standards are published or planned for the following information items:

— Context of use description (this document);

— User needs report (ISO/IEC 25064);

— User requirements specification (ISO 25065);

— Design specification of user-system interaction and user interface (planned ISO 25067);

— Reporting usability evaluations (ISO 25062);

— Field data report.

The CIF standards are developed by the “Extension Division” of the ISO/IEC 25000 “SQuaRE” series of International Standards (see Table 1).

Table 1 — Organization of SQuaRE series of International Standards

Context of use is defined in ISO 9241‑11^[2]. The quality in use model in ISO/IEC 25019^[19] incorporates context of use.

Table 2 illustrates the interdependence of these information items with the human-centred design processes described in ISO 9241‑220, as well as the corresponding system life cycle processes described in ISO/IEC/IEEE 15288.

While this document specifies the minimum content of the various types of context of use descriptions, ISO 9241‑220 introduces the human-centred design processes including:

— identify the context of use;

— identify user needs;

— specify the user requirements;

— specify the user-system interaction;

— produce and refine user interface design solutions;

— user-centred evaluation.

Table 2 — Relationship of CIF documents to human-centred design in ISO 9241‑220
and system lifecycle processes in ISO/IEC 15288

Systems and software engineering — Systems and software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability: Context of use description

This document specifies the contents of a context of use description for an interactive system to be designed or evaluated.

The context of use description is applicable to all kinds of interactive systems, products, services or a combination of these. The description of the context of use is intended to be used as part of system-level documentation resulting from development processes such as those in ISO 9241‑210 and ISO/IEC JTC 1/SC 7 process standards.

This document does not prescribe any kind of method, life cycle or process.

The context of use information item can be integrated into any type of process model.

NOTE For the purpose of establishing process models, ISO/IEC TR 24774 specifies the format for process models. In addition, ISO/IEC 15289 defines the types and content of information items developed and used in process models for system and software life cycle management. ISO 9241‑220 provides guidance on processes for enabling, executing and assessing human-centred design.

This document also describes the purposes for which a context of use description is used.

While this document specifies the required content components of a context of use description, it does not prescribe any particular structure or layout for documenting the context of use.

There are no normative references in this document.

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminology databases for use in standardization at the following addresses:

— ISO Online browsing platform: available at https://www.iso.org/obp

— IEC Electropedia: available at https://www.electropedia.org/

3.1.1

context of use

combination of users, goals and tasks, resources, and environment

Note 1 to entry: The “environment” in a context of use includes the technical, physical, social, cultural and organizational environments.

[SOURCE: ISO 9241‑11:2018, 3.1.15]

3.1.2

user

person who interacts with a system, product or service

Note 1 to entry: Users of a system, product or service include people who operate the system, people who make use of the output of the system and people who support the system (including providing maintenance and training).

[SOURCE: ISO 9241‑11:2018, 3.1.]

3.1.3

diverse users

individuals with differing abilities and characteristics or accessibility needs

[SOURCE: ISO/IEC Guide 71:2014, 2.3]

3.1.4

stakeholder

individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations

EXAMPLE End users, end user organizations, supporters, developers, customers, producers, trainers, maintainers, disposers, acquirers, suppliers, regulatory bodies, and people influenced positively or negatively by a system.

[SOURCE: ISO/IEC/IEEE 15288:2023, 3.44]

3.1.5

interactive system

combination of hardware and/or software and/or services and/or people that users (3.1.2) interact with in order to achieve specific goals

Note 1 to entry: This includes, where appropriate, packaging, user documentation, on-line and human help, support and training.

[SOURCE: ISO 9241‑11:2018, 3.1.5]

3.1.6

goal

intended outcome

[SOURCE: ISO 9241‑11:2018, 3.1.10]

3.1.7

task

activities required to achieve a goal

Note 1 to entry: These activities can be physical, perceptual and/or cognitive.

Note 2 to entry: While goals are independent of the means used to achieve them, tasks describe particular means of achieving goals.

[SOURCE: ISO 9241‑11:2018, 3.1.11]

3.1.8

resource

asset that is utilised or consumed during the execution of a task

Note 1 to entry: Resource includes diverse entities such as funding, personnel, facilities, capital equipment, tools and utilities such as power, water, fuel, and communication infrastructures.

Note 2 to entry: Resources include those that are reusable, renewable or consumable.

[SOURCE: ISO/IEC/IEEE 15288:2023, 3.37, modified with task replacing process]

3.1.9

environment

external conditions that are likely to influence the performance of a task

Note 1 to entry: This includes the technical, physical and social, cultural and organisational environments that influence the use of a system, product, or service.

3.2.1

information item

separately identifiable body of information that is produced, stored and delivered for human use

[SOURCE: ISO/IEC/IEEE 15289:2019, 3.1.12]

3.2.2

requirement

condition or capability that must be met or possessed by a system, system component, product, or service to satisfy an agreement, standard, specification, or other formally imposed documents

[SOURCE: ISO 9241‑220:2019, 3.30]

3.2.3

user need

prerequisite identified as necessary for a user, or a set of users, to achieve an intended outcome, implied or stated within a specific context of use

EXAMPLE 1 A presenter (user) needs to know how much time is left (prerequisite) in order to complete the presentation in time (goal) during a presentation with a fixed time limit (context of use).

EXAMPLE 2 An account manager (user) needs to know the number of invoices received and their amounts (prerequisite), in order to complete the daily accounting log (goal) as part of monitoring the cash flow (context of use).

Note 1 to entry: A user need is independent of any proposed solution for that need.

Note 2 to entry: User needs are identified based on various approaches including interviews with users, observations, surveys, evaluations, expert analysis, etc.

Note 3 to entry: User needs sometimes represent gaps (or discrepancies) between what should be and what is.

Note 4 to entry: User needs are transformed into user requirements considering the context of use, user priorities, trade-offs with other system requirements and constraints.

[SOURCE: ISO/IEC 25065:2019, 3.1.9, Modified with “often” in Note 3 to entry replaced by “sometimes”]

3.2.4

user requirements

set of requirements for use that provide the basis for design and evaluation of interactive systems to meet identified user needs

Note 1 to entry: User requirements are derived from user needs and capabilities in order to allow the user to make use of the system in an effective, efficient, safe and satisfying manner.

Note 2 to entry: User requirements are not requirements on the users.

Note 3 to entry: User requirements include user-system interaction requirements and use-related quality requirements.

Note 4 to entry: In software engineering terms, user requirements include both “functional” and “non-functional” requirements derived from user needs and capabilities.

[SOURCE: ISO 25065:2019, 3.1.10]

3.2.5

usability

extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use

Note 1 to entry: The “specified” users, goals and context of use refer to the particular combination of users, goals and context of use for which usability is being considered.

Note 2 to entry: The word “usability” is also used as a qualifier to refer to the design knowledge, competencies, activities and design attributes that contribute to usability, such as usability expertise, usability professional, usability engineering, usability method, usability evaluation, usability heuristic.

[SOURCE: ISO 9241‑11:2018, 3.1.1]

3.2.6

accessibility

extent to which products, systems, services, environments and facilities can be used by people from a population with the widest range of user needs, characteristics and capabilities to achieve identified goals in identified contexts of use

Note 1 to entry: Context of use includes direct use or use supported by assistive technologies.

[SOURCE: ISO 9241‑112:2017, 3.15]

3.2.7

system

combination of interacting elements organized to achieve one or more stated purposes

Note 1 to entry: A system is sometimes considered as a product or as the services it provides.

Note 2 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs, firmware, technical documentation, services and personnel required for operations and support to the degree necessary for self-sufficient use in its intended environment.

EXAMPLE A presentation system is composed of a projector used in conjunction with a notebook computer.

Note 3 to entry: A system can be composed of a product, service, built environment or combination thereof, and people.

[SOURCE: ISO 9241‑11:2018, 3.1.4, Modified EXAMPLE added]

3.2.8

product

item that is made or created by a person or machine

EXAMPLE A programmable microwave oven is a consumer product.

[SOURCE: ISO 9241‑11:2018, 3.1.2, Modified EXAMPLE added]

3.2.9

service

means of delivering value for the customer by facilitating results the customer wants to achieve

Note 1 to entry: Services can include both human-system interactions (e.g. accessing a word processor through the web) and human-human interactions (e.g. a citizen interacting with a clerk at the post office counter).

Note 2 to entry: The “customer” is a user, and does not necessarily have a financial relationship.

[SOURCE: ISO 9241‑11:2018, 3.1.6]

A context of use description (current context of use or intended context of use) shall include all the elements specified in 6.1 to 6.6.

There is always some uncertainty about which characteristics of the context of use will definitely affect usability or accessibility and which will not. Therefore, the extent of the description of the context of use is a matter of judgement of the likelihood of the impact of each characteristic on usability. There are risks associated with either underspecifying or over specifying the context of use. Human factors knowledge and any previous experience with this type of interactive system can aid in determining which individual components are relevant to a context of use.

EXAMPLE It would not be necessary to include “sufficient electrical power” when it is usually available in the target location.

A context of use description serves the following purposes:

— understanding how a current interactive system can be used;

— identifying the user needs and/or requirements to be met by an interactive system to be designed;

— evaluating the usability and/or accessibility of an interactive system;

— providing use-related information as part of the description of an interactive system.

A context of use description should be treated as an evolving repository of information. The content of the description will grow as an increasing amount of detail is added during the design process.

NOTE Information about a particular context of use can be used in the development of more than one interactive system.

The description of the context of use provides common information that is needed for use in conjunction with the other information items that are to be produced relating to human centred design. Information about the context of use provides a basis for designing an interactive system that is usable in the intended context of use and helps maintain a human-centred design focus within the project.

Context of use information can be captured in a variety of forms, and descriptions of the context of use can be documented in various formats to meet the needs of particular audiences. Annex B of this document introduces approaches for gathering context information.

Understanding the domain in which the context of use is situated is the basis for gathering information directly with users. This includes technical vocabulary and theoretical concepts that are used in a business or an industry. A prerequisite for researching the context of use with the users of the system is a solid understanding of other sources of context of use information including organizational policies, procedures, roles and responsibilities.

Annex D contains an example framework for how structured information can be organized and catalogued.

The interactive system (to which the current context of use relates) shall be identified. This may be a system that is currently in use or intended to be developed or purchased.

EXAMPLE 1 A new planning tool for ergonomic seating design is to be developed. There is no similar product available, nor a detailed product specification. There is a concept of the product, focusing on the characteristics of the product’s capabilities, design guidelines and innovations to be introduced in the planned interactive system.

EXAMPLE 2 When designing or evaluating the user interface of an existing model of cell phone, both, hardware-based operating functions and software-based operating functions are subject of the context of use description for the current interactive system.

Business-related objectives for those utilizing the interactive system shall be described from the perspective of their impact on the intended use of the interactive system.

NOTE 1 It can be helpful to use unique names for business objectives to ease referring to them.

NOTE 2 Some business-related objectives that could be relevant include:

— task performance times;

— efficiency metrics;

— payment procedures;

— design guidelines;

— corporate design policy;

— promoting specific products and services;

— security issues.

EXAMPLE 1 An organization has mandated the business objective to automate all tasks that don’t need human-system interaction / human intervention.

EXAMPLE 2 An organization has decided to make use of artificial intelligence wherever possible.

A contradiction of business-related objectives and task-related goals might occur. Where such contradictions occur, it is not the role of the context-of-use description to attempt to resolve these contradictions, but merely to identify their occurrence.

EXAMPLE 3 The organization states that entering a phone number is essential for authentication of user data and provides important marketing data. User research indicates that users would prefer not to provide this data.

In case of contradictions between business related objectives and task related goals, each conflict between them shall be identified.

In addition to the business-related objectives for the interactive system, the human-centered quality objectives shall be documented to identify the expected impact for the users and other stakeholders. This consideration can also include optimized cognitive load as well as reduced errors and resulting harm.

Human-centred quality objectives always relate to one or more of the following dimensions:

— usability;

— accessibility;

— user experience;

— avoidance of harm from use.

The following examples of human-centred quality objectives have been taken from ISO 9241‑220.

EXAMPLE 1 Usability: The average time that air passengers entering the country will take to pass through immigration is half the average time currently taken, while maintaining current levels of security and safety in screening arrivals.

EXAMPLE 2 Accessibility: The intended user population explicitly includes users with the widest possible range of diverse human needs and characteristics.

EXAMPLE 3 User experience: Potential users anticipate that the new product will maintain the company’s reputation as the market leader for quality and innovation.

EXAMPLE 4 Avoidance of harm from use: The design of the medical device will ensure that use errors that cause harm are either eliminated or reduced to the extent possible.

Constraints that could affect the design of the interactive system in a way that affects the usability shall be:

— identified with a unique name;

— described from the perspective of their impact on the intended use of the interactive system.

The constraints include design constraints and organizational constraints. The former are imposed from sources other than the organization developing the interactive system whereas the latter are imposed by the organization itself.

EXAMPLE 1 Some design constraints (not imposed by the organization) include:

— legal considerations (also jurisdiction);

NOTE Some legal considerations can include: accessibility, privacy, sustainability.

— available Information (e.g. existing knowledge, research findings);

— business intelligence;

— competition; and

— seasonal determinants (e.g. number of users varies because of holiday season).

EXAMPLE 2 Some development organizational constraints (imposed by the organization) include:

— corporate design;

— budget constraints;

— time constraints for the duration of development and deployment;

— strategic focus of business;

— confidentiality policies; and

— access to users.

When describing the current context of use, the users, current work practises, resources used and environmental conditions present are described. Pain points of users, including operational deficiencies, are also identified. The intended context of use relies on the empirical facts of the current context of use in order to satisfy the underserved needs of the users, eliminate operational deficiencies, and specify appropriate user requirements. Annex C in this document illustrates how to identify the intended context of use based on the current context of use.

People become users because they interact directly or indirectly with the interactive system to accomplish one or more tasks. User groups can be differentiated by the tasks they are performing, their role related to these tasks, their task-relevant characteristics, and the environment in which they are performing these tasks. Each user group can be expected to contain diverse users.

Users are classified as primary or secondary, direct or indirect.

Direct users include:

— primary users are people who carry out the tasks that the interactive system has been designed for (e.g. people printing documents);

— secondary users are people who support primary users (e.g. people maintaining and servicing the printer).

Indirect users include people who receive output from a system, but do not interact with the system (e.g. people using the printed documents in a business meeting).

User groups for the interactive system to designed or evaluated shall be identified in terms of a “user group profile” with:

— a unique name;

— whether the users within each user group represent primary users or secondary users or indirect users;

— the task-relevant characteristics of a user group (see 6.2.2);

— the roles and related responsibilities of the user group related to their tasks (see 6.2.3);

— the tasks that the user group performs and for each task, the task-related goals (see 6.3).

NOTE User group profiles in a context of use description can be accompanied by persona descriptions. A persona is a description of a fictitious but realistic user and what the user intends to do when using the interactive system. Personas can help to provide a deeper understanding of some user groups.

There are an infinite number of possible characteristics that could be used to describe a user group. Only those characteristics that are relevant to the accomplishment of one or more tasks and that are likely to lead to user requirements belong in a context of use description.

Some possible task-relevant characteristics of a user group include:

— skills required to complete the tasks;

NOTE 1 If the range of skills that a user has is not equal to the skills required to complete a task, the interactive system might be able to supplement these skills or provide training to the user.

NOTE 2 Expertise is seldom a useful characteristic, since it is expected that all users will start as novices and some will progress to being experts. Where certain expertise is needed, it can be considered as a skill that is required to complete the task.

— language(s) used;

NOTE 3 The interactive system can be developed for only one or more languages. Understanding the different languages of potential users is important in the development or evaluation of an interactive system.

— beliefs and expectations;

NOTE 4 Some beliefs and expectations can have a strong influence on how a user interacts with an interactive system to perform a task.

— authority over the task;

NOTE 5 There is a difference between the authority over a task and responsibility for completing the task or part of it.

EXAMPLE 1 Some users responsible for completing a task might only have the authority to input data, while other users might have authority to also change or delete the data.

— physical and mental attributes (only if required by the task).

User characteristics shall not be used to discriminate against users or to exclude potential users who otherwise would be part of a particular user group. User characteristics are not absolutes (either always present or always absent) in a user group, but rather they exist as a range of typical attributes that encompass diverse users within a user group.

Each task-relevant characteristic of a user group shall be identified with:

— the characteristic itself;

— a range of the typical values of the characteristic in the user group.

EXAMPLE 2 Completing the annual income tax declaration is a task that can take a long time for the citizen completing it and places stress on the user to remember where they are within the steps of the task. This makes memory capabilities a task-relevant characteristic, which can have values such as: memory capabilities ranging from limited short-term memory to detailed short-term memory.

NOTE 6 The range of the typical values of the characteristics in the user group can affect the testing of the accessibility of the interactive system.

Roles and associated responsibilities are often externally identifiable (e.g. job titles) and can often be easily agreed upon by many different people. Each role has its own responsibilities, expected skills, and level of access to the interactive system.

The responsibilities of a user group are typically determined by the set of tasks that the user group performs. A user’s relationship to the tasks supported by the interactive system is often the basis for naming a user group. However, if the user group has wider responsibilities, those responsibilities can be the basis for naming the user group.

Any responsibilities supported by the interactive system shall be identified in the context of use description.

EXAMPLE A food server in a restaurant is responsible for the tasks “serving food and drinks” as well as presenting the bill and charging for the consumed food and drinks.

The context of use description shall identify all tasks for each identified user group.

In most cases the users will also be performing other tasks, beyond those involving the interactive system to be designed or evaluated.

The context of use description should identify additional tasks that might be supported in a future version of the interactive system.

The following attributes of each task shall be documented:

a) a unique name for each task;

b) the user group(s) that perform(s) the task;

c) task-related goals;

d) contextual precondition(s) that trigger the performance of the task;

e) the sub tasks to be performed during task completion.

The following attributes should also be documented if relevant:

a) whether this is a current or planned task;

b) potential negative consequences with the achievement of goals and execution of tasks or if the task is not completed or is completed incorrectly;

c) pain points experienced during task completion;

d) variability in inputs to be handled (e.g. frequency of input, precision of input, completeness of input);

e) the timing of task occurrence (e.g. time or day, day of the week, etc.);

f) the frequency of the task;

g) the assumed importance of the task;

h) the duration of the task;

i) the complexity of the task;

j) flexibility and discretion in whether and how to carry out the task or task invariance;

k) mental workload of the task (see ISO 10075‑2).

The following relationships should be documented, if relevant:

a) task interdependencies;

b) tasks that are often performed simultaneously as serial/parallel activities;

c) allocation of function between people, and between people and technology.

The context of use description shall identify task-related goals.

Different user groups can have different task-related goals, thus, it is useful to identify particular goals within particular user groups. The task-related goals for using the interactive system shall be stated as the intended outcomes that are available when the corresponding task has been performed successfully.

Task related goals can focus on accomplishing the task and/or achieving satisfaction / positive user experience.

EXAMPLE 1 The task “Following up on unpaid invoices” of a financial accounting clerk (primary user group) in a company has the task-related goal “All due invoices are paid”.

EXAMPLE 2 The task “Showing tourists around town” of a tourist guide employed by the city (primary user group) has the task-related goals “creating personal income for each guided tour” and “receiving positive feedback from each tourist”. From the perspective of the mayor of the city (secondary user), the task has the task-related goals “Producing income for the city” and “increasing the number of tourists” by positive word of mouth.

The resources reported in a context of use description are anything external to the interactive system under consideration that can be expected to be utilized or consumed by the interactive system or the user during the execution of one or more tasks.

[ISO 9241‑11:2018, 7.5.2] Reusable resources include equipment, applications, information and support that are used in conjunction with the object of interest while the user is carrying out the task and that are integral to its completion.

[ISO 9241‑11:2018, 7.5.3] Expendable resources include available time, human effort, financial resources, and materials.

Each resource shall be identified with:

— a unique name for each resource;

— the task(s) for which the resource is used;

— the user group(s) involved with using the resource;

— the quantity of the resource needed to be used.

If resources are only available in certain environments, then the environments in which they are available should be identified.

Interactive systems are used within multiple, overlapping environments that can affect how they are used and what they can accomplish. There are three main types of environments that are particularly relevant:

— technical environment(s);

— physical environment(s);

— social, cultural, and organizational environment(s).

Environments can influence how a user group interacts with an interactive system.

EXAMPLE 1 It is difficult to type or use precise physical inputs in a winter environment that is severe enough to require users to wear gloves or mitts. Recognizing that a user group working outdoors in all weather is distinct from a user group that only works indoors can be important in a context of use description.

A user group can perform their tasks in different environments.

EXAMPLE 2 The user group patient wears a medical device in three physical environments: at home, in public, and at a medical facility.

The technical environment consists of those technical components that enable or constrain the use of the reusable and expendable resources.

A technical environment typically includes access to resources such as furniture, packages, control devices, energy (e.g. electrical, chemical or mechanical) and connectivity (e.g. Internet, cell network).

Each technical environment shall be identified with:

— a unique name for the technical environment;

— a brief description of the relevant characteristics of the technical environment.

NOTE Some relevant characteristics of the environment can include:

— a list of major components of the technical environment;

— the tasks affected by the environment;

— the effect(s) of the technical environment on the performance of these tasks;

— the user group(s) performing tasks in the environment.

The physical environment consists of those physical components or attributes that enable or constrain the performance of tasks.

The physical environment can include components or attributes such as the:

— physical attributes, including spatial, thermal, acoustic and visual conditions, stability and vibration;

— location attributes, including facility-specific information and relevant geographical and/or topographical features;

— timing attributes, including time of day and season.

Each physical environment shall be identified with:

— a unique name for the physical environment;

— a description of the relevant characteristics of the physical environment.

NOTE Some relevant characteristics of the environment can include:

— a list of major components of the physical environment;

— the tasks affected by the environment;

— the effect(s) of the physical environment on the performance of these tasks;

— the user group(s) performing tasks in the environment.

The social, cultural and organizational environment includes:

— other people (including stakeholders),

— roles and relationships between people,

— organizational structures,

— language,

— legislation,

— norms, values, and work practices,

— use in isolation or as part of a group, and

— privacy.

Each social, cultural, and organizational environment shall be identified with:

— a unique name for the social, cultural, and organizational environment;

— a description of the relevant characteristics of the social cultural, and organizational environment.

NOTE Relevant characteristics of the identified environment can include:

— the goals, policies, regulations, and any other attributes of the environment that affect performing tasks;

— the user group(s) involved in the environment and their roles within the environment;

— the tasks affected by the environment;

— the effect(s) of the environment on the performance of these tasks.

The context of use is composed of the following components:

— groups of users;

— resources;

— tasks and task-related goals;

— technical, physical, social, cultural and organizational environments.

The context of use description enables the identification of user needs and specification of user requirements by identifying relationships between these components Relationships and dependencies within a context of use are often outputs of tasks produced by one user group that serve as inputs to tasks of another user group.

EXAMPLE The pilot of an airplane cannot start moving the aircraft to the runway before receiving a notification from the storage compartment that the baggage handler has loaded all luggage.

Identified relationships within the context of use that are likely to contain user needs and lead to user requirements shall be illustrated in the context of use description.

Annex A provides examples of various diagrams and a as-is scenario that can be used to describe relationships between the identified components of the context of use.

Multiple representations of the relationships might be required depending on the complexity of the context of use.

Complexity is influenced by multiple physical, technical, social, cultural and organizational environments in which tasks are performed by users of the interactive system under consideration.

EXAMPLE Levels of complexity of the context of use related to tasks are differentiated by:

a) a single personal task within one user group (e.g. “a flight passenger who checks in for a flight at the airport”);

b) a single business task within a user group (e.g. “an insurance employee processing claims from policy holders”);

c) a set of tasks within a user group as part of their responsibility (e.g. “a team leader in an insurance company who manages the work of their team” involving several tasks such as “assigning claims to different staff depending on complexity of the case” or “reviewing rejected claims before sending them to the affected policy holder” etc.);

d) multiple tasks within one user group that logically follow one another in terms of a “journey” (e.g. a flight passenger who checks in at the airport, then passes security control and then moves to the airplane and board);

e) various user groups with various sets of tasks and dependencies across those user groups as part of a “multi-phase journey” (e.g, at the airport all tasks of flight passengers, customer clerks, baggage handlers and the flight crew and their dependencies).

When describing the context of use, the relationships that contain user needs and can lead to user requirements shall be described using the unique names of:

— the user group(s);

— the task(s) and the task-related goals;

— the resources used by the user group with the task(s);

— the environment(s) in which the user group performs the task(s);

— environment(s) as these relationships are likely to impact on user needs.

NOTE Relationships can exist in the current context of use or can be identified for the intended context of use.

This is typically achieved by diagrams and/or narrative scenario-based descriptions showing the users in conjunction with their tasks / task-related goals, the environment(s) they are in and the resources they use to accomplish their tasks.

1. 
   (informative)
   
   Examples for showing relationships within the context of use
   1. General

This informative annex includes four diagrams and one as-is scenario. The purpose is to illustrate the relationships within the context of use at different levels of complexity related to tasks.

• 1. Relationships illustrated by means of diagrams

Diagrams give an overview of a context of use quickly and enable informed communication within product teams as well as communication with project-external stakeholders. They support team efforts to surface misunderstandings or inaccuracies of documented processes and help identify user needs and derive user requirements.

Figure A.1 shows a template that illustrates all components of the context of use.

Figure A.2 shows an example of how the template (shown in Figure A.1) can be used to illustrate the context of use around the single task “Airplane passenger checking in at the airport”.

Figure A.3 shows an example for a set of tasks following each other in an order (also referred to as “journey”) within the user group “airplane passenger”.

Figure A.4 shows an example that involves multiple user groups with different tasks that relate to each other at an airport.

Figure A.1 — Template for describing the context of use

Figure A.2 — The context of use for one single task “Passenger check-in (at airport)”

Figure A.3 — The context of use in terms of a journey of one user group “airplane passenger”

Figure A.4 — The context of use in terms of a multi-phase journey showing relationships of the tasks within multiple user groups

NOTE For each task stated in Figure A.4 it is advisable to have a detailed illustration as shown in Figure A.2.

• 1. Relationships illustrated by means of as-is scenarios

As-is scenarios use narrative text as an alternative means to diagrams for describing context of use information in a cost-effective way. When interviewing or observing users, the gathered information can easily be represented as a coherent as-is scenario. The scenario contains the target user group, other user group(s) they communicate and interact with, resources used, and a description of the environment. Various analysis techniques have been published that allow for rigorous and structured analysis of narrative scenarios in terms of user needs and user requirements.

The following narrative text describes an as-is scenario for an interactive system to be designed. The interactive system is intended to support the user throughout all phases of their travel journey.

The primary user group is an occasional business traveler. The below as-is scenario covers the portion of the journey for the task “Checking in at the airport.”

Julia is an account manager at a rapidly growing tech company, who travels infrequently. Today she is on a rare business trip to meet a client in another city. Arriving at the airport, she steps out of the taxi with a medium-sized suitcase in tow and a laptop bag slung over her shoulder. Unaccustomed to frequent flying, she feels a bit anxious as she looks up at the busy terminal entrance.

Inside, Julia quickly searches for the airline check-in counter. With a quick scan of her surroundings, she finds it and navigates her way to the queue, noticing a modest crowd ahead of her. She checks her watch nervously, ensuring she has enough time before her flight.

When it’s her turn at the counter, the agent requests her passport and flight confirmation. Julia rummages through her laptop bag, eventually producing the printed itinerary along with her passport. The agent processes everything, and Julia watches anxiously as her suitcase is tagged and sent down the conveyor belt.

Clutching her boarding pass, she proceeds to the security checkpoint. Approaching security, she mentally reviews her last flight over a year ago. “Laptop out, shoes off,” she quietly reminds herself. The line is shorter than expected, but her nerves heighten when she reaches the conveyor belt. Hastily, she extracts her laptop and figures out where to place her shoes and belt.

Balancing her laptop bag and jacket proves challenging, but she manages to send everything through the scanner. Nearing the metal detector, she remembers to remove any metal items and suddenly realizes she still has coins from the taxi fare in her pocket. Embarrassed, she empties her pockets and successfully passes through. Relaxed, she gathers her belongings, quickly shoving her laptop back into her bag without securing it properly.

With a sigh of relief, Julia checks the departure screens and sees "Gate C15." Repeating it to herself, she begins walking. A few minutes of brisk walking reveals the gate is further than she initially thought. As she walks, she absentmindedly checks work emails on her phone while thinking about her upcoming presentation.

Arriving at her gate, she finds that boarding has already begun. She retrieves her boarding pass and passport, fumbling slightly with her laptop bag. After the agent scans her ticket, she heads down the jet bridge, her nerves starting to ease.

Onboard, Julia finds her seat assignment: a window seat. She smiles, looking forward to the view and a moment to relax. She opens the overhead bin above her row and carefully places her laptop bag inside. Though it takes a few tries to navigate around other bags, her purse containing essentials like headphones and a book remains by her side.

Settling into her seat, Julia fastens her seatbelt and starts to unwind. She observes passengers and flight attendants preparing for takeoff. Her laptop is nearby, but she ensures her phone is in airplane mode to avoid errors.

As the final passengers settle in, Julia leans her head against the window, thankful that the most stressful part of the airport experience is over. Taking a deep breath, she closes her eyes for a moment, ready to focus on the tasks ahead.

1. 
   (informative)
   
   Approaches to gather context of use information
   1. General

There is a variety of qualitative and quantitative approaches to identify the context of use.

Data gathering techniques most commonly used include contextual inquiry and interviewing. Clause B.2 and Clause B.3 have been adapted from ISO/TR 62366‑2, clauses 8.4.2 and 8.4.3.

• 1. Contextual inquiries and observations

Contextual inquiries are a common and effective way to learn about prospective or actual users, their tasks, the resources they use and the physical, social and technical environment they are in. A contextual inquiry is an interview technique in combination with an observation, which is conducted in the user’s actual workplace. The user researcher / context analysist observes users, while they are performing their tasks and discusses with them what they do and why. The method is typically used in the early stages of the human-centred design process and helps to gain a thorough understanding about the context of use of each user group for which the interactive system is developed.

• 1. Interview and survey techniques

In contrast to contextual inquiries, interviews and surveys can be conducted at any location and are not necessarily bound to the user’s workplace. They help to gain insights into the user’s knowledge, perceptions or opinions. Interviews can be used as a stand-alone method or to supplement other methods (e.g. contextual inquiries) by following up on the observations made during the prior session. Since interviews can be conducted remotely, they are often less expensive compared to contextual inquires and can target a larger group of respondents. Interviews can be conducted in a one-on-one manner or as group interviews. A very large group of users or stakeholders can be approached by conducting surveys.

1. 
   (informative)
   
   Intended context of use

In order to design and assess the impact of a planned interactive system on the productivity of an organization, the efficiency of the users as well as their satisfaction, the current context of use is documented. The current context of use includes existing pain points as well as process-related deficiencies. The design of an intended context of use in terms of a planned state can then be determined. With complex interactive systems with multiple user groups, it is likely that there will be several iterations to a final design solution and its adoption. Through observation, examination of required inputs, produced outputs and process decisions, risk assessment and role interactions, the opportunities for improvements can be identified.

Using the example of an airplane traveler who travels with luggage to be checked in, a proposal for the intended context might capture the separation of the passenger experience and their baggage experience, i.e. check-in baggage is picked up at the passenger’s desired location and independently delivered to the airport and processed. This would impact roles, technology, decision-making, interactions, durations and error handling.

Considerable efforts are necessary to communicate with all stakeholders regarding the need and benefits of such a project proposal.

Since the effect of the intended context of use on users and organization is yet unknown, success criteria can be important to verify the achieved improvement. Verifiable success criteria can be assigned to human-centred quality objectives to evaluate whether the intended context of use in conjunction with the designed / re-designed interactive system is a success. With complex multiphase processes/journeys, the implementation of change can be broken down into smaller iterations (trials) with changes introduced over a period of time. Sustainability of human-centred design is achieved by a life-cycle approach that identifies how continued evolution impacts efficiency.

1. 
   (informative)
   
   Structured documents serving as research resources for context of use information

The range of information related to the context of use that is collected and examined before or after interviewing and/or observing users can be considerably high. The following Table D.1 provides a framework for how structured information can be organized and catalogued.

Table D.1 — Structured documents serving as research resources for context of use information

In more mature organizations, the documents listed in Table D.1 are controlled and used to support user responsibilities and quality of work to be done. As the project team collects and reviews these documents, the context of use can be determined. This research can be collected in a project repository and used for design input. Mature organizations might share the context of use information with other project teams or research units within the company.

Bibliography

[1] ISO 9241‑11:2018, Ergonomics of human-system interaction — Part 11: Usability: Definitions and concepts

[2] ISO 9241‑110:2020, Ergonomics of human-system interaction — Part 110: Interaction principles

[3] ISO 9241‑112:2017, Ergonomics of human-system interaction — Part 112: Principles for the presentation of information

[4] ISO 9241‑115:2024, Ergonomics of human-system interaction — Part 115: Guidance on conceptual design, user-system interaction design, user interface design and navigation design

[5] ISO 9241‑210:2019, Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems

[6] ISO 9241‑220:2019, Ergonomics of human-system interaction — Part 220: Processes for enabling, executing and assessing human-centred design within organizations

[7] ISO 10075‑2:2024, Ergonomic principles related to mental workload — Part 2: Design principles

[8] ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes

[9] ISO/IEC 15289:2006, Systems and software engineering — Content of systems and software life cycle process information products (Documentation)

[10] ISO/IEC/IEEE 24765:2017, Systems and software engineering — Vocabulary

[11] ISO/IEC 25000:2014, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE

[12] ISO/IEC 25010:2011, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models

[13] ISO/IEC/TR 25060:2023, Systems and software engineering — Systems and software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability — General framework for usability-related information

[14] ISO 26800:2011, Ergonomics — General approach, principles and concepts

[15] International Usability and User Experience Qualification Board e. V. (UXQB). “CPUX-UR Curriculum – Certified Professional for Usability and User Experience – User Requirements Engineering”, [2023-03-11] ^[1]

1. https://uxqb.org/public/documents/CPUX-UR_EN_Curriculum.pdf ↑