prEN ISO 25063

SLOVENSKI STANDARD
01-marec-2026
Sistemi in programska oprema - Zahteve za kakovost in vrednotenje sistemov in
programske opreme (SQuaRE) - Skupni industrijski format (CIF) za uporabnost:
kontekst opisa uporabe (ISO/DIS 25063:2026)
Systems and software engineering - Systems and software product Quality
Requirements and Evaluation (SQuaRE) - Common Industry Format (CIF) for usability:
Context of use description (ISO/DIS 25063:2026)
System- und Software-Engineering - Qualitätskriterien und Bewertung von Systemen
und Softwareprodukten (SQuaRE) - Allgemeines Industrieformat (CIF) zur
Gebrauchstauglichkeit: Nutzungskontextbeschreibung (ISO/DIS 25063:2026)
Ingénierie des systèmes et du logiciel - Exigences de qualité et évaluation des systèmes
et du logiciel (SQuaRE) - Format industriel commun (CIF) pour l'utilisabilité: Description
du contexte d'utilisation (ISO/DIS 25063:2026)
Ta slovenski standard je istoveten z: prEN ISO 25063
ICS:
35.080 Programska oprema Software
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
International
Standard
ISO/DIS 25063
ISO/TC 159/SC 4
Systems and software
Secretariat: BSI
engineering — Systems and
Voting begins on:
software product Quality
2026-01-30
Requirements and Evaluation
Voting terminates on:
(SQuaRE) — Common Industry
2026-04-24
Format (CIF) for usability: Context
of use description
Ingénierie des systèmes et du logiciel — Exigences de qualité
et évaluation des systèmes et du logiciel (SQuaRE) — Format
industriel commun (CIF) pour l'utilisabilité: Description du
contexte d'utilisation
ICS: 35.080
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS.
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Reference number
ISO/DIS 25063:2026(en)
DRAFT
ISO/DIS 25063:2026(en)
International
Standard
ISO/DIS 25063
ISO/TC 159/SC 4
Systems and software
Secretariat: BSI
engineering — Systems and
Voting begins on:
software product Quality
Requirements and Evaluation
Voting terminates on:
(SQuaRE) — Common Industry
Format (CIF) for usability: Context
of use description
Ingénierie des systèmes et du logiciel — Exigences de qualité
et évaluation des systèmes et du logiciel (SQuaRE) — Format
industriel commun (CIF) pour l'utilisabilité: Description du
contexte d'utilisation
ICS: 35.080
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
© ISO 2026
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
BE CONSIDERED IN THE LIGHT OF THEIR
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
or ISO’s member body in the country of the requester.
NATIONAL REGULATIONS.
ISO copyright office
RECIPIENTS OF THIS DRAFT ARE INVITED
CP 401 • Ch. de Blandonnet 8
TO SUBMIT, WITH THEIR COMMENTS,
CH-1214 Vernier, Geneva
NOTIFICATION OF ANY RELEVANT PATENT
Phone: +41 22 749 01 11
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland Reference number
ISO/DIS 25063:2026(en)
ii
ISO/DIS 25063:2026(en)
Contents Page
Foreword .iv
Introduction .v
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 . 4
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 .7
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
Annex B (informative) Approaches to gather context of use information . 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

iii
ISO/DIS 25063:2026(en)
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.

iv
ISO/DIS 25063:2026(en)
Introduction
[4]
The human-centred design approach of ISO 9241-210 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
[19] [17]
ISO/IEC TR 25060 and is part of the SQuaRE series (ISO/IEC 25000 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
SQuaRE architecture and the divisions who develop the standards
ISO/IEC 2501n: Quality Model Division
ISO/IEC 2500n: Quality management division
ISO/IEC 2503n: Quality require‑ ISO/IEC 2504n: Quality evalua‑
ment division tion division
ISO/IEC 2507n: Quality engineering division
ISO/IEC 2502n: Quality measurement division
ISO/IEC 25050 – 25099 SQuaRE extension division
ISO/IEC 25051: Requirements for quality of Ready to Use
ISO/IEC 2506n: Common Industry Format division
Software Product (RUSP) and instructions for testing
[2] [19]
Context of use is defined in ISO 9241-11 . The quality in use model in ISO/IEC 25019 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;

v
ISO/DIS 25063:2026(en)
— 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
Human-centred design (HCD) CIF – International Standards System lifecycle processes
processes
ISO 9241-220 ISO/IEC 15288
(9.4.3) Identify the context of this document (6.4.2. b1) Define context of use
use
(9.4.4.2) Identify user needs ISO/IEC 25064:2013 Common Industry Format (6.4.2.b2) Identify stakeholder
(CIF) for usability: User needs report needs
(9.4.4.3) Specify the user re‑ ISO 25065:2019 Common Industry Format (CIF) (6.4.3) System requirements
quirements for Usability: User requirements specification definition process
(9.4.5.2) Specify the user-sys‑ ISO 25067 Common Industry Format (CIF) for (6.4.4) Architecture definition
tem interaction Usability: Design specification of user-system process
interaction and user interface
(9.4.5.3) Produce and refine (6.4.5) Design definition pro‑
user interface design solutions cess
(9.4.6) User-centred Evaluation ISO 25062:2025 Common Industry Format (CIF) (6.4.9) Verification process
for reporting usability evaluations
(6.4.11) Validation process
vi
DRAFT International Standard ISO/DIS 25063:2026(en)
Systems and software engineering — Systems and software
product Quality Requirements and Evaluation (SQuaRE) —
Common Industry Format (CIF) for usability: Context of use
description
1 Scope
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.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
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 Context of use and its components
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]

ISO/DIS 25063:2026(en)
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]

ISO/DIS 25063:2026(en)
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 Other relevant definitions
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]

ISO/DIS 25063:2026(en)
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]
4 Conformance
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.
ISO/DIS 25063:2026(en)
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.
5 Introduction to the Context of use description
5.1 Purposes of a context of use description
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.
5.2 Inputs to a context of use description
5.2.1 General
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.
5.2.2 Domain knowledge for a context of use
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.

ISO/DIS 25063:2026(en)
6 Elements of a context of use description
6.1 Subject of the context of use description
6.1.1 The interactive system (to be designed or evaluated)
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.
6.1.2 Business-related objectives
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.
6.1.3 Human-centred quality objectives
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;
ISO/DIS 25063:2026(en)
— 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.
6.1.4 Constraints
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.
6.1.5 Relationship between current and intended context of use
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

ISO/DIS 25063:2026(en)
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.
6.2 User groups
6.2.1 Identification of the user groups
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.
6.2.2 Task-relevant characteristics of a user group
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;
ISO/DIS 25063:2026(en)
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.
6.2.3 Roles and responsibilities of a user group
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.
6.3 Tasks and task-related goal
...