Ergonomics of human-system interaction Part 220: Processes for enabling, executing and assessing human-centred design within organizations

ISO/IEC 2015 All rights reserved ISO TC 159/SC4/WG6 N505 Date: 2015-03-12 ISO CD 9241-220.2 ISO TC 159/SC4/WG6 Secretariat: Ergonomics of human-system interaction Part 220: Processes for enabling, executing and assessing human-centred design within organizations Version: N224 Final text for CD2 9241-220.docx Status: Text for 2 nd CD Editors: Nigel Bevan, Jonathan Earthy and Thomas Geis Warning This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard. 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. C:\Users\tt8jve\Downloads\N1693_CD2_9241-220_(2015-03).docxBasic template BASICEN3 2002-06-01

Copyright notice This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the reproduction of working drafts or committee drafts in any form for use by participants in the ISO standards development process is permitted without prior permission from ISO, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior written permission from ISO. Requests for permission to reproduce this document for the purpose of selling it should be addressed as shown below or to ISO's member body in the country of the requester: [Indicate the full address, telephone number, fax number, telex number, and electronic mail address, as appropriate, of the Copyright Manager of the ISO member body responsible for the secretariat of the TC or SC within the framework of which the working document has been prepared.] Reproduction for sales purposes may be subject to royalty payments or a licensing agreement. Violators may be prosecuted. ISO/IEC 2015 All rights reserved ii

Contents 1 Scope 1 2 Conformance 2 3 Terms and definitions 2 4 Purpose and use of this part of ISO 9241 10 5 Human-centred design processes 11 6 Using the HCD process descriptions 15 6.1 Uses of the process descriptions... 15 6.2 Notes on the use of process descriptions... 16 7 Human-centred design process descriptions 17 7.0 Format... 17 7.1 Ensure enterprise focus on human-centred quality (HCP.1)... 17 7.1.0 Purpose and outcomes of HCP.1 17 7.1.1 Incorporate human-centred quality in business strategy (HCP.1.1) 18 7.1.2 Institutionalise human-centred quality (HCP.1.2) 19 7.2 Enable human-centred design across projects and systems (HCP.2)... 19 7.2.0 Purpose and outcomes of HCP.2 19 7.2.1 Integration of human-centred design (HCP.2.1) 20 7.2.2 Resources for human-centred design (HCP.2.2) 21 7.2.3 Authorisation and control of human-centred quality (HCP.2.3) 22 7.3 Execute human-centred design within a project (HCP.3)... 22 7.3.0 Purpose and outcomes of HCP.3 22 7.3.1 Plan and manage human-centred design for the project (HCP.3.1) 22 7.3.2 Context of use for each user group (HCP.3.2) 26 7.3.3 Establish the user requirements and related stakeholder requirements (HCP.3.3) 28 7.3.4 Design ergonomic solutions that meet user requirements (HCP.3.4) 31 7.3.5 User-centred evaluation (HCP.3.5) 33 7.4 Introduction, operation and retirement of a system (HCP.4)... 36 7.4.0 Overall purposes and outcomes 36 7.4.1 Introducing the system (HCP.4.1) 37 7.4.2 Human-centred quality in operation (HCP.4.2) 38 7.4.3 Human-centred quality in retirement (HCP.4.3) 38 Annex A (normative) Work products for the processes described in ISO 9241-220 39 A.1 Introduction... 39 ISO/IEC 2015 All rights reserved iii

A.2 Format of the process work product list... 39 A.3 Use of the process work product list... 39 A.4 Process work product list... 40 Annex B (normative) Conformance and Tailoring 46 B.1 Introduction... 46 B.2 Conformance... 46 B.2.1 Introduction 46 B.2.2 Conformance to a selected set of unchanged processes 46 B.2.3 Conformance to tailored processes 46 B.3 Tailoring Process... 47 B.3.1 Purpose 47 B.3.2 Outcomes 47 B.3.3 Activities and tasks 47 B.3.4 Procedure for identifying work products and their contents 48 Annex C (informative) Cross-reference between ISO 9241-210 and ISO 9241-220 HCPs 50 Annex D (informative) Descriptions of work products 55 D.1 Introduction... 55 D.2 Use of work products... 55 D.3 Sources of the work products... 55 D.4 Generic Work Products... 55 D.5 Specific work products related to human-centred quality described in ISO/IEC TR 25060... 57 D.6 Systems work products from ISO/IEC 15504-6... 58 Annex E (informative) Target audiences of the document and uses 71 E.1 Audiences... 71 E.2 Different uses... 72 E.2.1 Implementing human-centred design 72 E.2.2 Assessing an enterprise s existing capability to carry out the human-centred processes 72 E.2.3 Improving the application of human-centred design as part of an existing system development process 73 E.2.4 Development of competence in human-centred design 74 E.3 Organisational context for implementing human-centred design... 74 ISO/IEC 2015 All rights reserved iv

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. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote. ISO 9241-220 was prepared by Technical Committee ISO/TC159 Ergonomics, Subcommittee SC4. ISO 9241-220 revises and replaces ISO/TR18529:2000. The major changes are: Technical update to take account of developments in human-centred design and usability, and concepts such as user experience Introduction of a collective term for the results of human-centred design of interactive systems Architectural update to clarify the different types of process described (management, technical and lifecycle) Format update to align with ISO/IEC 24774 in the description of processes Content update with increased detail and number of process descriptions and inclusion of work product descriptions from ISO/IEC 25060 and ISO/IEC 15504-6. ISO/IEC 2015 All rights reserved vi

Introduction This part of ISO 9241 describes the processes by which human-centred design is achieved throughout the lifecycle of systems intended for human use. These human-centred process descriptions are for use in the specification, assessment and improvement of human-centred processes used in system development and operation. They represent good international practice in human-centred design from a range of industries. Process models offer: a) the potential to analyse the ability of an organisation to deliver and/or maintain a system that meets a required level of performance and quality, b) a description of the factors that hinder this ability and c) a means of addressing such shortcomings and mitigating associated risks. These have led to the widespread adoption of process modelling and assessment as an element in the assurance of timely and effective system delivery. Processes are defined at the level of what is done to develop and operate a system or organisation. NOTE 1 Process models have been defined for particular applications and industries. International standard process models are being developed by ISO and ISO/IEC JTC1. The specification in ISO 9241-220 provides a bridge between standardization in the area of Ergonomics (by ISO TC159) and the life cycle standardization being carried out by ISO/IEC JTC1/SC7 Software engineering. This part of 9241 has been developed with the following objectives in mind: To provide support for the assessment and mitigation of risks arising from human-system issues that will affect usability, accessibility and user experience through the life cycle. To provide a description of human-centred processes for use in project planning and for inter-disciplinary communication. As a basis for understanding and co-operation during the tendering process and for human-centred design capability evaluation to support contract award, either in a stand-alone manner or in conjunction with a software or system capability evaluation. To provide a basis for structured human-centred design process improvement by supplier, customer or employer organisations. ISO 9241-210 Human-centred design for interactive systems describes the principles of a human-centred approach and the activities necessary to be human-centred in design. This part of ISO 9241 elaborates these principles and activities as structured processes. ISO 9241-210 also explains that human-centred design has a broad range of benefits. These can include improving usability, accessibility and user experience, and reducing the risk of the product failing to meet stakeholder requirements. In this part of ISO 9241 human-centred quality is the collective term used to refer to these outcomes. The target of humancentred design is thus to establish an acceptable level of human-centred quality. NOTE 2 NOTE 3 ISO 9241-210 describes the approaches to human-centred design to be used by project managers. ISO 27500 and 27501 describe the human-centred approach for executives and management respectively. ISO/IEC 2015 All rights reserved vii

Ergonomics of human-system interaction Part 220: Processes for enabling, executing and assessing human-centred design within organizations 1 Scope ISO 9241-220 describes the processes by which human-centred design is achieved throughout the lifecycle of systems (including products and services) intended for human use. These human-centred process descriptions are for use in the specification, assessment and improvement of human-centred processes used in system development and operation. They can also provide the basis for professional development and certification. NOTE 1 A process is a set of interrelated resources and activities that transform inputs into outputs. Processes are defined at the level of what is done to develop and operate a system. A process has a purpose and fulfils a business requirement. ISO 9241-220 specifies the purposes, benefits, and outcomes and describes typical activities and work products for each process. Reference is made to related standards that address the design and/or evaluation of components of an interactive system or its environment and the documentation of human-centred design. The description of processes in ISO 9241-220 can be used: to provide a basis for those planning and carrying out HCD activities within an organisation, and in the execution of projects; to provide the basis for those who wish to improve the performance of HCD activities within their own organization to assess human-centred design processes in an organisation as a basis for improvement; to assess the capability of an organisation to supply systems or services with acceptable human-centred quality (whether bespoke or off-the-shelf); as a basis for a definition of professional competence for usability and UX professionals. NOTE 2 The processes do not support organisational redesign, although their application might identify the necessity for redesign. ISO TS 18152 is a related standard with a broader scope than ISO 9241-220. The viewpoint adopted in ISO TS 18152 is that of those responsible for the organisational processes necessary to realise and sustain systems with human-centred quality. It therefore describes system life cycle processes focussing on the identification and handling of issues related to people (users and other stakeholders). ISO 9214-220 is intended for use by organizations that want to address and improve their treatment of human-centred design of either their internal system or the products and services they provide, and the procurement of systems and parts of systems. The processes can be applied by small and medium sized enterprises as well as by large organisations. NOTE 3 The internal promotion of human-centred design is addressed in other International Standards such as ISO 9241-210 and ISO 27500. Readers who are learning about or implementing human-centred design will require additional sources of information to this Part of 9241. For example specific methods are not included. These are described in ISO/TR 16982. International Standards containing more information about process and human-centred design are listed in the Bibliography. ISO/IEC 2015 All rights reserved 1

The set of processes are described from the viewpoint of those responsible for the analysis, design and evaluation of the human use of interactive systems. The processes also address enabling top management support for human-centred design, process management of human-centred design and the lifecycle activities necessary to achieve and sustain systems with human-centred quality. The description of process is intended for use in different contexts, by different audiences, with different roles and responsibilities. Annex E details the target audiences for ISO 9241-220 and their uses of ISO 9241-220. NOTE 4 ISO 9241-220 does not prescribe specific methods. The processes described in ISO 9241-220, can be implemented using a range of methods (such as those described in ISO/TR 16982). The HCD processes in this part of ISO 9241 are described in the format used in ISO/IEC 15504 Process assessment. NOTE 5 Process assessment models describe and structure the activities that give an organisation the best opportunity to achieve defined business and technical outcomes. This viewpoint also supports the communication with other roles, disciplines and domains in projects including product management and development by identifying the necessary efforts for ensuring that an interactive system meets those requirements related to its quality for human use (human-centred quality). 2 Conformance A claim of conformance to ISO 9241-220 when the process descriptions are used for one of the purposes described in 7.1, can be based on: Either A claim of full conformance declaring the set of processes (selected from those described in Clause 7) for which conformance is claimed. Full conformance is achieved by demonstrating that the declared set of processes has been implemented, using the process outcomes as evidence. Or A set of processes, selected from Clause 7, may be tailored to the specific needs of a project using the tailoring process defined in Annex B. The set of tailored processes, for which conformance is claimed, is declared. Conformance is achieved by demonstrating that the processes, as tailored, have been implemented, using the process outcomes as evidence. NOTE 1: All applicable process outcomes within the declared set have to be produced for conformance. NOTE 2: More details of the alternative approaches to conformance are described in Normative Annex B. 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1 accessibility <system, product or service> usability of a product, service, environment or facility by people with the widest range of capabilities [SOURCE: ISO 9241-171 with the domain to which each definition applies modified to a system, product or service] 3.2 context of use combination(s) of users, goals and tasks, resources, and physical and social environments [SOURCE: ISO CD 9241-11] Note to entry: This can apply to an existing context of use or an intended context of use. ISO/IEC 2015 All rights reserved 2

3.3 effectiveness extent to which the use of the system, product or service enables the goals to be achieved accurately, completely and appropriately [SOURCE: ISO CD 9241-11] 3.4 efficiency expendable resources (including time, human effort, costs and materials) used to achieve specified goals [SOURCE: ISO CD 9241-11] 3.5 ergonomics human factors scientific discipline concerned with the understanding of interactions among human and other elements of a system, and the profession that applies theory, principles, data and methods to design in order to optimize human well-being and overall system performance [SOURCE: ISO 26800:2011] 3.6 enterprise that part of an organization with responsibility to acquire and to supply products and/or services according to agreements. Note to entry: organizations. An organization may be involved in several enterprises and an enterprise may involve one or more [SOURCE: ISO/TS 18152:2010, 4.4] 3.7 evaluation systematic determination of the extent to which an entity meets its specified criteria [SOURCE: ISO/IEC 12207:2008] 3.8 goal intended outcome [SOURCE: ISO 9241-11:1998, 3.8] 3.9 human factors data information about humans and human behaviour derived from new user research or based on existing findings Note to entry: This includes, for example, anthropometric data, health and safety data, psychometric measurements, ergonomics standards, accessibility standards, and expert knowledge in all human sciences (e.g. psychology, sociology, medicine, human computer interaction, behavioural science, anthropology, management science, education, personnel and staffing management), and codifications of this information and knowledge (e.g. international standards, legislative requirements, existing patents, good practice, style guides and project standards). ISO/IEC 2015 All rights reserved 3

3.10 human-centred design (HCD) approach to system design and development that aims to make interactive systems more usable by focussing on the use of the system; applying human factors, ergonomics and usability knowledge and techniques Note 1 to entry: The term human-centred design is used rather than user-centred design in order to emphasize that this standard also addresses impacts on a number of stakeholders, not just those typically considered as users. However, in practice, these terms are often used synonymously. Note 2 to entry: Usable systems can provide a number of benefits including improved productivity, enhanced user wellbeing, avoidance of stress, increased accessibility, and reduced risk of harm. [SOURCE: ISO 9241-210:2010, 2.7] 3.11 human-centred quality usability, accessibility, user experience and reduced risk Note 1 to entry: Human-centred quality is a collective term for the intended outcomes of human-centred design. Note 2 to entry: The term "human-centred quality" is also used as a qualifier to refer to factors that contribute to humancentred quality. 3.12 inspection-based evaluation evaluation based on the judgment of one or more evaluator(s) who examine or use a system to identify potential usability problems and/or deviations from established criteria Note 1 to entry: The evaluators making the inspections typically are usability specialists but can also include end users and members of the design team. Note 2 to entry: Established criteria typically include user requirements, usability guidelines in standards, design conventions contained in manufacturer guidelines and style guides, task models to be supported as well as standardized principles. Note 3 to entry: The evaluation can be conducted with or without the help of reference documents. Note 4 to entry: Inspection-based evaluation is a generic term for methods that include but are not limited to heuristic evaluation, cognitive walkthroughs, standards inspection, pluralistic walkthroughs, and consistency inspections. Note 5 to entry: Inspection-based evaluation can be conducted by machines in some cases, e.g. when consistency. [ISO/IEC DIS 25066] 3.13 interaction object <interactive system> control or component (including information) assisting the user in carrying out tasks using the interactive system 3.14 interactive system combination of hardware, software and/or services that receives input from, and communicates output to, users Note 1 to entry: training. This includes, where appropriate, packaging, branding, user documentation, on-line help, support and [SOURCE: ISO 9241-210:2010, 2.8] ISO/IEC 2015 All rights reserved 4

Note 2 to entry: Interactive systems include any product, system or service that enables users to complete tasks. 3.15 learnability degree to which a product or system can be used by specified users to achieve specified goals of learning to use the product or system with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use [SOURCE: ISO/IEC 25010] 3.16 life cycle the stages and activities spanning the life of the system from the definition of its requirements to the termination of its use covering its conception, development, operation, maintenance support and disposal Note to entry: Adapted from definitions in IEC 61508, ISO 13407 and ISO/IEC 12207. 3.17 process set of interrelated activities, which transform inputs into outputs [SOURCE: ISO 8402:1994] 3.18 process category set of processes addressing the same general area of activity [SOURCE: ISO/TS 18152:2010] 3.19 process capability the capability of a process to meet its purpose as managed by an organization's management and process definition structures Note1 to entry: This usage differs from human capability, military capability and operational capability. To avoid confusion these alternative usages are avoided in this specification. Note 2 to entry: The capability levels used in ISO/IEC 15504-2 Performing an assessment are included in E. 3.20 process assessment disciplined evaluation of an organization's processes against a Process Assessment Model [SOURCE: ISO/IEC 15504-1:2004, 3.29] 3.21 process benefit positive achievement from the execution of a process. Note 1 to entry: Benefits are often spread broadly across the business and not necessarily related to the technical or business intent of executing a process. Note 2 to entry: so. A benefit might provide the motivation to execute a process, but it might not be the primary reason to do [SOURCE: ISO/IEC 24774:2010] ISO/IEC 2015 All rights reserved 5

3.22 process improvement actions taken to change an organization's processes so that they more effectively and/or efficiently meet the organization's business goals [SOURCE: ISO/IEC 15504-1:2004, 3.40] 3.23 process outcome observable result of the successful achievement of the process purpose [ISO/IEC 12207:2008] 3.24 process purpose high level objective of performing the process and the likely outcomes of effective implementation of the process Note to entry: The implementation of the process should provide tangible benefits to the stakeholders. [ISO/IEC 12207:2008] 3.25 project endeavour with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements [SOURCE: ISO/IEC 15288:2008, 4.20] Note to entry: The term project is not intended to be exclusive to the development of a system. Projects include longterm activities related to a system, such as training, maintenance and support. 3.26 prototype <interactive system> representation of all or part of an interactive system, that, although limited in some way, can be used for analysis, design and evaluation [SOURCE: ISO 9241-210:2010] Note to entry: A prototype can be as simple as a sketch or static mock-up or as complicated as a fully functioning interactive system with more or less complete functionality. 3.27 reduced risk extent to which the human-centred quality of an interactive system mitigates or avoids potential risk to the user, organisation or project related to or arising from human use; including risks to economic status, human life, health, or the environment Note 1 to entry: Risks include any undesirable consequences that could result from not achieving the intended objective, from inappropriate task activities or from inappropriate system output. Organisational risks include lack of agreement on solutions (within and across user groups). Note 2 to entry: Risk is a function of the probability of occurrence of a given threat and the potential adverse consequences of that threat's occurrence. ISO/IEC 2015 All rights reserved 6

3.28 requirement a 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 Note to entry: Requirements include the quantified and documented needs, wants, and expectations of the sponsor, customer, and other stakeholders. [SOURCE: ISO/IEC 24765:2010, 3.2506] 3.29 satisfaction extent to which attitudes related to the use of a system, product or service and the emotional and physiological effects arising from use are positive or negative Note to entry: Attitudes include cognitive beliefs and opinions about the system or the interaction with the system. [SOURCE: ISO CD 9241-11] 3.30 service means of delivering value for the customer by facilitating results the customer wants to achieve Note to entry: Service is generally intangible. [SOURCE: ISO/IEC 20000-1:2011] 3.31 stakeholder person or organisation that can affect, be affected by, or perceive themselves to be affected by a decision or activity [SOURCE: ISO 31000:2009, 2.13, modified: omitted note 1] Note to entry: Users are stakeholders. 3.32 success-critical stakeholders stakeholders for whom meeting requirements is critical to the success of the system 3.33 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: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g. aircraft system. Alternatively the word system may be substituted simply by a context dependent synonym, e.g. aircraft, though this may then obscure a system principles perspective. [SOURCE: ISO/IEC 15288] 3.34 task activities required to achieve a goal [SOURCE: ISO 9241-11:1998, 3.9] ISO/IEC 2015 All rights reserved 7

3.35 usability extent to which an interactive system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use [SOURCE: ISO 9241-210, 2.13] 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 term "usability" is often used as a qualifier to refer to the knowledge, competencies, activities and design attributes that contribute to usability. 3.36 usability requirement required level of usability expressed in terms of measures of effectiveness, efficiency and satisfaction in a specified context of use [SOURCE: ISO 20282-2] 3.37 user person who interacts with a system, product or service Note 1 to entry: Users include people who operate a system, people who make indirect use of the system by using the output provided by a system and people who conduct support tasks using the system (including maintenance and training). Note 2 to entry: Other stakeholders who can be affected by a system, product or service, but do not interact with either the system or its outputs are not considered to be users. [SOURCE: ISO CD 9241-11] Note 3 to entry: Users are stakeholders. 3.38 user-based evaluation evaluation that involves representative users performing tasks with the system to enable identification of usability problems and/or measurements of efficiency, effectiveness, user satisfaction or other user experiences [ISO/IEC DIS 25066] 3.39 user experience person's perceptions and responses that result from the use and/or anticipated use of a product, system or service Note 1 to entry: User experience includes all the users emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviours and accomplishments that occur before, during and after use. Note 2 to entry: User experience is a consequence of brand image, presentation, functionality, system performance, interactive behaviour, and assistive capabilities of the interactive system; the user s internal and physical state resulting from prior experiences, attitudes, skills and personality; and the context of use. Note 3 to entry: Usability, when interpreted from the perspective of the users personal goals, can include the kind of perceptual and emotional aspects typically associated with user experience. Usability criteria can be established so as to assess aspects of user experience. ISO/IEC 2015 All rights reserved 8

[SOURCE: ISO 9241-210:2010, 2.15] 3.40 user group <usability> group of users differentiated by characteristics of the users, tasks or environments that are expected to influence usability Note to entry: This could either be an intended user group or a user test group. [ISO/TS 20282-2:2013] 3.41 user interaction exchange of information between a user and an interactive system via the user interface to complete the intended task Note 1 to entry: Adapted from ISO 11064-5:2008, 3.20. Note 2 to entry: User interaction specifications focus on user interactions without considering implementation details. 3.42 user interface all components of an interactive system (software or hardware) that provide information and controls for the user to accomplish specific tasks with the interactive system [SOURCE: ISO 9241-110:2006, 3.9] 3.43 user interface guidance principle, requirement, recommendation or established convention for designing the user interaction and/or the user interface. Note 1 to entry: Specific requirements, recommendations or established conventions are also referred to as user interface guidelines. Note 2 to entry: User interface guidance can apply to both, the dialogue between user and system as well as the user interface itself in terms of ergonomic design of information and controls. Note 3 to entry: Principles, requirements and recommendations are published in various sources including the ISO 9241 series. These principles, requirements and recommendations typically apply across user interface platforms, e.g. colour should be used only as an additional means to code information or required entry fields should be visually distinct from optional entry fields. User-interface related recommendations can be found in the ISO 9241 series of standards (see bibliography). Note 4 to entry: Established conventions typically include rules published by suppliers of the user interface platforms (e.g. Windows, Mac OS, ios, Android ). An example for a convention is a dialog box always has an OK and Cancel button at the bottom right corner of the dialogue box. 3.44 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 [SOURCE: ISO/IEC 25064] ISO/IEC 2015 All rights reserved 9

3.45 user requirements (usage requirements) 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 make use of the system in an effective, efficient, safe and satisfying manner. Note 2 to entry: User requirements specify the extent to which user needs and capabilities are to be met when using the system. They are not requirements on the users. Note 3 to entry: In software-engineering terms, user requirements comprise both functional and non-functional requirements based on user needs and capabilities. [SOURCE: ISO/IEC TR 25060:2010, 2.21] 3.46 validation confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled [SOURCE: ISO 9000:2005] Note to entry: Validation is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals and objectives (i.e., meet stakeholder requirements) in the intended operational environment. 3.47 verification confirmation, through the provision of objective evidence, that specified requirements have been fulfilled [SOURCE: ISO 9000:2005] Note to entry: Verification is a set of activities that compares a system or system element against the required characteristics. This can include, but is not limited to, specified requirements, design description and the system itself. 3.48 work product artefact associated with the execution of a process [SOURCE: ISO/IEC 15504-1:2004] 4 Purpose and use of this part of ISO 9241 This part of ISO 9241 describes the processes that represent good practice for implementing human-centred design within and across projects, and for assessing an organisation's capability to implement and operate human-centred design processes. It facilitates consistent application of human-centred design to take account of the interactions between people and systems. Application of these HCD processes supports the achievement of human-centred quality that is comprised of usability, user experience, accessibility, and reduction of risk related to, or arising from, human use (humancentred quality is described in more detail in Annex F). The benefits of addressing human-centred quality include improved performance, enhanced user well-being, avoidance of stress, increased accessibility and reduced risk of any adverse consequences. NOTE Ergonomics shares these objectives and benefits but has a scope that includes the design of organisations as well as systems for human use, and is also used beyond the domain of design, for example in the forensic analysis of the causes of accidents and in the generation of data and methods of measurement. ISO 27500 explains the management of risk through consideration of ergonomics. ISO/IEC 2015 All rights reserved 10

For any system to which human-centred design is applied there will be a set of qualities in that system, or the way it is delivered, which are of value to different stakeholders. These qualities need to be addressed when designing the solution. The stakeholders for whom meeting requirements could be critical to the success of the system ("success-critical stakeholders") for human-centred quality, and the risks for which they are responsible are described in E.1 and F.2. The definition, assessment and improvement of the processes by which services and products are produced and maintained in operation benefits many areas of human enterprise. The rationale for process capability improvement is that it offers: prediction of the ability of a business to deliver a product that meets a required level of human-centred quality; indication of the factors that hinder this ability; and the means of addressing such shortcomings. These benefits of a process-based approach have led to the widespread adoption of process capability improvement as an element in the assurance of timely and effective system development and delivery. Process capability improvement of human-centred design benefits all of those who purchase, make and use interactive systems. Benefits to through life cost, safety and satisfaction will be felt directly by purchasers and users (ranging from governments to individual consumers). Benefits in client satisfaction and reduced project risk will be felt by all stages in the product/service supply chain (industry, trade and distributors). 5 Human-centred design processes The human-centred design processes (that are that are summarised in Figure 1, listed in Table 1 and described in detail in clause 7) describe the activities and outcomes that are necessary in order to achieve human-centred quality in interactive systems. Some processes focus on managing the objective of humancentred quality, while others describe the HCD activities and outcomes that are necessary in order to produce human-centred quality. Figure 1 illustrates the different levels in an organization and their responsibilities for human-centred quality. It is a responsibility of the top management in an organization to set vision and policies for human-centred quality (HCP.1). Human-centred design across projects and systems is enabled by those responsible for (project) program management and/or the operation of systems (HCP.2). The execution of human-centred design within projects and the introduction, operation and retirement is carried out by people with the appropriate skills within each project (HCP.3 and HCP.4). ISO/IEC 2015 All rights reserved 11

Figure 1: HCD process framework The HCD processes (HCPs) are listed in Table 1. They are grouped into the following process categories: HCP.1 Ensure enterprise focus on human-centred quality HCP.2 Enable human-centred design across projects and systems HCP.3 Execute human-centred design within a project HCP.4 Introduction, operation and retirement of a system Table 1 also lists the primary audiences for each process category (for more detail see E.1). Each process is identified with a reference number of the form HCP.n.m where HCP is an abbreviation for Human-Centred Process. The processes HCP.1, HCP.2, HCP.3 and HCP.4 are described clauses 7.1, 7.2, 7.2.3 and 7.4. HCP.1 addresses what organisations need to do to support human-centred design. HCP.2 describes the management of human-centred design, and HCP.3 details the technical aspects of human-centred design during development or change of a system. HCP.4 covers the introduction and operation of a system. Together these four sets of processes ensure that the systems produced, acquired and operated by an organisation have human-centred quality. Organisations can implement these processes to the degree necessary to achieve required targets for the components of human-centred quality. Individual processes can be applied without the necessity to have all processes in place and the sequence of implementing and applying them depends on the situation in which they are used. ISO/IEC 2015 All rights reserved 12

Unique Identifier Table 1 Human-centred design processes Process Name Primary audiences HCP.1 Ensure enterprise focus on human-centred quality Executive HCP.1.1 Incorporate human-centred quality in business strategy management Executive HCP.1.2 Institutionalise human-centred quality responsible for human-centred quality HCP.2 HCP.2.1 HCP.2.2 HCP.2.3 HCP.3 HCP.3.1 HCP.3.1.1 HCP.3.1.2 HCP.3.1.3 HCP.3.1.4 HCP.3.1.5 HCP.3.2 HCP.3.2.1 HCP.3.2.2 HCP.3.3 HCP.3.3.1 HCP.3.3.2 HCP.3.3.3 HCP.3.4 HCP.3.4.1 HCP.3.4.2 HCP.3.5 HCP.3.5.1 HCP.3.5.2 HCP.3.5.3 HCP.4 HCP.4.1 HCP.4.2 HCP.4.3 Enable human-centred design across projects and systems Integration of human-centred design Resources for human-centred design Authorisation and control of human-centred quality Execute human-centred design within a project Plan and manage human-centred design for the project Establish human-centred quality objectives Manage risks related to the achievement of humancentred quality Define extent of HCD activities in the project Plan each HCD activity Manage HCD activities within the project Context of use for all user groups Identify and differentiate groups of users Identify context of use and reported issues Establish the user and related stakeholder requirements Identify the user needs Derive the user requirements Negotiate the user requirements in the context of a project Design ergonomic solution that meets user requirements Specify the user-system interaction Produce and refine user interface design solutions User-centred evaluation Plan for evaluation throughout the project Plan each evaluation (what to evaluate and how) Carry out each evaluation Introduction, operation and retirement of a system Introducing the system Human-centred quality in operation Human-centred quality in retirement Project, product and usability managers Those responsible for processes used by the organization Project managers Product manager Technical leadership responsible for usability and ergonomics Service & support managers Technical leadership responsible for usability and ergonomics Note: Educators and trainers of human-centred design are also a primary audience. ISO/IEC 2015 All rights reserved 13

The purpose of each process is to produce the specified outcomes. However, to assist in the correct implementation as well as the assessment of processes performance the description of each process includes a list of the activities that are typically carried out to achieve the process outcomes. Annexes A and D describe the resulting work products. HCP.3, which describes the processes for executing human-centred design within projects, elaborates on the content of ISO 9241-210. The scope of HCP.3 is the same as the scope of ISO 9241-210. It describes the planning and management of HCD for a project as well as detailed HCD activities. The other processes categories go beyond the scope of ISO 9241-210. HCP.1 and HCP.2 describe the organisational governance and high-level management activities that require and resource human-centred design. HCP.4 describes the activities that ensure that human-system issues are addressed throughout the life of a system. ISO 9241-220 shows how the ISO 9241-210 activities fit within an institutional framework. Figure 2: Illustration of the data relationships between the HCD processes Figure 2 shows the relationship between the processes. It includes a box for each process category (HCP 1 to 4) and elaborates HCP.3 with the processes HCP 3.1 to 3.5. The solid lines between processes show the flow of management control and responsibility. The direction of the arrow indicates the flow of control. Control can be achieved by the provision of a management work product, such as a policy or plan. HCP.1 Ensure enterprise focus on human-centred quality is responsible for HCP.2 Enable human-centred design across projects and systems which is responsible for HCP.3.1 Plan and manage human-centred design for the project, which is responsible for the technical sub-processes (HCP.3.2, HCP.3.3, HCP.3.4 and HCP.3.5), as well as HCP.4 Introduction, operation and retirement of a system. The dashed lines indicate exchange of technical information. The direction of the arrow indicates the direction of exchange of a technical work product, such as a set of requirements or an evaluation report. The technical sub-processes are typically used iteratively in a project, but there is a logical flow of information from HCP.3.2 Context of use for all user groups to HCP.3.3 Establish the user and related stakeholder requirements to HCP.3.4 Design ergonomic solution that meets user requirements to HCP.3.5 User-centred evaluation and back to HCP.3.2. Evaluation should also take place as part of HCP.4 Introduction, operation and retirement of a system. The results of use of the system will provide feedback on whether HCP.1 Ensure enterprise focus on human-centred quality has been successful. ISO/IEC 2015 All rights reserved 14

6 Using the HCD process descriptions 6.1 Uses of the process descriptions The human-centred process model describes the processes and sub-processes that are necessary to make systems human-centred and thus achieve human-centred quality. This makes it a useful resource for enterprises (organisations, departments or projects) in the situations that are summarised below, and described in more detail in E.2. a) Implementing human-centred design as part of a system development process and/or support lifecycle The ISO 9241-220 processes can be used a basis for incorporating HCD activities into a system development process by enterprises (organisations, departments or projects) and/or into a support lifecycle that needs to be human-centred. In this application the enterprise identifies which ISO 9241-220 processes could help meet their organisational needs and the level of implementation required to achieve the enterprise's business purposes. The detailed description of process work products in Annex D can assist in this definition. b) Assessing an enterprise s existing capability to carry out the human-centred processes ISO 9241-220 can be used in the assessment of an enterprise s capability to carry out the human-centred processes described in ISO 9241-220 and hence to achieve human-centred quality in its systems products and services. In this application the first step is the tailoring of the model for the assessment. This consists of selection of relevant processes and definition of the maximum capability that the organisation aspires to. If it is not important to the business that a particular process is performed well then there is no need to assess it. The next step is to select typical projects for assessment. For a thorough assessment the range of projects are selected to be representative of the spread of work, size of project and diligence of the enterprise. The assessment is typically achieved by interviewing selected staff, to ascertain how many of the activities are performed for each process, and, to ascertain how well these processes are implemented. The process outcomes and work products can be used as evidence of the performance of the activities. c) Improving the application of human-centred design as part of an existing system development process The assessment of an enterprise s capability to carry out the human-centred processes can be extended to identify the gaps between the existing and desired levels of performance of each HCD process. HCD methods can then be identified to fill the gaps and raise the level of performance in a way that is cost-effective for the particular organisation. In this application the organisation reviews the results of its process assessment against the outcomes and benefits achieved by better performance of each process. Where this would improve organisational performance in a cost-effective manner the activities, outcomes and work products are used as a specification for change to its processes. This change is typically achieved in stages and progress is measured by further assessments. d) Development of competence in human-centred design The processes can be used as a basis for a definition of professional competence for usability professionals. An agreed model of the activities that constitute human-centred design can be used by professional bodies, academic institutions, training organisations and certification bodies. ISO/IEC 2015 All rights reserved 15

In this application competence is defined in terms of two dimensions, or axes. One axis is the set of processes considered relevant to the discipline of interest, in this case the processes in this part of ISO 9241. The other axis defines the levels of proficiency in performing these processes. In an educational context the structure can serve a framework for skills and knowledge or more specifically as a basis for a course syllabus. The outcomes, activities and work products described for each process can be used to identify and link content for education and training courses in human-centred design and usability. e) Organisational context for implementing human-centred design Human-centred design can be implemented in a wide range of organisational contexts including those listed below. These are described in more detail in E.3. Formality ranging from governance-centred to ad hoc. Both manufacturers and acquirers (including both off-the-shelf products and bespoke developments). Organisations ranging in size from small to large. Both introduction and improvement of human-centred design. Both top down and bottom-up application of human-centred design. Both system and service providers. 6.2 Notes on the use of process descriptions a) Integration with systems and software engineering The structure used for documenting HCD processes in ISO 9241-220 is the same as that used for the International Standards for systems and software engineering processes. This allows HCD processes to be integrated with, and implemented and assessed in the same way as systems and software engineering standards such as ISO/IEC 15288 and ISO/IEC 12207. This common approach facilitates the integration of human-centred design with systems and software engineering. b) Implementation of the processes The ISO approach to documenting processes focuses on the outcome, i.e. what is achieved when the process is carried out, not the detail of methods or the production of documents. This approach allows process descriptions to be applied to many different systems, projects and organisational settings. Process descriptions are brief and concise in order that they can be interpreted for a wide range of management and development styles, methods and techniques. Sets of process descriptions, such as ISO 9241-220 are not methodologies. They require tailoring before they can be implemented in an organisation. This tailoring takes account of the level of human-centred quality needed to mitigate system, project or organisational risk. Processes can be integrated in all types of management approaches to development (e.g. very formalized, agile, design thinking). c) Repeated use of processes Processes are likely to be carried out partly or fully several times in a life cycle and in various parts of an organisation as a product, service or system is defined, developed and maintained. Human-centred design processes can be applied repeatedly as the result of iterative development or continuous improvement of the system. Processes are performed whenever the need for specific outcomes arises. The duration and degree of rigour employed in the performance of a process depends on risk, context and requirements. ISO/IEC 2015 All rights reserved 16

7 Human-centred design process descriptions 7.0 Format For each process ISO 9241-220 specifies the following process elements. Process title: a descriptive heading for a process. Process purpose: describes the goal of performing the process. Process benefits: describe the positive achievements from the execution of a process. Process outcomes: express the observable results expected from the successful performance of the process. Process activities: activities that are typically performed to achieve the process outcomes. Each activity is followed by a list of associated outcomes (e.g. [a, b]). Each process is described with a unique identifier of the form HCP.l.n.m and a unique title. "HCP" indicates that the process is from the HCP model, "l" is the process category reference and "n" or m is the unique process number, depending on the level of decomposition used within the category. The purpose of each process is described, along with notes, if necessary, to describe the process, and the benefit of the process in terms of achievement of human-centred quality. Annex A contains a table listing the information items and other work products that form the input to and output from the process. The work products are described in detail in Annex D. 7.1 Ensure enterprise focus on human-centred quality (HCP.1) 7.1.0 Purpose and outcomes of HCP.1 The main audience for this set of processes is executives and management responsible for human-centred quality. The opportunities and risks addressed are related to corporate image or society, customer confidence, business success, staff motivation, and human-system issues in governance and services. The purpose of this process is to establish and maintain awareness and sensitivity to satisfying stakeholder and user needs for human-centred quality across the organisation, and make these needs an inherent element in an organization's business strategy. The outcomes achieved by this set of processes are as follows. Human-centred quality of systems is treated as corporate asset across the organization Policies for achieving human-centred quality are set (demonstrating senior management support for the improvement of infrastructure related to human-centred quality). Change to a human-centred organization is managed effectively. The organisation maintains an appropriate level of human-centred quality: o o o across systems, products and services; over time; in the market and workplace. Human effectiveness, cost and risk analysis results are taken into account in investment decisions. NOTE See ISO DIS 27500 for more information on the benefits of taking a human-centred approach, the type of human-centred quality objectives that may be set as a result, and the potential risks if these are not achieved. ISO/IEC 2015 All rights reserved 17

[Editorial note: need to check that HCP.1 is consistent with any changes made to ISO 27500 (currently out for DIS ballot).] These outcomes are achieved by performance of the following processes. 7.1.1 Incorporate human-centred quality in business strategy (HCP.1.1) Table 2 describes the purpose, the outcomes and the process activities to be conducted within HCP.1.1. Process purpose Process benefits Process outcomes Process activities (typical) Table 2: Purpose, outcomes and activities of HCP.1.1 Explicitly take account of system, product and service human-centred quality in an organisation s business strategy. NOTE: This applies to both the human-centred quality of systems, products and services acquired for use and those designed and developed by an organisation. The organization and affected stakeholders benefit from improved human-centred quality. a) Analysis of opportunities for the organisation related to human-centred quality, including the understanding and mitigation of risks. b) A corporate vision of human-centred quality as a corporate asset. c) Strategic objectives for the human-centred quality of the organisation's systems, products and services in the market/work place are set. d) System, product and service investment is based on human effectiveness, cost benefits and risk analysis. e) Necessary resources for addressing human-centred quality are available. f) HCD is integrated in the procurement process. g) Marketing explicitly takes account of human-centred quality. 1. Identify opportunities / benefits of good human-centred quality for the organisation [a] 2. Identify any risks to human-centred quality within the organisation. [b] 3. Determine the extent to which improved human-centred quality of interactive systems is a benefit for the organisation and poor human-centred quality of interactive systems is a risk for the organisation. [a] 4. Determine how the organisation affects the human-centred quality of its interactive systems. [c] 5. Assess how human-centred quality is related to business benefits for the organisation. [b] 6. Define strategic human-centred quality objectives for interactive systems. [b] 7. 8. Explicitly plan for human-centred quality in financial management of programs and infrastructure. [c, d] Explicitly take account of human-centred quality in procurement. [e] 9. Analyse social, educational and technological trends in staff and users. [f] 10. Analyse competitive situation in the market place. [g] ISO/IEC 2015 All rights reserved 18

7.1.2 Institutionalise human-centred quality (HCP.1.2) Table 3 describes the purpose, the outcomes and the process activities to be conducted within HCP.1.2. Table 3: Purpose, outcomes and activities of HCP.1.2 Process purpose Process benefits Process outcomes Process activities (typical) Establish and maintain a human-centred approach as normal practice in the organization. A means to achieve human-centred quality is defined. a) The organisation has a human-centred approach to system design, operation and procurement. b) Systems, products and services aim to meet users needs and expectations. c) The extent to which HCD needs to be incorporated for each product line is known. d) The principles of human-centred design are applied in development of interactive systems. e) The enterprise is responsive to changes in how their systems, products and services are used. 1. Designate a suitable member of the executive board to be responsible for championing a human-centred approach and getting board endorsement. [a] 2. Establish and communicate a policy for achieving human-centred quality in the organisation. [b] 3. Establish and maintain awareness of human-centred quality. [c] 4. Ensure acceptance of human-centred activities in the organization. [d] 5. Establish a continuous improvement program for human-centred quality in the organisation. [b] 6. Planners consider stakeholder and organisation requirements in setting out systems strategy. [e] 7. Review and maintain the effectiveness of the achievement of the outcomes. [a] 7.2 Enable human-centred design across projects and systems (HCP.2) [Editorial note: may need to check HCP.2 and HCP.3.1 are consistent with 27501 if it has reached DIS] 7.2.0 Purpose and outcomes of HCP.2 The main audience for this set of processes is program, project, product and usability managers, process owners and technical specialists with cross-project or organizational responsibilities. The types of risks addressed include risks to the corporate image or society, business survival, and human-system issues in governance and services The purpose of these processes is to provide the organisation with an appropriate HCD capability, ensuring that human-centred design is resourced, conducted and consistent within the whole system lifecycle process within and across systems, and that the enterprise policies are implemented in every project as appropriate. The outcomes achieved by this set of processes are as follows. Each project s business plan addresses human-centred quality in terms of: o o o usability; accessibility; user experience; and ISO/IEC 2015 All rights reserved 19

o reduced risk. Appropriate procedures for achieving human-centred quality by HCD activities exist: o o o o for systems, products, services; to support interoperability, integration, consistency of use across systems, products, services; across user groups; over time. An organizational infrastructure and staff for HCD processes is established, promoted and maintained. Human-centred quality is an inherent element in the process of acquisition, supply and operation of interactive systems. Trade-off and risk management explicitly include human-centred quality in mitigating risks. Reusable data and information necessary for the organization to carry out human-centred design and maintain safe, accessible and usable systems that meet stakeholder and user requirements are available. These outcomes are achieved by performance of the following processes. 7.2.1 Integration of human-centred design (HCP.2.1) Table 4 describes the purpose, the outcomes and the process activities to be conducted within HCP.2.1. Table 4: Purpose, outcomes and activities of HCP.2.1 Process purpose Process benefits Process outcomes Process activities (typical) To ensure that the organisation has procedures that enable human-centred design to be appropriately integrated into all phases of the life cycle for interactive systems. Human-centred design is used appropriately to achieve human-centred quality. a) The organization has a shared understanding of human-centred design and how it is achieved. b) Human-centred design is a documented part of the systems development process and the overall system development project plan. c) Procedures are defined for integrating HCD activities with other system development activities. d) An effective mechanism is established for personal and technical communication related to human system issues. e) Strategic human-system issues and associated risks related to systems and their use are identified and managed. f) The costs and benefits of particular HCD activities and risks mitigated are known. g) Stakeholders relevant to the human-centred approach are involved. 1. Establish a common terminology for human-system issues with the organisation. [a] 2. Integrate human-centred design into the overall system development project plan. [b] 3. Collect feedback on the management of human-system issues across the organisation. [d] 4. Develop effective procedures for communication between those responsible for human-centred design and other members of project teams. [c, d] 5. Identify emerging human-system issues for the organization. [e, f] 6. Identify and integrate stakeholders relevant to the human-centred approach. [g] ISO/IEC 2015 All rights reserved 20

7.2.2 Resources for human-centred design (HCP.2.2) Table 5 describes the purpose, the outcomes and the process activities to be conducted within HCP.2.2. Table 5: Purpose, outcomes and activities of HCP.2.2 Process purpose Process benefits Process outcomes Process activities (typical) To maintain an effective organisational infrastructure to support human-centred design. Human-centred design can be carried out appropriately within projects to achieve human-centred quality. a) An agreed set of suitable HCD procedures, tools and methods representing accepted practise is used to address human-centred quality. b) Agreed HCD procedures are maintained in suitable format(s) for effective and widespread use by project members. c) Accepted design guidelines, standards and human factors data related to humancentred quality are provided and maintained in suitable format(s) for effective and widespread use by project stakeholders. d) Sufficient staff competent in human-centred design are available to all projects. e) Guidance on selecting, adapting and applying individual tools and methods to obtain sufficient confidence that the required level of human-centred quality will be achieved is available. 1. Define an authority to be responsible for maintaining and promoting the infrastructure for human-centred design (procedures, tools, methods, training and mentoring). [a] 2. Select, publish and maintain HCD procedures, tools and methods that are usable by the organization. [b] 3. Define required competences in human-centred design and appropriate assessment methods. [d] 4. Establish training to reach and maintain required competences in Human-centred design. [d] 5. Mentor and monitor trained individuals to ensure that competence is effectively applied in the working environment by senior staff. [d] 6. Ensure that staff are competent (including any necessary training) to apply selected procedures, tools and methods (including tailoring where appropriate). [d, e] 7. Select, publish and maintain design guidelines, standards and other information related to human-centred quality within the organization by senior staff. [c] NOTE: Principles, requirements and recommendations are published in various sources including the ISO 9241 series. These principles, requirements and recommendations typically apply across user interface platforms, e.g. colour should be used only as an additional means to code information or required entry fields should be visually distinct from optional entry fields. User-interface related recommendations can be found in the ISO 9241 series of standards (see bibliography). ISO/IEC 2015 All rights reserved 21

7.2.3 Authorisation and control of human-centred quality (HCP.2.3) Table 6 describes the purpose, the outcomes and the process activities to be conducted within HCP.2.3. Table 6: Purpose, outcomes and activities of HCP.2.3 Process purpose Process benefits Process outcomes Process activities (typical) To take account of human-centred quality in the acquisition, supply and operation of interactive systems. Appropriate levels of human-centred quality are achieved. a) Human-centred quality is part of official sign-off for each interactive system and its elements. b) Human-centred design practice and capability are monitored in the supplying organization. c) Acquisition includes requirements for human-centred quality. 1. Include review and sign-off of human-centred quality in all reviews and decisions. [a] 2. Assess and improve HCD capability in organizations carrying out design and development of interactive systems. [b] 3. Include requirements for human-centred quality in the criteria for acquisition. [c] 7.3 Execute human-centred design within a project (HCP.3) 7.3.0 Purpose and outcomes of HCP.3 The main audience for this set of processes is project managers, product managers, senior Usability professionals, and educators and trainers. The types of risks addressed include human-system issues in the project and the system, and the quality of the system. The purpose of this set of processes is to carry out HCD activities as appropriate in order to ensure that the system achieves appropriate human-centred quality. The outcomes achieved by this set of processes are as follows. Designs or redesigns are based on stakeholder requirements. Appropriate HCD activities are performed. Appropriate methods are applied. Work products contain the required content. Appropriate human-centred quality is achieved. NOTE This process provides a means of conforming to the requirements of ISO 9241-210 (see Annex C). These outcomes are achieved by performance of the following processes. 7.3.1 Plan and manage human-centred design for the project (HCP.3.1) 7.3.1.0 Overall Purpose and outcomes The purpose of the following set of processes is to ensure that human centred design is conducted in a systematic manner within a project and can be traced throughout the project. The outcomes achieved by this set of processes are as follows. ISO/IEC 2015 All rights reserved 22

Project stakeholders know which work products need to be produced from the perspective of humancentred quality of the system. Human-centred design is integrated in the overall project plan. Human-centred design is conducted in a systematic manner. These outcomes are achieved by performance of the following sub-processes. 7.3.1.1 Establish human-centred quality objectives (HCP.3.1.1) Table 7 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.1.1. [Editorial Note: should the examples be moved to ISO/IEC 25065 - the requirements CIF?] Table 7: Purpose, outcomes and activities of HCP.3.1.1 Process purpose Process benefits Process outcomes Process activities (typical) High-level objectives for human-centred quality are available taking account of the risks identified in HCP.3.1.2. Specific objectives for human-centred quality are established. NOTE: These: provide a basis for managing risks and opportunities, (HCP.3.1.2), defining the extent of HCD activities (HCP.3.1.3) and for providing more detailed user requirements (HCP.3.3.2). a) The context of use (including user groups) is known at a high level and the need to obtain more detail by data collection (user research) is identified. b) Verifiable objectives are set for usability. Examples: The average time that air passengers entering the United States will take to pass through immigration will be half the average time taken currently. Users are able to use the system without assistance on the first occasion they use it. c) Verifiable objectives are set for accessibility to enable the system to be used by people with the widest range of capabilities in the intended user populations. Example: People with diverse statures and strengths (including people seated in wheel chairs) will be able to purchase tickets from the ticket machine at all locations. d) Verifiable objectives are set for user experience. Examples: Potential users will believe that a forthcoming time management system will save time doing their travel expenses. Potential users want to have the product the first day of its release. Users will have confidence in the privacy of the system. Users will prefer the system compared to the equivalent system of the strongest competitor. Users feel secure that the coffee maker will not be harming the natural environment by producing unnecessary waste. e) Verifiable objectives are set for reducing relevant risks (for economic status, human life and health, environment and dissent across stakeholders). Examples: Users will be explicitly prevented from destroying data with the system. Medical staff using the system will be explicitly prevented from causing harm to patients. Existing users of the system will be as satisfied with the new operating system as new users. 1. Analyse the overall project objectives with respect to human-centred quality. [b] 2. Develop a high-level description of the context of use (list of user groups, tasks, equipment used, environment). [a] 3. Identify human-centred quality objectives for each attribute of human-centred ISO/IEC 2015 All rights reserved 23

quality (usability, accessibility, user experience and reduced risk). [b, c, d, e] 4. Communicate the human-centred quality objectives to relevant project stakeholders. [b] 7.3.1.2 Manage risks and opportunities related to the level of human-centred quality (HCP.3.1.2) [Editorial note: does the process as drafted sufficiently address opportunity management?] Table 8 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.1.2. Table 8: Purpose, outcomes and activities of HCP.3.1.2 Process purpose Process benefits Process outcomes Process activities (typical) To manage risks and opportunities related to the achieved level of human-centred quality. The risks that could arise from inadequate usability, accessibility or user experience are minimised and opportunities provided by superior levels of human-centred quality are recognised. a) The benefits and risks related to human-centred quality form part of the business case. b) The benefits that will result from good human-centred quality for the project stakeholders for whom the success of the system is critical are documented. c) The negative consequences are documented that could result from poor humancentred quality for the project stakeholders for whom the success of the system is critical. d) The opportunities for innovative solutions based on user needs. e) HCD methods are selected and tailored to give sufficient confidence that the required level of human-centred quality will be achieved in each project. f) Potential conflicts between human-centred quality and other quality attributes (e.g. usability versus security), or with the use of off-the-shelf components are identified. g) Project resources are determined based on an explicit assessment of risks to human-centred quality. 1. The development of the business case addresses issues related to humancentred quality. [a] 2. Identify project stakeholders for whom the success of the system is critical [b, c] 3. Establish any potential benefits that could result from superior human-centred quality. [b, d] EXAMPLES Medical application: to have patients spend less days needing dialysis. Consumer product: to have fewer customers initiating service calls. 4. Assess the potential risks resulting from poor human-centred quality (for the users, organisation or project, including risks to economic status, human life, health, or the environment). [c] EXAMPLE Expense reporting application: to have members of staff spending more time by entering additional data which were not previously required to be captured. 5. Resolve any potential conflicts between human-centred quality and other quality attributes (e.g. usability versus security), or with buy-or-build decisions related to off the shelf components. [f] 6. Determine project resources to mitigate risks to human-centred quality. [e, g] ISO/IEC 2015 All rights reserved 24

7.3.1.3 Define extent of HCD activities in the project (HCP.3.1.3) Table 9 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.1.3. Table 9: Purpose, outcomes and activities of HCP.3.1.3 Process purpose Process benefits To identify the appropriate level of HCD resources for the project. The activities and resources necessary to achieve the required level of humancentred quality are defined Process outcomes a) The scope of HCD activities needed to mitigate the risks identified by HCP 3.1.2 is defined. b) The HCD methods and techniques that are to be used are identified. c) Human centred design activities can be integrated in the overall project plan, starting at the earliest stages. d) The required resources (people, budgets, time) for each HCD activity are known. Process activities (typical) 1. Identify necessary data/information to be produced through HCD activities to meet the goals. [a] 2. Identify the method(s) used to obtain the required information. [b] 3. Identify which information produced through HCD activities is required when in the project. [c] 4. Plan overall set of HCD activities to be performed. [c] 5. Identify resources (people, budgets, time) for each HCD activity. [d] 7.3.1.4 Plan each HCD activity (HCP.3.1.4) Table 10 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.1.4. Table 10: Purpose, outcomes and activities of HCP.3.1.4 Process purpose Process benefits Process outcomes To ensure that each HCD activity and the work products for each HCD activity can be produced to the quality required for use by the project. The HCD activities needed to achieve the required levels of human-centred quality are planned. a) The resources (people, budgets, time) required for HCD activities are defined. b) The method(s) to be used to conduct each HCD activity are selected and customized as appropriate. c) The work products to be delivered for each HCD activity are specified. d) The HCD activities are integrated in the overall project plan, allowing for any necessary iteration. e) Effective procedures are established for feedback and communication on HCD activities as they affect other design activities and trade-offs, including an explanation and justification of the design decisions. f) Necessary representatives of users of the system are available as and when required to participate in HCD activities where necessary. g) The composition of the design team includes sufficient diversity in expertise to collaborate over design and implementation trade-off decisions at appropriate times. Human-centred design activities are carried out by suitably qualified and experienced staff. ISO/IEC 2015 All rights reserved 25

Process activities (typical) 1. Identify resources required (in terms of time, delay and effort) for sufficient iteration to mitigate risks. [a] 2. Select method(s) for conducting each HCD activity. [b] 3. Define work products to be produced for each HCD activity. [c] 4. Define suitable formats for documenting results of HCD activities. [c] 5. Identify at which point of time each work product is needed in the project. [d] 6. Plan each HCD activity in terms of resources (people, budgets, time). [d] 7. Assign competent staff (internal or external) to conduct each HCD activity. [f, g, h] 8. Tailor HCD procedures and customize associated tools and methods as appropriate to provide sufficient and timely information to the project. [b, c] NOTE See Annex B for a tailoring procedure. 7.3.1.5 Manage HCD activities within the project (HCP.3.1.5) Table 11 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.1.5. Table 11: Purpose, outcomes and activities of HCP.3.1.5 Process purpose Process benefits Process outcomes Process activities (typical) To ensure that each HCD activity is conducted as planned and the specified work products for each HCD activity are achieved with the required quality and are available for use in the project at the right time. The HCD activities needed to achieve the required levels of human-centred quality are carried out. a) Each HCD activity is conducted as specified to deliver the specified work product. b) Required work products of HCD activities are available as soon as needed as input to the project. c) Work products (e.g. system architecture) are improved where necessary based on the results of HCD activities. d) The project plan and HCD activities are adjusted where necessary based on emergent data delivered by HCD activities. 1. Ensure that work products of HCD activities are delivered in the agreed upon format. [a] 2. Monitor the accomplishment for each HCD activity. [a, b] 3. Identify where outputs of HCD activities point to needs for iteration and lead to changes in the overall project plan. [d] 4. Communicate work products of each completed HCD activity to stakeholders in project. [b] 5. Review the HCD activities within the project plan throughout the life of the project. [c] 6. Ensure that HCD work products are appropriately acted on. [c]. 7.3.2 Context of use for each user group (HCP.3.2) 7.3.2.0 Overall purpose and outcomes The purpose of this set of processes is to identify, clarify and communicate the characteristics of the users of the interactive system, their goals and tasks and the technical, organizational and physical environment of the interactive system. This can be for an actual context of use or for an intended context of use (see ISO/IEC 25063). The outcomes achieved by this set of processes are as follows. ISO/IEC 2015 All rights reserved 26

The characteristics of the actual or intended users, their goals and their tasks, including user interaction with other users and other interactive systems, are identified; The operational environment of the system, including the factors that affect the performance of users, is described in sufficient detail to support the design activities; Information about the context of use and its implications is available throughout the life cycle of the interactive system. NOTE Analysing, designing and evaluating human use of an interactive system can be addressed for a system in its current state, specified state and future state. A range of contexts of use may be considered including the context of introducing or selling and context of managing the system in operation. These outcomes are achieved by performance of the following sub-processes. 7.3.2.1 Identify and differentiate groups of users (HCP.3.2.1) Table 12 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.2.1. Table 12: Purpose, outcomes and activities of HCP.3.2.1 Process purpose Process benefits Process outcomes Process activities (typical) To identify and differentiate the groups of users, describing the relevant characteristics of the identified user groups. The users for whom human-centred quality is to be achieved are known and a basis for describing the context of use in which human-centred quality is to be achieved is available. a) User groups to be considered (for the interactive system to be designed or evaluated) are identified and their relevant characteristics (including the diversity of these characteristics) are described. b) User groups not to be considered (for the interactive system to be designed or evaluated) are identified. 1. Identify the user groups (users with similar characteristics and/or context of use relevant to the use) of the interactive system, their intended goals and any constraints (ISO/IEC 25063, ISO 20282-2). [a] 2. Ensure that potential users with accessibility needs are not unnecessarily excluded. [a] 3. Describe the attributes of each user group relevant for the interactive system to be designed or evaluated, including any needs for accessibility. [a] 4. Decide whether the quality of information is sufficient or whether further investigation is required. [a] 7.3.2.2 Identify context of use and reported issues (HCP.3.2.2) Table 13 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.2.2. Table 13: Purpose, outcomes and activities of HCP.3.2.2 Process purpose Process benefits Process outcomes To understand and determine users goals and tasks and ensure that sufficient information about the context of use is available to support the human-centred design of the interactive system. The context of use in which human-centred quality is to be achieved is described. a) The users tasks and related goals, outcomes, equipment (hardware and software), social and organizational environment, physical environment for all user groups to be supported are clearly communicated to all project members in ISO/IEC 2015 All rights reserved 27

sufficient detail to support the design activities. b) Existing problems, deficiencies and workarounds are identified. c) There is sufficient information to identify needs that are implied and/or contained in the context of use. Process activities (typical) 1. Agree on the scope for context of use analysis (e.g. tasks and environments to be focussed on) based on the purpose of the interactive system to be designed or evaluated. [a] 2. Select method(s) for collecting and describing context of use information (context interviews, observations, user self-reports, etc.). [a] 3. Research all aspects of the context(s) of use for each user group: actual user characteristics, tasks, goals and related outcomes, tools (hardware and software), technical environment (including development environment for the system to be built or advanced), resources, social and organizational environment, physical environment (ISO/IEC 25063), management structure, communications and organizational practices or legislation. [a, b] 4. Research to identify existing problems, deficiencies and workarounds related to systems in use. [b] 5. Conduct task analysis in order to understand identified tasks and the relationships between them. [a] 6. Describe the context of use for each intended/actual user group in a suitable format and sufficient detail for later use (e.g. user needs analysis, user requirements specification and evaluation). [a] 7. Decide whether the quality of information is complete and in sufficient detail or whether further investigation is required. [c] 8. Communicate information about the context of use to relevant project stakeholders. [a, b, c] 7.3.3 Establish the user requirements and related stakeholder requirements (HCP.3.3) 7.3.3.0 Overall purpose and outcomes The purpose of this set of processes is to ensure that a comprehensive set of valid and verifiable user requirements relevant for the context of use are specified for the interactive system to be developed. The outcomes achieved by this set of processes are as follows. The user needs for the context of use are identified. Human-centred quality requirements are set (specified in terms of usability, accessibility, user experience and reduced risk) for the system. User requirements are derived and specified. Those stakeholder requirements that have impact on the user requirements are identified. These outcomes are achieved by performance of the following sub-processes. ISO/IEC 2015 All rights reserved 28

7.3.3.1 Identify the user needs (HCP.3.3.1) Table 14 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.3.1. Table 14: Purpose, outcomes and activities of HCP.3.3.1 Process purpose Process benefits Process outcomes Process activities (typical) To provide the basis for deriving a comprehensive set of valid user requirements. The user needs for human-centred quality are identified. a) The user needs are comprehensively described and documented (ISO/IEC 25064). b) There is sufficient information to derive user requirements that adequately satisfy the user needs. 1. Analyse all data within the context of use description for user needs (i.e. prerequisites necessary for users to achieve the intended outcomes). [a, b] 2. Consult relevant stakeholders (i.e. typical users, subject matter experts, managers) to obtain a correct and complete set of user needs including those user needs imposed by organizational and management needs. [a, b] 3. State each user need as an outcome to be achieved by the user (what is to be achieved, rather than how) in the context of use and the associated prerequisites.[b] 4. Communicate the context of use (including any constraints imposed by the context of use) and the identified needs to all relevant project stakeholders. [b] 7.3.3.2 Specify the user requirements (HCP.3.3.2) Table 15 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.3.2. Table 15: Purpose, outcomes and activities of HCP.3.3.2 Process purpose Process benefits Process outcomes Process activities (typical) To specify a set of user requirements that provide the basis for designing system solutions that will satisfy the user needs. Human-centred quality is addressed in the user requirements. a) The intended context of use is specified to clearly identify the conditions under which the requirements apply. b) More precise human-centred quality objectives are specified as measurable user requirements. c) More detailed qualitative user requirements are derived based on the humancentred quality objectives and the user needs. d) User requirements are structured and prioritized in a form that can be used by the project team. e) Emergent organisational requirements that are critical to the success of the system and are derived from user requirements. f) The project team is informed about the required capability of the system from the user s perspective. g) The user requirements are stated in terms that enable subsequent evaluation. 1. Refine human-centred quality objectives (HCP.3.1.1) into more precise requirements. [b] 2. Identify for each user need (HCP.3.3.1), under which constraints which actions need to be enabled for the user in terms of: i) What information must the user be able to detect? e.g. The user shall be able to detect whether the heart rate of the patient is decreasing. (medical measurement device). ISO/IEC 2015 All rights reserved 29

ii) What information / physical entity must the user be able to enter/introduce into the system?; e.g. The user shall be able to place (i.e. enter ) a 24cm sauce pan in the fridge. (refrigerator). iii) What choices must the user be able to make? e.g. The user shall be able to select a rental car with automatic gear. (car rental website) [c, f] 3. Incorporate relevant guidance from ergonomics and user interface and interaction knowledge, standards and guidelines. [c] 4. Structure all identified user requirements by the corresponding task to be supported by the system. [a] 5. Identify and resolve potential conflicts among the user requirements themselves. [d] 6. Prioritize each user requirement (from the perspective of the users) with representatives of the user groups. [d] 7. Identify any user requirements derived from organizational requirements that directly affect the user. 8. Identify emergent organizational requirements that have to be implemented to enable the implementation of user requirements. Example: User requirement: The user of the warehouse system shall be able to assign a suitable ramp for each arriving truck. Emergent organizational requirement: The site control must categorize each type of truck as it arrives. [e] 9. Communicate the user requirements to all relevant project stakeholders. [f] 7.3.3.3 Negotiate the user requirements in the context of a project (HCP.3.3.3) Table 16 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.3.3. Table 16: Purpose, outcomes and activities of HCP.3.3.3 Process purpose Process benefits Process outcomes Process activities (typical) To ensure that potential conflicts between user requirements, stakeholder requirements and other project requirements are resolved. Human-centred quality and user requirements are taken into account in the specification of the interactive system. a) Agreement on the implementation of user requirements is reached (within and across user groups and stakeholders). b) Implementation priorities are assigned to all derived user requirements. c) An accepted and consistent set of user requirements can be used in the definition of system requirements. d) The feasibility of meeting the high priority user requirements forms part of feasibility studies for technical solutions 1. Identify dependencies between user requirements and other requirements including other stakeholder and project requirements (such as buy-or-build). [a] 2. Agree on scheme for implementation priorities. [b] 3. Identify the feasibility of and costs associated with implementing each user requirement and the risks associated with not implementing each user requirement. [c, d] 4. Assign an implementation priority to each user requirement. [b] 5. Document the rationales for any rejected user requirements so that these can be understood in the future. [c] ISO/IEC 2015 All rights reserved 30

7.3.4 Design ergonomic solutions that meet user requirements (HCP.3.4) 7.3.4.0 Overall purpose and outcomes The purpose of this set of processes is to incorporate user requirements and human-factors data into design solutions that can be evaluated to provide the basis for modifying the design solution to eliminate humancentred quality defects. The outcomes achieved by this set of processes are as follows: the design of the solution takes published human factors data into account; one or more design solution is available that takes account of the need to: o o o o allow interaction according to the sequence of activities and tasks to be supported; meet the accepted user requirements; adhere to user interface guidance; be in a form that can be evaluated against user requirements with real users; a basis for assessing the costs for implementation of a solution that meets user requirements is provided. These outcomes are achieved by performance of the following sub-processes. 7.3.4.1 Specify the user-system interaction (HCP.3.4.1) Table 17 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.4.1. Table 17: Purpose, outcomes and activities of HCP.3.4.1 Process purpose Process benefits Process outcomes Process activities (typical) To ensure that all necessary interactions of the users during task completion are identified and documented and the corresponding requirements can be implemented according to the task model for each task. Human-centred quality is the basis of the design of the user-system interaction. a) The overall task model to be supported is agreed upon b) The interaction between user and system is specified from the user s perspective. c) An appropriate allocation of function between users and technology is derived, taking account of the users strengths, limitations, preferences and expectations. d) All action-guiding information to be supplied during task completion is identified e) The required interaction objects for the interaction between user and system can be derived. f) The necessary system functions to enable the interaction between user and system can be derived. 1. Identify and specify each task to be supported with the system, based on the task analysis (as part of the context of use analysis) and the specified user requirements. [a] 2. Decompose each task into sub tasks as a set of activities meaningful to the intended user (task model). [b] 3. Describe for each task the precondition(s) and the intended outcome to be achieved. [b] 4. Define the rules for allocating actions between user and system as a meaningful set of tasks from the perspective of usability, accessibility, user experience and reduced risk. [c] 5. Specify which actions are allocated to the user and which actions and reactions (including action-guiding information to the user) are provided by to the system ISO/IEC 2015 All rights reserved 31

taking account of the users strengths, limitations, preferences and expectations, and involving representative users when possible. [c, d] 6. Decide whether the interaction specification is adequate for producing the design solution or whether further investigation is required. [e, f] 7.3.4.2 Produce and refine user interface design solutions (HCP.3.4.2) Table 18 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.4.2. Table 18: Purpose, outcomes and activities of HCP.3.4.2 Process purpose Process benefits Process outcomes Process activities (typical) To produce and iteratively evaluate user interface design solutions from a user perspective to ensure that user requirements have been met, and to minimize the risk that human-centred quality defects are not foreseen and cannot be eliminated economically. NOTE 1 The user interface design solution can be a prototype that is as simple as a sketch or static mock-up or as complicated as a fully functioning interactive system with more or less complete functionality. NOTE 2 The user interface design solution can be provided as a ready to use system (including a COTS or a ready-to-use Software Product, see ISO/IEC 25051). User interfaces are designed that satisfy the user requirements and meet humancentred quality objectives. a) A user interface design solution is available that enables completion of one or more tasks. b) The user s interaction with the user interface design solution has been evaluated before technical implementation. c) The development team has a basis for the technical implementation of the system. d) The degree of conformance with user requirements of the system intended for release is known. 1. Create a concept for interaction that addresses selected users requirements that aim for tasks defined in the context of use description. [a] 2. Identify appropriate dialogue techniques. [a] 3. Derive the required interaction objects, the sequence and timing (dynamics) of the interaction and the navigation structure. [a] 4. Design the information architecture of the user interface to allow efficient access to interaction objects. [a] Identify and apply appropriate user interface and interaction guidelines for the design of both hardware and software of the user interface according to the target platform. [a] 5. Construct testable user interface design alternatives with a level of detail and realism that is appropriate to the issues that need to be investigated. [a] 6. Evaluate the user interface design alternatives from a user perspective (HCP 3.5). [b] 7. Iteratively adapt the concept based on findings of user-centred evaluation until an acceptable cost-effective solution is obtained. [a, b] 8. Evaluate design with users in order to identify previously unidentified context information, emergent needs, refine the user requirements and to identify design improvements. [b] 9. Decide, if the user interface design solution sufficiently meets the user requirements. [d] ISO/IEC 2015 All rights reserved 32

10. Communicate the acceptable solution to the development team based on the user requirements and tasks to be supported by the solution. [c] NOTE: For a ready-to-use system (where the design is not under control of the project), evaluate the system (HCP 3.5) to determine whether is adequately meets then requirements established in HCP.3.4.1. 7.3.5 User-centred evaluation (HCP.3.5) 7.3.5.0 Overall purpose and outcomes The purpose of this set of processes is ensure that proposed designs are evaluated and the feedback is used to shape and improve the design throughout the lifecycle, specifically in relation to HCPs 3.2, 3.3, 3.4 and 4.0, that any human-centred quality defects are identified, and that the system is proven to meet the user requirements. The outcomes achieved by this set of processes are as follows. The design solutions that are most likely to provide human-centred quality are Identified and refined. Human-centred quality defects of the user interface are identified before implementation. Overlooked user requirements are identified before the system is implemented. Incompleteness and misinterpretations in the user interaction specification and user interface specification are identified before the system is implemented. The degree of conformance with user requirements of the system intended for release is known. These outcomes are achieved by performance of the following sub-processes. 7.3.5.1 Plan for evaluation throughout the project (HCD 3.5.1) Table 19 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.5.1. Table 19: Purpose, outcomes and activities of HCP.3.5.1 Process purpose Benefits Process outcomes To ensure appropriate user-centred feedback is available on design concepts and prototypes and enable use of the results for changing the interactive system (or the given representation of the system) at appropriate stages of the lifecycle. The user and human-centred quality requirements established in HCP.3.1.1 and HCP.3.3 are assessed. a) The purpose of each planned evaluation is identified. b) The necessary resources and infrastructure for each evaluation activity are planned. c) Appropriate methods to be employed for evaluation are agreed upon. d) The work products to be delivered for each evaluation activity are specified. e) Sufficient time is allocated for communication among design team participants, and for reconciling potential conflicts and trade-offs regarding human-system issues. f) The interactive system (or representation of the system) can be changed based on the evaluation results. ISO/IEC 2015 All rights reserved 33

Process activities (typical) 1. Identify which of the following types of evaluations apply in the context of the project [a]: i) ii) Evaluation of design concepts in order to refine the user requirements for the interactive system. Evaluation of prototypes in order to check that ergonomic guidance has been followed. iii) Evaluation of prototypes in order to improve the design. iv) Evaluation of prototypes to check that the user, other stakeholder and organisational requirements have been met. v) Evaluation of the interactive system in use in order to ensure that it continues to satisfy organisational and user needs. 2. Identify the characteristics of human-centred quality to be evaluated at appropriate stages of the project [a]. i) The presence of human-centred quality defects (related to usability, accessibility, user experience and reduced risk) in the design. ii) iii) iv) v) vi) The extent to which users can achieve their pragmatic and hedonic goals. Acceptable use of resources, including time, money and mental and physical effort. Acceptable risks of unacceptable consequences (including personal, business, health and safety risks). Trust. User engagement, frustration and/or pleasure. vii) The range of contexts of use in which the interactive system is usable (including the range of users for whom the system is accessible). viii) User satisfaction with any of the above. 3. Allocate resources including competent staff (internal or external) both for obtaining early feedback to improve the product, and later for determining if requirements have been satisfied [b]. 4. Plan the scope of later (summative) evaluation depending on the extent of the risks associated with not meeting requirements. [b] 5. Plan degree of iteration in terms of number of evaluation cycles to be expected taking account of project risks. [e] 6. Plan how evaluation results will be communicated to all relevant stakeholders. 7.3.5.2 Plan each evaluation (what to evaluate and how) (HCP.3.5.2) Table 20 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.5.2. Process purpose Benefits Table 20: Purpose, outcomes and activities of HCP.3.5.2 To identify the most appropriate evaluation methods is used and plan how the results will be used. The evaluation methods that are needed to ensure that requirements for humancentred quality are met are planned. ISO/IEC 2015 All rights reserved 34

Process outcomes Process activities (typical) a) The objectives of the evaluation are identified, which could include: i) identifying the aspects of human-centred quality to be evaluated (usability, accessibility, user experience and/or reduced risk); ii) identifying human-centred quality problems; iii) identifying recommendations for improving the human-centred quality of the object of evaluation; iv) identifying additional user requirements; v) obtaining a baseline for human-centred quality for the whole product; vi) comparing the human-centred quality of different products; vii) reporting conformity with specified criteria. b) The methods and work products for conducting the evaluations are agreed. c) The inspection-based or user-based evaluation is prepared. i) Target user group(s) for the interactive system is/are identified and for user- based evaluation, participants have the capabilities, characteristics and relevant previous experience that reflect the range of users for whom the system is being designed. ii) If tasks are used tasks are specified based on the users' intended objectives. iii) All relevant aspects of usability, accessibility and user experience are included. iv) The evaluation is based on a realistic context of use. v) Necessary resources for the evaluation are available (e.g. evaluators, users, test system, test room). vi) The evaluation is scheduled. 1. Identify the intended outcomes of the specific evaluation. [a] 2. Agree on the user group(s) to be considered for the evaluation (HCP.3.2.1). [c] 3. Select the context of use to be used for evaluation that adequately represents the real context of use. [c] 4. Agree appropriate methods for the inspection-based or user-based evaluation and the evaluation schedule. [b] NOTE When prototypes are being tested users provide feedback while carrying out tasks rather than just commenting on demonstrations that provide a preview of the design. 5. Ensure that the system is fit for evaluation and all resources are available. [c] 6. Plan the communication of evaluation outcomes. [b] 7.3.5.3 Carry out each evaluation (HCP.3.5.3) Table 21 describes the purpose, the outcomes and the process activities to be conducted within HCP.3.5.3. Table 21: Purpose, outcomes and activities of HCP.3.5.3 Process purpose Process benefits To obtain the information needed to achieve the evaluation objectives identified in HCP.3.5.2. Human-centred quality is assessed. ISO/IEC 2015 All rights reserved 35

Process outcomes Process activities (typical) a) Results are obtained for the evaluation objectives identified in H.C.P.3.5.2, such as the following. i) Human-centred quality defects are identified. ii) Recommendations are made for improving the human-centred quality of the object of evaluation; iii) Failures to meet user requirements are identified. iv) Overlooked user requirements are identified. v) Incompleteness and misinterpretations in the user interaction specification and user interface specification are identified. vi) A baseline is obtained for human-centred quality for the whole product; vii) Results that enable the human-centred quality of different products to be compared. b) Any issues are prioritised from a user perspective with proposed solutions. c) The evaluation results are documented in the form of the work products identified in HCP.3.5.2 and communicated to all relevant stakeholders involved in the process. d) Decisions are made on how to deal with any problems related to the humancentred quality for the redesign of the interactive system. e) Any necessary corrective actions are initiated. 1. Conduct evaluation according to agreed-upon methods. [a] 2. Analyse the evaluation results, prioritising any issues from a user perspective and proposing solutions. [b] 3. Document the evaluation results in the form of the agreed upon work product so that they can be used effectively by all relevant stakeholders in the process. [c] 4. Communicate the evaluation results to all relevant stakeholders involved in the process. [c] 5. Take account of the costs and benefits of proposed changes when deciding what will be modified. [d, e] 7.4 Introduction, operation and retirement of a system (HCP.4) 7.4.0 Overall purposes and outcomes The main audience for this set of processes is service and support managers, senior usability professionals, and educators and trainers. The types of risks addressed include operational risks, human-system issues in the service, and the quality of the service. The purpose of this set of processes is to identify unsatisfied needs and unsatisfactory system attributes during introduction, support and maintenance of the system in order to continuously meet stakeholder and user requirements The outcomes achieved by this set of processes are as follows. The transition into operation is managed. Feedback on the operation is obtained. The operation of the system is supported. Changes in context of use and user needs are identified. Necessary changes in the system are identified and implemented. The system continues to meet user needs throughout its lifecycle, including retirement. ISO/IEC 2015 All rights reserved 36

These outcomes are achieved by performance of the following processes. 7.4.1 Introducing the system (HCP.4.1) Table 22 describes the purpose, the outcomes and the process activities to be conducted within HCP.4.1. Table 22: Purpose, outcomes and activities of HCP.4.1 Process purpose Process benefits Process outcomes Process activities (typical) To manage change in order to ensure that human-centred quality is given sufficient attention throughout the implementation, introduction and validation of an interactive system. The factors necessary to achieve human-centred quality with the system are known and addressed. a) The needs of the users of the system related to introduction and adoption of the system are known by the project. b) The system takes sufficient account of applicable legal requirements (e.g. workplace design, software and hardware ergonomics). c) Users are aware off changes and innovations that are intended to achieve human-centred quality. d) The system can be adapted (as appropriate) to meet the requirements of individual implementations. e) First use problems are minimized. f) The product meets human-centred design objectives in the actual context of use. g) Human-system issues identified in rollout are resolved. 1. Determine impact of introduction on users. [a] 2. Identify needs for customization/localization, training and documentation and provide them as needed. [a, b] 3. Define communication to actual and potential users. [c] 4. Identify emerging human-system-issues. [d] 5. Monitor human-system-issues during roll out. [g] 6. Identify any differences between expected and actual context of use. [d, g] 7. Perform human-centred evaluation after introduction. [f] 8. Implement improvements related to interactive system. [e, g] 9. Implement process-related improvements related to future rollouts where applicable. [e] ISO/IEC 2015 All rights reserved 37

7.4.2 Human-centred quality in operation (HCP.4.2) Table 23 describes the purpose, the outcomes and the process activities to be conducted within HCP.4.2. Table 23: Purpose, outcomes and activities of HCP.4.2 Process purpose Process benefits Process outcomes Process activities (typical) To identify human-system issues in operation that impact on human-centred quality Human-centred quality is maintained a) Emergent requirements (including support requirements) of users are identified. b) The system is modified to address human-system issues identified by evaluation in use. c) The system can be customized for local use if/where appropriate. d) The system supports compliance with health and safety related requirements. 1. Monitor human-system-issues during operation. [d] 2. Identify any emergent human-centred quality requirements for the system. [a] 3. Investigate human-system issues associated to incidents affecting economic status, human life and health, environment or dissent across stakeholders. [b] 4. Analyse any changes in the context of use (users, tasks, equipment, environment) as well as the way the system is used. [b, c] 5. Implement necessary changes to maintain or improve human-centred quality. [b, c] 7.4.3 Human-centred quality in retirement (HCP.4.3) Table 24 describes the purpose, the outcomes and the process activities to be conducted within HCP.4.3. Table 24: Purpose, outcomes and activities of HCP.4.3 Process purpose Process benefits Process outcomes Process activities (typical) To take account of user needs in the close down, removal from service, decommissioning and destruction of a system. The factors that contributed to achievement of human-centred quality are described. a) User feedback and user performance information are considered as part of the decision to replace the system. b) User requirements for the new system take actual use into account. c) Existing functions that are important to the user are retained. 1. Investigate actual system usage. [a] 2. Identify the requirements for the future system based on how the existing system is used. [b] 3. Identify use-related human-system issues of the existing system. [b] 4. Identify consequences for users related to loss of the system. [b, c] ISO/IEC 2015 All rights reserved 38

Annex A (normative) Work products for the processes described in ISO 9241-220 A.1 Introduction Work products are the artefacts produced by the execution of processes. They can be used as follows: during process assessment the existence, content and quality of work products is an indicator of an organization or project s capability to perform processes; during process implementation a standard work product description (such as those in Annex D) can be used to define the content and quality of organization- or project-specific documents or other artefacts. The list of work products associated with a process can be used in the design of an organizational lifecycle model or project tailoring of the lifecycle. A.2 Format of the process work product list Table A.1 lists the work products associated with each of the processes described in ISO 9241-220. For each process two categories of work products are listed: Those are used as input for the process ( input work products ). This information that is useful to know when carrying out the process. Those are being produced by the process ( output work products ). This is information that is produced or changed as a result of carrying out the process. The last column of the table contains notes regarding particular human-centred issues for the work products related to the system lifecycle. In order to relate human-centred design to the information associated with the project and system activities the work products in ISO 9241-220 are derived from the ISO/IEC set of work products defined in ISO/IEC 25060 Common Industry Format (CIF) for usability: General framework for usability-related information and ISO/IEC 15504-6 An exemplar system lifecycle process assessment model. Each work product is prefixed by a reference number that indicates the work product and the standard in which it is defined. Work products from the 25060 series are preceded by CIF. Those from 15504-6 are prefaced by a two-part work product ID from that standard. Output work products are suffixed with the item number of the process outcome that creates or updates the works product. The information that comprises each work product is listed in tables in Annex D. For work products that are amended or extended by a process the information added is indicated by the referenced outcome. A.3 Use of the process work product list To get a full understanding of a work product and its purpose in relation to a process read: 1. the process description in clause 7; (for example clause 7.3.3.1, Table 14 Identify the user needs (HCP.3.3.1) ) 2. the relevant row in this table; (for example the row beginning Identify the user needs (HCP.3.3.1) ) ISO/IEC 2015 All rights reserved 39

3. the outcome(s) listed in the process description, the closest relation is indicated by the suffixed referenced letter; (for example Outcome a) The user needs are comprehensively described and documented and CIF.4 User needs report (a) ); and 4. the detail of the information within the work product in annex D (referenced by the prefixed work product ID or reference number), (for example the row beginning CIF4 User needs report ). A.4 Process work product list Table A.1 lists the work products for each HCP process that is described in Clause 7. Table A.1: Work products for each process described in ISO 9241-220 Process Input work products (for details see Annex D) Title Ensure enterprise focus on human-centred quality (HCP.1) Output work products (for details see Annex D) notes Incorporate humancentred quality in business strategy (HCP.1.1) Institutionalise human-centred quality (HCP.1.2) 3.02 supply strategy 3.03 business strategy 6.10 customer satisfaction report 8.08 quality management goals and objectives 3.02 supply strategy 3.03 business strategy 3.04 system life cycle management policy 6.04 system lifecycle model review 3.02 supply strategy (d,f,g) 3.03 business strategy (a,b) 6.06 investment decision report (d) 8.08 quality management goals and objectives (c,e) 3.01 acquisition strategy (a,b) 3.02 supply strategy (b,c) 3.08 quality management policy (b) 4.03 quality management system (b,c) 3.04 system life cycle management policy (d) 6.07 system life cycle process review (e) 8.09 quality measures (c) Enable Human-centred design across projects and systems (HCP.2) Integration of humancentred design (HCP.2.1) 3.04 system life cycle management policy 3.06 system life cycle process policy 3.08 quality management policy 6.07 system lifecycle process review 2.01 system lifecycle stage model (a) 3.04 system life cycle management policy (a,b) 3.06 system life cycle process policy (c) 3.11 technical management plan (d,f) 3.08 quality management policy (d) 4.02 system life cycles management procedure (b) 6.08 system lifecycle improvement report (e,f) ISO/IEC 2015 All rights reserved 40

Process Resources for human-centred design (HCP.2.2) Authorisation and control of humancentred quality (HCP.2.3) Input work products (for details see Annex D) 3.04 system life cycle management policy 3.06 system life cycle process policy 3.07 training strategy 3.08 quality management policy 3.01 acquisition strategy 4.01 supplier selection procedure 4.03 quality management system Execute Human-centred design within a project (HCP.3) Title Plan and manage human-centred design for the project (HCP.3.1) Output work products (for details see Annex D) 1.03 competent personnel (d) 2.04 system lifecycle process model (a,b) 3.06 system life cycle process policy (e) 3.07 training strategy (d) 3.11 technical management plan (a,b,c) 3.01 acquisition strategy (c) 4.01 supplier selection procedure (a) 5.01 supplier justification record 6.01 supplier assessment report (b) 6.02 delivery acceptance report (b) 6.03 supply performance report 6.11 quality management report 7.02 acquisition agreement change request 7.03 supply proposal (c) 7.06 supplier directive (a) 8.02 delivery acceptance criteria (a) 8.03 supply agreement (a) notes 3.1.1 technical management plan includes HCD procedures and HCD design guidelines, standards and human factors data related to human-centred quality ISO/IEC 2015 All rights reserved 41

Process Establish humancentred quality objectives (HCP.3.1.1) Input work products (for details see Annex D) 8.03 supply agreement 8.12 stakeholder requirements Title Output work products (for details see Annex D) CIF.5 user requirements (b,c,d,e) 8.04 project requirements (a) 8.09 quality measures (b,c,d,e) notes CIF.5 includes human-centred quality opportunities and risks Manage risk related to the achievement of human-centred quality (HCP.3.1.2) CIF.5 user requirements 8.04 project requirements 8.12 Stakeholder requirements 3.14 decision-making strategy (a,e,d) 3.15 risk management strategy (b,c,d) 5.04 risk register (b,c) 6.18 risk management report (f,g) Define extent of HCD activities in the project (HCP.3.1.3) Plan each HCD activity (HCP.3.1.4) Manage HCD activities within the project (HCP.3.1.5) CIF.5 user requirements 8.04 project requirements 3.11 Technical management plan 3.11 Technical management plan 2.01 tailored system life cycle stage model (c) 3.09 Project management plan (a) 3.11 technical management plan (b) 3.20 verification strategy (a) 3.22 validation strategy (a) 6.13 project resources and services report (d) 8.10 project team requirements (d) 2.02 tailored system life cycle process model (e) 3.09 Project management plan (a,b,c,d) 3.10 project acquisition plan (f,g) 3.13 project quality plan (c) 6.04 system life cycle model review (d) 6.07 system life cycle process review (d) 6.11 quality management report (a,c) 6.14 Project quality report (c,d) 6.15 Project progress report (b) Human Factors Integration Plan is in 3.09 and 3.11 7.4.3.1 Context of use for all user groups (HCP.3.2) Identify and differentiate groups of users (HCP.3.2.1) 8.04 project requirements 8.12 stakeholder requirements 2.07 stakeholders profile (a,b) 2.07 Includes User group profiles which is a synonym for a Target Audience Description (TAD)and personas Identify context of use and reported issues (HCP.3.2.2) 8.17 human-equipment interface requirements CIF 3 context of use description (a,b,c) Also in 8.12 Stakeholder requirements 7.4.3.2 Establish the user requirements (HCP.3.3) Identify the user needs (HCP.3.3.1) CIF 3 context of use description 7.10 operation request CIF.4 User needs report (a) 8.13 stakeholder requirements constraints on solution (a,b) ISO/IEC 2015 All rights reserved 42

Process Derive the user requirements (HCP.3.3.2) Negotiate the user requirements in the context of a project (HCP.3.3.3) Input work products (for details see Annex D) CIF.4 user needs report CIF.5 user requirements specification 8.13 stakeholder requirements constraints on solution Title Output work products (for details see Annex D) CIF.5 user requirements specification (b,c,d,e) 6.21 stakeholder requirements report (a) 8.16 system technical measures specification (f.g) 5.10 stakeholder requirements record (a,b,c) 6.22 system requirements report (c) 8.14 system requirements (b,c) 8.15 System requirements constraints on solution (d) notes In 8.12 Stakeholder requirements CIF.5 includes human-centred quality requirements specification ISO/IEC 2015 All rights reserved 43

7.4.3.3 Design ergonomic solution that meets user requirements (HCP.3.3.4) Specify the usersystem interaction (HCP.3.4.1) Produce and refine interface design solutions (HCP.3.4.2) CIF.3 context of use 8.13 stakeholder requirements constraints on solution 8.14 system requirements 8.15 system requirements constraints on solution 8.20 implementation constraints on solution 8.26 transition constraints on solution 8.28 validation constraints on solution 8.30 maintenance constraints on solution 8.32 disposal constraints on solution CIF.6 user interaction specification CIF.8 evaluation report 8.13 stakeholder requirements constraints on solution 8.15 system requirements constraints on solution 8.18 human-equipment interface requirements 8.20 implementation constraints on solution 8.26 transition constraints on solution 8.28 validation constraints on solution 8.30 maintenance constraints on solution 8.32 disposal constraints on solution 3.11 technical management plan CIF.6 user interaction specification (b,d,e) 2.08 system functional model (c,f) 8.18 human-equipment interface requirements (e) 5.1.1 system requirements traceability (a,f) CIF.7 user interface specification (a,b,c,d) 2.09 Architectural design description (c) 8.17 system interface requirements (c) In 8.17 System interface requirements Technological possibilities are in 8.17 system interface requirements. Refinement includes development of low-fidelity prototypes. User-centred evaluation (HCP.3.5) Plan for evaluation throughout the project (HCD 3.5.1) Plan each evaluation (what to evaluate and how) (HCP.3.5.2) 3.20 verification strategy 3.22 validation strategy 3.20 verification strategy 3.22 validation strategy verification procedure (a,c,d,e,f) 4.08 validation procedure (a,c,d,e,f) 8.25 Verification enabling system requirement (b,c,d,e) 8.29 validation enabling system requirements (b,c,d,e) 4.06 verification procedure (a,b,c) 4.08 validation procedure (a,b,c) 8.28 validation constraints on solution (b) Overall V&V procedures Specific V&V protocols Test cases are included in V&V procedures. (e.g. scenarios) ISO/IEC 2015 All rights reserved 44

Carry out each evaluation (HCP.3.5.3) 4.06 verification procedure (a,b,c) 4.08 validation procedure (a,b,c) CIF.8 evaluation report (a,b,c,d) 1.08 verified system (e) 1.10 validated system (e) 5.09 stakeholder requirements traceability (a,c,d) 5.17 verification record (a) 5.19 validation record (a) 6.26 verification report (b,d) 6.28 validation report (b,d) See ISO/IEC 25062 and ISO/IEC 25066 for details of reporting. 7.4.3.4 Introduction, operation and retirement of a system (HCP.4) Introducing the system (HCP.4.1) 3.19 integration strategy 3.21 transition strategy CIF.9 field data report (f,g) 1.06 qualified operators (a) 1.11 operational system (d,f) 3.07 training strategy (a,c,e) 3.12 service management plan (f) 3.19 integration strategy (a,e,g) 3.21 transition strategy (e,g) 4.04 implementation procedure (a,c,d,e,g) 4.07 transition procedure (e,g) 5.18 transition record (a,f) 6.27 transition report (e,g,) 8.20 implementation constraints on solution (a,b,d) 8.26 transition constraints on solution (a,e,g) 8.27 transition enabling system requirements (a,d,f) Includes user documentation (Training materials, guides, online support, user awareness programme) Human-centred quality in operation (HCP.4.2) 1.06 qualified operators 1.11operational system 3.07 training strategy 3.12 service management plan 3.23 operation strategy 3.24 maintenance strategy CIF.9 field data report (a,d) 1.11operational system (b) 4.10 maintenance procedure (a,b) 5.20 operation record (b,d) 5.21 maintenance record (a,b) 6.03 supply performance report (a,d) 6.10 customer satisfaction report (a,b) 6.16 corrective action report (b,c) 6.29 operation report (b,d) 6.30 maintenance report (b) 7.10 operation request (b,d) 8.17 human-equipment interface requirements (a,b,c) 8.30 maintenance constraints on solution (b,c,d) 8.31 maintenance enabling system requirements (a,c,d) Human-centred quality in retirement (HCP.4.3) 3.26 disposal strategy CIF.9 field data report (a,b) 1.12 waste products (b,c) 4.15 disposal procedure (c) 6.31disposal report (a,c) 8.32 disposal constraints on solution (a,b,c) 8.33 disposal enabling systems requirements (c) ISO/IEC 2015 All rights reserved 45

Annex B (normative) Conformance and Tailoring B.1 Introduction Annex B provides requirements for conformance to, and tailoring of, ISO 9241-220. Most applications of ISO 9241-220 will be informal, for example, using the processes as guidance, an informal framework for humancentred design, or processes to include in other process models. Where the application of the standard is formal and a statement of compliance is needed the requirements of Annex B shall be followed. Where conformance to an adapted version of ISO 9241-220 is needed the requirements of the tailoring process in clause B.3 shall be applied. Tailoring is not a requirement for conformance to the standard. In fact, tailoring is not permitted if a claim of "full conformance" is to be made. If a claim of "tailored conformance" is made, then the process in B.3 is applied to perform the tailoring. B.2 Conformance B.2.1 Introduction There are two ways that an implementation of the processes in ISO 9241-220 can be claimed to conform to the provisions of ISO 9241-220. Either, conformance to a selected set of unchanged processes, or, conformance to a set of processes that have been adapted ( tailored ) to meet particular contractual, organizational or project requirements using the process described in B.3 below. All claims of conformance shall be cited in one of the two forms given in B.2.2 or B.2.3 below. B.2.2 Conformance to a selected set of unchanged processes A claim of full conformance declares the set of processes for which conformance is claimed. Full conformance is achieved by demonstrating that the declared set of processes has been implemented using the outcomes as evidence. B.2.3 Conformance to tailored processes A selected set of processes can also be tailored to the specific needs of a project. The tailored text, for which conformance is claimed, is declared. Tailored conformance is achieved by demonstrating that requirements for the processes, as tailored, have been satisfied using the outcomes as evidence. The clauses of ISO 9241-220 are selected or modified in accordance with the tailoring process prescribed in Clause B.3 of ISO 9241-220. Any organization (for example, national, industrial association, company) imposing ISO 9241-220, as a condition of trade, should specify and make public the minimum set of required processes, activities, and tasks, which constitute suppliers' conformance with ISO 9241-220. When ISO 9241-220 is used to help develop an agreement between an acquirer and a supplier, clauses of ISO 9241-220 can be selected for incorporation in the agreement with or without modification. In this case, it is more appropriate for the acquirer and supplier to claim compliance with the agreement than conformance with this part of ISO 9241. NOTE 1 Requirements of ISO 9241-220 are marked by the use of the verb "shall". Recommendations are marked by the use of the verb "should". Permissions are marked by the use of the verb "may". NOTE 2 An example of tailored conformance would be to tailor the processes to only include the requirements of ISO 9241-210 in order to make a process assessment of compliance to ISO 9241-210. ISO/IEC 2015 All rights reserved 46

B.3 Tailoring Process B.3.1 Purpose The purpose of the Tailoring Process is to adapt the processes of ISO 9241-220 to satisfy particular circumstances or factors that: a) surround an organization that is employing ISO 9241-220 in an agreement; b) influence a project that is required to meet an agreement in which ISO 9241-220 is referenced; c) reflect the needs of an organization in order to supply products or services. B.3.2 Outcomes As a result of the successful implementation of the Tailoring Process: a) Modified or new life cycle processes are defined to achieve the purposes and outcomes of a life cycle model. B.3.3 Activities and tasks If ISO 9241-220 is tailored, then the organization or project shall implement the following tasks in accordance with applicable policies and procedures with respect to the Tailoring Process, as required. a) Identify and document the circumstances that influence tailoring. These influences include, but are not limited to: 1) stability of, and variety in, operational environments; 2) risks, commercial or performance, to the concern of interested parties; 3) novelty, size and complexity; 4) starting date and duration of utilization; 5) integrity issues such as safety, security, privacy, human-centred quality, availability; 6) emerging technology opportunities; 7) profile of budget and organizational resources available; 8) availability of the services of enabling systems; 9) roles and responsibilities in the overall life cycle of the system; 10) the need to conform to other standards. b) In the case of properties critical to the system, take due account of the life cycle structures recommended or mandated by standards relevant to the dimension of the criticality. c) Obtain input from all parties affected by the tailoring decisions. This includes, but is not necessarily limited to: 1) the system stakeholders; 2) the interested parties to an agreement made by the organization; ISO/IEC 2015 All rights reserved 47

3) the contributing organizational functions. d) Make tailoring decisions to achieve the purposes and outcomes of the selected life cycle model. NOTE 1 Organizations establish standard life cycle models as a part of life cycle model management. It can be appropriate for an organization to tailor processes of ISO 9241-220 in order to achieve the purposes and outcomes of the stages of a life cycle model to be established. NOTE 2 Projects select an organizationally-established life cycle model for the project as a part of the project planning process. It can be appropriate to tailor organizationally adopted processes to achieve the purposes and outcomes of the stages of the selected life cycle model. NOTE 3 In cases where projects are directly applying ISO 9241-220, it can be appropriate to tailor processes of ISO 9241-220 in order to achieve the purposes and outcomes of the stages of a suitable life cycle model. e) Select the life cycle processes that require tailoring and delete selected outcomes, activities, or tasks. NOTE 4 Irrespective of tailoring, organizations and projects are always permitted to implement processes that achieve additional outcomes or implement additional activities and tasks beyond those required for conformance to this standard. An organization or project can encounter a situation where there is the desire to modify a provision of ISO 9241-220. Modification should be avoided because it may have unanticipated consequences on other processes, outcomes, activities or tasks. If necessary, modification is could by deleting the provision (making the appropriate claim of tailored conformance) and, with careful consideration of consequences, implementing a process that achieves additional outcomes or performs additional activities and tasks beyond those of the tailored standard. B.3.4 Procedure for identifying work products and their contents The following steps should be performed while developing an information management plan and a documentation plan, to determine what work products are needed and the work product contents: 1. Review and tailor Clause 7, to determine the human-centred life cycle model for the project. 2. Examine Annex A and Annex D to match the work products with the organization and project s life-cycle processes and services. 3. Tailor Annex A and Annex D to satisfy the project s documentation needs and requirements. 4. Determine and list what work products are deliverable documents, intermediate deliverables, or nondeliverables; and what work products are to be archived. NOTE This step is performed based on applicable agreements and organizational policies. 5. Determine work product content requirements for the life cycle, organization and project or service, using Annex A and Annex D. 6. Tailor and finalize the content requirements of each required work products. 7. Determine the title, style, format and schedule of each work product or work product type, including provisions for updates of preliminary and intermediate work products. 8. Examine Annex A and Annex D to identify sources of input work product inputs. 9. Develop a plan for information reuse: consider what is common among work products and applicable work products types, define a hierarchy of work products, and select a method or system for sharing information sources and content among related work products. 10. Define the procedures for configuration management of intermediate and final work product versions. ISO/IEC 2015 All rights reserved 48

11. Determine the quality characteristics of each work product and work product type. 12. Determine how the quality characteristics will be evaluated for each work product and work product type. 13. Define the deliverable work product review and approval criteria and process, including authority, responsibilities and title of individuals who can approve each work product. 14. Determine how long the archived work products are to be stored and on what media, for example, paper or disk. 15. Include the actions and results of the above activities in a documentation plan. ISO/IEC 2015 All rights reserved 49

Annex C (informative) Cross-reference between ISO 9241-210 and ISO 9241-220 HCPs Annex C cross-references the processes in ISO 9241-220 that can be used to achieve conformance with each requirement and recommendation in ISO 9241-210. In most cases the specific activity or outcome in the process is indicated by appending a letter for the outcome or a digit for the activity. Table C.1 Cross-reference between ISO 9241-210 and ISO 9241-220 clauses Clause in ISO 9241-210 Requirement or recommendation HCP reference 4 Principles of human-centred design 4.1 Whatever the design process and allocation of responsibilities and roles adopted, a humancentred approach should follow the principles listed in ISO 9241-210. 4.2 Products, systems and services should be designed to take account of the people who will use them as well as other stakeholder groups including those who might be affected by their use. HCP.3 4.2 All relevant user and stakeholder groups should be identified. [see also 6.2.2a] HCP.3.2.1 4.3 User involvement should be active. HCP.3.1.4.f HCP.3.3.1.2 4.3 The users who are involved should have capabilities, characteristics and experience that reflect the range of users for whom the system is being designed. [see also 6.2.2b] 4.4 User centred evaluation should take place as part of final acceptance of the product to confirm that requirements have been met. 4.5 Iteration should be used to progressively eliminate uncertainty during the development of interactive systems. 4.6 The users experience of previous or other systems and issues such as branding and advertising should also be considered. 4.6 Users strengths, limitations, preferences and expectations should be taken into account when specifying which activities are carried out by the users and which functions are carried out by the technology. 4.6 Representative users should generally be involved in decisions related to the allocation of function. 4.6 The human activities resulting from the allocation of function should form a meaningful set of tasks. 4.7 Human-centred design teams do not have to be large but the team should be sufficiently diverse to collaborate over design and implementation trade-off decisions at appropriate times. HCP.3.3.1.2 HCP.3.5.2.c HCP.3.4.2.8 HCD 3.5.1.5 HCP.3.5.2.c HCP.3.4.1.5 HCP.3.4.1.5 HCP.3.4.1.4 HCP.3.1.4.g 5 Planning human-centred design 5.1 Human-centred design shall be planned and integrated into all phases of the product life cycle. HCP.3.1 5.2 Those responsible for planning the project shall consider the relative importance of usability in the project by evaluating: 5.2.a) how usability relates to the purpose and use of the product, system or service; HCP.3.1.2.a ISO/IEC 2015 All rights reserved 50

5.2.b) the levels of the various types of risk that might result from poor usability; HCP.3.1.3.a 5.2.c) the nature of the development environment. HCP.3.1.3.c 5.3 The planning of human-centred design shall include: 5.3.a) identifying appropriate methods and resources for the activities described in Clause 5; 5.3.b) defining procedures for integrating these activities with other system development activities; 5.3.c) identifying the individuals and the organization(s) responsible for the HCD activities and the range of skills and viewpoints they provide; 5.3.d) developing effective procedures for establishing feedback and communication on HCD activities as they affect other design activities and trade-offs, and methods for documenting these activities; 5.3.e) agreeing on appropriate milestones for human-centred activities integrated into the overall design and development process; 5.3.f) agreeing on suitable timescales to allow iteration, use of feedback, and possible design changes, to be incorporated into project schedule. 5.4 The plan for human-centred design shall form part of the overall system development project plan. 5.4 To ensure that it is followed through and implemented effectively the plan for humancentred design should be subject to the same project disciplines (e.g. responsibilities, change control) as other key activities 5.4 The HCD aspects of the project plan should be reviewed and revised as requirements change as appropriate throughout the life of the project. HCP.3.1.3.b HCP.3.1.3.c HCP.3.1.3.d HCP.3.1.4.e HCP.2.1.c HCP.3.1.4.d HCP.2.1.b HCP.3.1.3.c HCP.3.1.5.d 5.5 Project planning shall allocate time and resources for the human-centred activities. HCP.3.1.3.d 5.5 [The plan] shall include time for iteration and the incorporation of user feedback, and for evaluating if the design solution satisfies the user requirements. 5.5 Additional time should be allocated for communication among design team participants and for reconciling potential conflicts and trade-offs that involve human-system issues. HCP.3.1.4.1 HCP.3.5.1.e 5.5 Human-centred design activities should start at the earliest stage of the project. HCP.3.1.3.c 5.5 The HCD aspects of the project plan should be reviewed throughout the life of the project. HCP.3.1.5.d 6 Human-centred design activities 6.1 There are four linked HCD activities that shall take place during the design of any interactive system 6.1.a) Understand and specify the context of use HCP.3.2 6.1.b) Specify the user requirements. HCP.3.3 6.1.c) Produce design solutions. HCP.3.4 6.1.d) Evaluate HCP.3.5 6.2.2.a) Relevant groups shall be identified and their relationship with the proposed development described in terms of key goals and constraints. HCP.3.2.1.1 6.2.2.b) Relevant characteristics of the users shall be identified. HCP.3.2.1.a 6.2.2.b) If necessary, the characteristics of different types of users should be defined HCP.3.2.1.a 6.2.2.b) In order to achieve accessibility, products, systems and services should be designed to be used by people with the widest range of capabilities in intended user populations. HCP.3.1.1.c 6.2.2.c) The task goals of the users and the overall goals of the system shall be identified. HCP.3.2.2.a 6.2.2.c) The characteristics of tasks that can influence usability and accessibility shall be described. HCP.3.2.2.a ISO/IEC 2015 All rights reserved 51

6.2.2.c) Any potential adverse consequences for health and safety should be identified HCP.3.1.2.c 6.2.2.c) If the task can be completed incorrectly, this should be identified HCP.3.1.2.c 6.2.2.c) 6.2.2.d) 6.2.2.d) Tasks should not be described solely in terms of the functions or features provided by a product or system. The technical environment, including the hardware, software and materials, shall be identified. The relevant characteristics of the physical, social, organizational and cultural environment shall be described. HCP.3.2.2.a HCP.3.2.2.a HCP.3.2.2.a 6.2.3 The context of use of the system should be described in sufficient detail to support the design activity. 6.2.4 The intended context of use should be specified as part of the user requirements specification to clearly identify the conditions under which the requirements apply 6.3.1 Identifying user needs and specifying the functional and other requirements for the product or system should be extended to create an explicit statement of user requirements in relation to the intended context of use and the business objectives of the system. 6.3.1 If the proposed interactive system will impact on organizational practice the development process should involve organizational stakeholders in the design process with the aim of optimising both the organizational and technical systems. HCP.3.2.2.a HCP.3.3.2.a HCP.3.3.1 HCP.3.3.2 HCP.3.3.3 6.3.2 User and other stakeholder needs should be identified, taking account of the context of use. HCP.3.3.1 6.3.2 User and other stakeholder needs should include what users need to achieve (rather than how) and any constraints imposed by the context of use. HCP.3.3.1.3 HCP.3.3.1.4 6.3.3 The specification of user requirements shall include: 6.3.3.a) the intended context of use; HCP.3.3.2.a 6.3.3.b) requirements derived from the user needs and the context of use; HCP.3.3.2.c 6.3.3.c) 6.3.3.d) requirements arising from relevant ergonomics and user interface knowledge, standards and guidelines; usability requirements and objectives including measurable usability performance and satisfaction criteria in specific contexts of use; HCP.3.3.2.3 HCP.3.3.2.b 6.3.3.e) requirements derived from organizational requirements that directly affect the user HCP.3.3.2.7 6.3.4 Potential conflicts between user requirements should be resolved. HCP.3.3.2.5 6.3.4 The rationales for any trade-offs should be documented so that they can be understood in the future. HCP.3.3.3.5 6.3.5 The user requirements specification should be: 6.3.5.a) stated in terms that permit subsequent testing; HCP.3.3.2.g 6.3.5.b) verified by the relevant stakeholders; HCP.3.3.3 6.3.5.c) internally consistent; HCP.3.3.3.c 6.3.5.d) updated as necessary, during the life of the project. HCP.3.5.3.a 6.4.1 Producing design solutions should include the following sub-activities: 6.4.1.a) designing user tasks, interaction and interface to meet the user requirements, considering the overall user experience; HCP.3.4.1 6.4.1.b) making the design solutions more concrete; HCP.3.4.2 6.4.1.c) altering the design solutions in response to user centred evaluation and feedback; HCP.3.4.2.7 6.4.1.d) communicating the design to those responsible for implementation. HCP.3.4.2.c 6.4.2.1 The following principles (taken from ISO 9241-110) should be taken into account when designing ISO/IEC 2015 All rights reserved 52

interactive systems: 6.4.2.1.a) suitability for the task HCP.2.2 6.4.2.1.b) self-descriptiveness HCP.2.2 6.4.2.1.c) conformity with user expectations HCP.2.2 6.4.2.1.d) suitability for learning HCP.2.2 6.4.2.1.e) Controllability HCP.2.2 6.4.2.1.f) error tolerance HCP.2.2 6.4.2.1.g) suitability for individualization HCP.2.2 6.4.2.2 Designing the interaction should include: 6.4.2.2.a) making high level decisions; HCP.3.4.1 6.4.2.2.b) identifying tasks and sub-tasks; HCP.3.4.1.a 6.4.2.2.c) allocating tasks to user and system; HCP.3.4.1.c 6.4.2.2.d) identifying the interaction objects required for the completion of the tasks; HCP.3.4.2.3 6.4.2.2.e) identifying appropriate dialogue techniques; HCP.3.4.2.2 6.4.2.2.f) designing the sequence and timing (dynamics) of the interaction; HCP.3.4.2.4 6.4.2.2.g) designing the information architecture of the user interface of an interactive system to allow efficient access to interaction objects. 6.4.2.3 Ergonomics and user interface knowledge, standards and guidelines should be used to inform the design of both hardware and software of the user interface. 6.4.3 The level of detail and realism [of prototypes] should be appropriate to the issues that need to be investigated. HCP.3.4.2.4 HCP.3.4.2.5 HCP.3.4.2.6 6.4.4 Feedback from evaluation should be used to improve and refine the system. HCP.3.4.2.8 6.4.4 The costs and benefits of proposed changes should be evaluated and used to inform decisions about what will be modified. 6.4.4 Project plans should allow sufficient time for making the changes as a result of such feedback. 6.4.5 There should be some sustained channel of communication between those responsible for human-centred design and other members of the project team. 6.4.5 When design solutions are communicated, they should be accompanied by an explanation and justification of the design decisions especially where trade-offs are necessary. HCP.3.4.2.8 HCP.3.1.5.d HCP.2.1.4 HCP.3.1.4.e 6.4.5 The communication [of details of the design] should take account of the constraints imposed by the project and the level of knowledge and understanding about ergonomics and user interface design. 6.5.1 User centred evaluation is a required activity in human-centred design. HCP.3.5 6.5.1 Even at the earliest stages in the project, design concepts should be evaluated to obtain a better understanding of the user needs. 6.5.1 If user-based testing is not practical or cost effective at a particular stage of a project, design solutions should be evaluated in other ways. HCP.3.4.2.8 HCP.3.5.1.1 HCP.3.5 6.5.2 User centred evaluation should involve: 6.5.2.a) allocating resources both for obtaining early feedback to improve the product, and later for determining if requirements have been satisfied; HCD 3.5.1.3 6.5.2.b) planning the user centred evaluation so that it fits the project time schedule; HCD 3.5.1 6.5.2.c) sufficiently comprehensive testing to give meaningful results for the system as a whole; ISO/IEC 2015 All rights reserved 53

6.5.2.d) analysing the results, prioritising issues and proposing solutions; HCP.3.5.3.2 6.5.2.e) communicating the solutions appropriately so that they can be used effectively by the design team. HCP.3.5.3.c 6.5.3 To obtain valid results, the evaluation should be carried out by experienced practitioners, (and) HCP.3.1.4.g 6.5.3 [To obtain valid results the evaluation] should use appropriate methods. HCP.3.5.1.c 6.5.3 Resources for evaluation should be allocated both for obtaining early feedback to improve the product, and later for determining if requirements have been satisfied. 6.5.3 The scope of this latter (summative) evaluation should depend on the extent of the risks associated with not meeting requirements. 6.5.4 When prototypes are used, they should be used to collect user feedback while carrying out tasks rather than just being demonstrations to show users a preview of the design. 6.5.6 A HCD process should include long term monitoring of the use of the product, system or service. 6.5.6 Criteria and measurements [for long term monitoring] should be sensitive enough to identify system failure, or system problems, as early as possible. HCP.3.5.1.b HCP.3.5.1.4 HCP.3.5.2.c HCP.4.2 HCP.4.1 HCP.4.2 ISO/IEC 2015 All rights reserved 54

Annex D (informative) Descriptions of work products D.1 Introduction This Annex lists the work products to be used and produced by each HCD process and outlines their content. D.2 Use of work products Work product characteristics listed in this Annex can be used when reviewing potential inputs and outputs of process implementation. The characteristics are provided as guidance for the attributes to look for, in a particular sample work product, to provide objective evidence supporting the assessment of a particular process. Work products and their characteristics should be considered as a starting point for considering whether (given the project context) they are contributing to the intended purpose of the process, not as a checklist of what every organization must have. A documented process and assessor judgment are required to ensure that the process context (application domain, business purpose, development methodology, size of the organization, etc.) is considered when using this information. Work products are defined using the scheme described in ISO/IEC 25060. This scheme is described in sub-clause D.4. In order to give flexibility the medium used to describe the work products is not defined. For example, in large, critical systems projects there is a reliance on documentation, while in software projects using Agile development methods there is more reliance on personal communication. D.3 Sources of the work products To ensure integration of human-centred design processes with the system lifecycle ISO 9241-220 where possible maps the outcome of human-centred design to system lifecycle work products described in ISO/IEC 15504-6. This is done in Annex A. In some cases the work products are unique to human-centred design. These work products are outlined in ISO/IEC 25060 and are being documented in detail in a series of International Standards under the title Common industry format for usability-related information. ISO/IEC 250662 Test reports, ISO/IEC 25063 Context of use description, ISO/IEC 25064 User needs report and ISO/IEC 25066 Evaluation report have been published so far. This part of ISO 9241 uses both these sets of work products and maps them to the appropriate processes. D.4 Generic Work Products Table D.1 describes the components of the work product descriptions in this Annex. Table D.1 Work product identification Work product identifier # Work product name An identifier number for the work product that is used to reference the work product. Provides an example of a typical name associated with the work product characteristics. This name is provided as an identifier of the type of work product the practice or process might produce. Organizations might call these work products by different names. The name of the work product in the organization is not significant. Similarly, organizations might have several equivalent work products, which contain the characteristics defined in one work product type. The formats for the work products can vary. It is up to the assessor and the organizational unit coordinator to map the actual work products produced in their ISO/IEC 2015 All rights reserved 55

organization to the examples given here. Work product characteristics Provides examples of the potential characteristics associated with the work product types. The assessor may look for these in the samples provided by the organizational unit. Table D.2 describes the generic types of the work products described in Annex D.2. Table D.2 Types of work product WP ID Generic Work Generic Work Product Description Product Type 1.00 object An entity created to serve a purpose, or created in the course of serving that purpose. Its existence is observable and rationalised by its material or behavioural characteristics. It can exist as a complete, partial or exemplifying realization of a product, be a subordinate part of a product, be a by-product or be a part of an enabling system 2.00 description An account or representation of a proposed or actual object or concept. It can be a textual, pictorial, graphical or mathematical representation. It can be in a standardised form for human or machine interpretation. It can be a static or dynamic model or a simulation representing reality. It can establish order, structure, grouping or classification. 3.00 plan A proposed scheme or systematic course of action for achieving a declared purpose. It predicts how to successfully accomplish objectives in terms of specific actions, undertaken at defined times and employing defined resources. It can apply to technical, project or enterprise actions. At a high level of abstraction it can be a policy or, with reference to assets and their disposition, a strategy. 4.00 procedure A declared way of formally conducting a customary course of action. It defines an established and approved way or mode of conducting business in an organization. It can detail permissible or recommended method in order to achieve technical or managerial goals or outcomes. 5.00 record A permanent, readable form of data, information or knowledge. Accessible and maintained evidence of the existence or occurrence of facts, events or transactions. It can take the form of a journal chronicle, register or archive. It can contain the information to confirm achievement of performance, fiscal or legal conditions or obligations. 6.00 report An account prepared for interested parties in order to communicate status, results or outcomes. It is a result of information gathering, observation, investigation or assessments, and it can impart situation, affects, progress or achievement. It serves to inform so that decisions or subsequent actions can be taken. 7.00 request A communication that initiates a defined course of action or change in order to fulfil a need. This can originate or control on-going action based on an agreed plan or procedure. It can result in a proposal or plan of action. It can take the form of a solicitation, requisition, instruction or demand for a resource, product, service or an approval to act. 8.00 specification Criteria or conditions that place limits or restrictions on actions, attributes or qualities. It establishes measures or qualities for determining acceptability, conformance or merit. It can be required as part of an agreement or contract. ISO/IEC 2015 All rights reserved 56

D.5 Specific work products related to human-centred quality described in ISO/IEC TR 25060 Table D.3 describes the work products specified in the ISO/IEC 25060 series common industry formats for usability. The column Where to use in ISO 9241-220 lists the HCP that uses or updates the work product. The suffix I indicates that the WP is an input to the process and O indicates that it is an output. Where no code is given the WP is an output. Table D.3 HCD work products from ISO/IEC 25060 WP ID Work Product Name Work Product Typical Characteristics CIF3 Context of use The overall goals of the system. description The stakeholder groups who either use the interactive system or are affected by its output throughout the life cycle of the interactive system. The characteristics of the users. The task goals and task characteristics. Information processed during tasks. Technical environment (hardware, software and materials). Physical and social environments. CIF4 User needs report Identified, stated, derived and implied user needs across all identified user groups (cognitive, physiological, social). The user needs derived from or modified on the basis of other stakeholders that have been identified to be relevant within the context of use description. The results of the user needs analysis relating the described context of use and its development constraints to the tasks of each user group who are affected including any resulting human-system issues or risks. CIF5 User Reference to the context of use description intended for the design. requirements specification Requirements derived from the user needs and the context of use; for example, there might be a requirement for a product to be used outdoors. Requirements arising from relevant ergonomics and user interface knowledge standards and guidelines. Usability requirements and objectives including measurable effectiveness efficiency and satisfaction. Criteria in specific contexts of use. Requirements derived from organizational requirements that directly affect the user. CIF6 User interaction specification Workflow design: the overall interrelationship (including sequences) between tasks and system components on an organizational level, including responsibilities and roles. Task design: all tasks broken down into sets of sub tasks and allocation of sub tasks to the user and the system and associated requirements. Dialogue model: for each task, the appropriate information exchange between user and system including sequence and timing as well as associated interaction objects and high-level selection of dialogue techniques. Task specific detailed usability objectives. CIF7 User interface specification Information architecture: from the user's perspective. The task objects and system objects needed to accomplish one or more tasks and the user interface elements that they are composed of. Their properties, behaviours and relationships. The dialogue techniques employed for specific tasks (e.g. menus, form based dialogues, command dialogues, combinations of those). Views of task objects and system objects for specific tasks, users and user groups. ISO/IEC 2015 All rights reserved 57

WP ID Work Product Name Work Product Typical Characteristics CIF8 Evaluation report Improving the usability of the object of evaluation. Defining a baseline (the data used as a reference with which to compare future evaluation results) for usability for the whole product. Comparing products (e.g. to inform decisions about purchasing off-the-shelf components or systems). Comparing a product with (one or more sets of) predefined requirements (e.g. the requirements of two different user groups). Enabling decisions on redesign or replacement of an existing product. Identifying failures in the development process. Reporting usability problems, derived user requirements and recommendations for improving the usability of the object of evaluation. Reporting a baseline for usability for the whole product. Reporting differences in usability across a set of products (two or more products). Reporting conformity with user requirements (conformance test report). Product identification. Evaluation objectives. Predefined user requirements. Methods used. Participant descriptions. Findings (positive and defects). Unsatisfied user requirements. Emergent user requirements and recommendations. Data obtained from the evaluated interactive system. Data analysis (e.g. cause and effect). CIF9 Field data report data on actual usage of the product (versus intended usage of the product). Sources of field data including observation of use, user satisfaction surveys, usage statistics and help desk data. Field data and its sources including: the actual context of use, the means of collecting the data, the reasons for its collection, any identified user needs, derived user requirements. D.6 Systems work products from ISO/IEC 15504-6 Table D.4 lists the specific system lifecycle work products produced as a result of a particular human-centred design process. NOTE The generic work product types defined in Table D.2 are included in the list for completeness. Table D.4 Systems work products WP ID Work Product Name Work Product Typical Characteristics 1.00 object refer to Table D.2 for Generic Work Product typical characteristics 1.03 competent personnel staff experience, skills and knowledge competence to perform life cycle processes team working ability staff assessments training and education needs retraining, reassignment or reallocation plans recruitment criteria project personnel profile ISO/IEC 2015 All rights reserved 58

WP ID Work Product Name Work Product Typical Characteristics 1.06 qualified operators operator competence definition operator selection criteria training criteria qualifications operating instructions failure detection instructions authorization to operate training resources system training mode service availability 1.08 verified system conformance evidence configuration status deviations corrective actions 1.10 validated system service requirements operational site qualified operators service non-conformances operational status acceptance condition 1.11 operational system service requirements service availability service life service non-conformances maintenance conditions operators 1.12 waste products waste disposal conditions waste disposal equipment system destruction procedure treaded waste waste handling procedure melted, crushed, incinerated or demolished system elements knowledge safeguards operator skills safeguards 2.00 description refer to Table D.2 for Generic Work Product typical characteristics 2.01 tailored system life cycle stage purpose stage model stage outcomes enabling system services succeeding stage criteria stage exit criteria approval to proceed 2.02 tailored system life cycle process purpose process model process outcome activity identity and detail output work products input work products 2.03 system life cycle stage business strategy model business area strategy stages gates gate review achievement criteria gate review authorities system life cycle management policy and procedures system life cycle performance measures risk management policies and procedures ISO/IEC 2015 All rights reserved 59

WP ID Work Product Name Work Product Typical Characteristics 2.04 system life cycle process policy to adapt system life cycle processes model life cycle process performance/trends project requirements and needs quality management policies and procedures 2.07 stakeholders profile stakeholder classes stakeholder identity acquirer organizations supplier organizations regulatory bodies members of society stakeholder representatives 2.08 system functional model product function performance parameters data flows human-centred quality measures functional views and viewpoints modelling notation 2.09 architectural design system elements description structure views and viewpoints non-functional views and viewpoints design rationale interface requirements implementation technology planned evolution technology upgrades 3.00 plan refer to Table D.2 for Generic Work Product typical characteristics 3.01 acquisition strategy acquisition plan life cycle model make/buy/reuse policy supply chain relationships market influences technology investment strategy 3.02 supply strategy enterprise objectives business area objectives asset base resource availability service offerings product families 3.03 business strategy new business opportunities business areas opportunity viability risks to organization projects prioritisation current product/service portfolio current assets resource availability investment strategy 3.04 system life cycle business achievement criteria management policy life cycle reference models stage gate/milestones approval criteria system life cycle processes improvement policy 3.06 system life cycle process system life cycle process definitions policy life cycle reference models process application policy tailoring/adaptation policy ISO/IEC 2015 All rights reserved 60

WP ID Work Product Name Work Product Typical Characteristics 3.07 training strategy competence profiles knowledge skills experience aptitude recruitment re-assignment 3.08 quality management policy business strategy organization quality goals and objectives quality management standards 3.09 project management plan work breakdown structure task relationships/external dependencies achievement milestones organizational infrastructure procured items and services project review times/events reserves for risk management 3.10 project acquisition plan staff recruitment acquired materials and goods acquired services solicitation plans supplier selection contract monitoring schedule 3.11 technical management plan technical achievement criteria technical roles and responsibilities technical resources selected methods and tools supporting technical services technology readiness technical risks technical review schedule 3.12 service management plan agreement service levels service conditions operational location service non-conformances maintenance operator training 3.13 project quality plan project quality objectives enterprise quality goals and objectives enterprise quality management policies and procedures quality standards infrastructure assets and capability enabling systems infrastructure capacity service availability allocation to tasks project performance criteria stakeholder satisfaction criteria project status reporting schedule enterprise reporting schedule 3.14 decision-making strategy decision categories prioritisation scheme effectiveness assessment project initiation or progression approvals decision-making parties ISO/IEC 2015 All rights reserved 61

WP ID Work Product Name Work Product Typical Characteristics 3.15 risk management strategy risk avoidance actions and rationale risk mitigation actions and rationale risk transfer actions and rationale risk retention actions rationale 3.19 integration strategy assembly sequence and configurations verification information fault isolation and diagnosis constraints operator integration 3.20 verification strategy product requirements verification methods and techniques configuration sequences disassembly strategies fault diagnosis steps inspections and comparisons static and dynamic tests demonstrations and acceptance criteria regression criteria verification enabling systems requirements non-conformance handling reviews and audits 3.21 transition strategy installation constraints operating environment dependencies commissioning instructions operator incorporation acceptance conditions 3.22 validation strategy stakeholder requirements/acquirer agreements safety, technical and commercial criticality constraints validation enabling system requirements non-conformance handling validation limitations and deferred actions service conformance recording validation steps, operational states, scenarios and missions conformance confidence, diagnosis, discrepancies validation methods and techniques purpose, conditions and conformance criteria 3.23 operation strategy service availability schedule introduction to service conditions operator capacity and renewal system modification schedules release and re-acceptance criteria service withdrawal circumstances service migration and concurrent services customer satisfaction criteria 3.24 maintenance strategy operational availability requirements corrective and preventative maintenance policy maintenance capabilities and locations maintenance enabling system requirements maintenance staff competence maintenance schedules service restrictions and suspensions replacement system element logistics health, safety, security and environment legislation ISO/IEC 2015 All rights reserved 62

WP ID Work Product Name Work Product Typical Characteristics 3.25 disposal strategy waste product handling system element recycling options disposal enabling system requirements disposal constraints, regulations and directives disposed material handling audits and inspections health, safety, security and environment legislation 4.00 procedure refer to Table D.2 for Generic Work Product typical characteristics 4.01 supplier selection procedure business policy supply chain circumstances technical and commercial issues selection rating criteria negotiation schedules decision and rationale feedback 4.02 system life cycles enterprise strategic plans management procedure business area plans risk management policy quality management policies stage entry and exit criteria project tailoring policy key milestones definition reporting events 4.03 quality management system quality policy access mechanism information medium standards customer satisfaction project quality plans quality assessments quality improvements 4.04 implementation procedure selected implementation technology implementation enabling systems fabrication safety, security and environmental standards and legislation physical fabrication and conditioning techniques software generation and coding methods operator task training system element verification actions conformance and quality reporting 4.06 verification procedure verification methods verification enabling system assembly sequence fault diagnosis sequence non-conformance handling 4.07 transition procedure installation location preparation transition enabling system operator induction activation conditions transition non-conformances operational readiness criteria acceptance requirements 4.08 validation procedure agreement acceptance conditions service requirements operational states, scenarios and missions validation enabling system ISO/IEC 2015 All rights reserved 63

WP ID Work Product Name Work Product Typical Characteristics 4.10 maintenance procedure servicing skills preventative maintenance schedules system element failure rates spares holdings maintenance enabling systems random faults detection systematic fault detection replacement schedules level of system element replacement useful life of degradable system elements corrective design/implementation actions 4.15 disposal procedure service withdrawal/transfer sequences power/fuel termination systems interfaces disassembly sequences intermediate/long term storage/archive conditions operating knowledge recording health, safety, security and environmental legislation 5.00 record refer to D.2 for Generic Work Product typical characteristics 5.01 supplier justification record supply chain technical and commercial issues competitive solicitations selection criteria offerings rating 5.04 risk register risk categories and responsibilities risk sources and relationships initiating events and occurrence probability risk consequences threshold of acceptability risk ranking 5.09 stakeholder requirements traceability 5.10 stakeholder requirements record agreement stakeholder class service requirement validation acceptance conditions stakeholder requirements baselines changes of need and origin persistent needs agreements 5.11 systems requirements stakeholder requirement traceability system functional model architectural design agreement 5.17 verification record compliance deviations verification data authentications corrective actions 5.18 transition record installation baseline installation test operator training/certification acceptance authorisation user training corrective actions ISO/IEC 2015 All rights reserved 64

WP ID Work Product Name Work Product Typical Characteristics 5.19 validation record stakeholder requirements legal and regulatory requirements operator qualification service levels non-conformances and deviations corrective actions 5.20 operation record operational configuration modification information operation non-conformances service levels service period 5.21 maintenance record operational information maintenance information product/service non-conformance trends and failure patterns detected design errors services risks and failures 6.00 report refer to D.2 Generic Work Product typical characteristics 6.01 supplier assessment report supplier proposals proposal rating justification supplier preference selected supplier 6.02 delivery acceptance report delivered product/service product/service requirements agreement compliance confirmation method compliance tools 6.03 supply performance report cost performance schedule risks execution of agreement assessment undesirable outcome evaluation corrective action recommendations 6.04 system life cycle model life cycle models review stages life cycle processes achievement criteria life cycle model improvements 6.06 investment decision report business strategy new business opportunities cost and delivery projections viability assessment risks to organization projects prioritisation current product/service portfolio current assets 6.07 system life cycle process enterprise goals and policies review quality audits method and tool support project review tailoring policy 6.08 system life cycle system life cycle performance measures improvement report process execution performance/trends process improvement opportunities processes improvement actions ISO/IEC 2015 All rights reserved 65

WP ID Work Product Name Work Product Typical Characteristics 6.10 customer satisfaction report customer satisfaction definition information sources and schedule customer satisfaction status 6.11 quality management report quality objectives non-conformance information project performance trends product/service quality improvements 6.13 project resources and project structure and responsibilities services report team competencies adequacy and availability supporting infrastructure readiness of enabling systems technology readiness technology insertion plans 6.14 project quality report performance measures business audit results technical results project self-assessment results quality deviations or variations corrective actions 6.15 project progress report project status risk profile stage progression criteria milestone achievements projected performance against plans business and technical risks replanting needs resource authorisation project readiness to proceed 6.16 corrective action report non-compliance agreement stakeholder requirements systems requirements service requirements diagnosed faults design change 6.18 risk management report identified risk risk treatment actions impact on plans risk status project risk reserves 6.21 stakeholder requirements integrity analysis report conflicting requirements missing requirements incomplete requirements ambiguous requirements unverifiable requirements requirements integrity resolution strategy 6.22 system requirement report requirements uniqueness requirements completeness requirements non-ambiguity requirements consistency requirements implementability requirements verifiability requirements integrity resolution strategy traceability derived requirements ISO/IEC 2015 All rights reserved 66

WP ID Work Product Name Work Product Typical Characteristics 6.26 verification report verification data verification non-conformances corrective action information diagnosed faults trends and patterns of failure evidence of design or implementation errors 6.27 transition report capability readiness installed system operational location and environment operator readiness acceptance criteria support enabling system readiness corrective action reports 6.28 validation report validation data user communication stakeholder satisfaction service restoration service amendment actions 6.29 operation report delivered services service levels service satisfaction performance parameters acceptable/revised service parameters operational situation service non-compliances operating personnel performance operations plans system activation actions operator training and accreditation usability review occupational safety environmental protection 6.30 maintenance report logistics analysis replenishment levels replacement schedules repair rates spares availability, spares integrity failure data events and histories lifetime data preventive and corrective maintenance adaptive and perfective maintenance operator replenishment maintenance personnel performance 6.31 disposal report disposal confirmation health factors safety factors security factors environmental factors 7.00 request refer to Table D.2 Generic Work Product typical characteristics 7.02 acquisition agreement needs change request stakeholder requirements agreement terms and conditions delivery schedule acceptance criteria ISO/IEC 2015 All rights reserved 67

WP ID Work Product Name Work Product Typical Characteristics 7.03 supply proposal supply request response supplier s project plans proposed cost, schedule and system performance anticipated risks supply terms and conditions 7.06 supplier directive acceptance criteria product/service defects instructions to rectify modified terms and conditions 7.10 operation request change of need context of use service level service non-compliance maintenance schedule modifications and upgrades operator assignment consumable materials 8.00 specification refer to Table D.2 for Generic Work Product typical characteristics 8.02 delivery acceptance criteria agreement criteria product/service compliance criteria delivery procedures and conditions verification procedure validation procedure 8.03 supply agreement acquirer product or service offered supplier terms and conditions acceptance information/demonstration deviation handling delivery procedures intellectual property rights responsibility transfer definition completion conditions liabilities 8.04 project requirements enterprise objectives requirements/review milestones acquirer/supplier agreement project objectives projects accountabilities and authorities project achievement criteria project life cycle stage responsibility project completion criteria project constraints scope of technical activities life cycle process tailoring project assessment and control plans 8.08 quality management goals business strategy and objectives quality policy customer satisfaction 8.09 quality measures customer satisfaction non-compliances project reviews 8.10 project team requirements project organization project roles and responsibilities definition of role competence staff appointments designation of legally responsible roles and individuals methods of team working ISO/IEC 2015 All rights reserved 68

WP ID Work Product Name Work Product Typical Characteristics 8.12 stakeholder requirements system purpose stakeholder concerns operational scenarios context of use user culture and social profile measures of effectiveness service validation conditions service requirements to stakeholder needs traceability 8.13 stakeholder requirements stakeholders assumptions and rationale constraints on solution stakeholder perceived constraints previous implementation decisions operator staff capabilities and competence agreements acquiring organization constraints health and safety security standards reliability and availability supportability environmental protection 8.14 system requirements functional boundary definition critical performance parameters behaviour and properties required system stimuli and responses interface constraints user and environment behaviour human-centred quality measures implementation constraints 8.15 system requirements performance requirements constraints on solution product sector standards interface requirements verification enabling system agreement 8.16 system technical measures performance parameters specification critical performance measures human-centred quality non-compliance criteria verification enabling system 8.17 system interface system boundary definition requirements external systems external interface specifications human-system interfaces product sector interface standards 8.18 human-equipment interface operator competence and capabilities requirements usability requirements and standards operator and user recruitment operator training needs operator certification requirements 8.20 implementation constraints implementation technology on solution selected implementation technology implementation technology constraints and limitations acquirer furnished materials existing system elements for adaptation implementation enabling systems limitations ISO/IEC 2015 All rights reserved 69

WP ID Work Product Name Work Product Typical Characteristics 8.25 verification enabling system requirement 8.26 transition constraints on solution 8.27 transition enabling system requirements 8.28 validation constraints of solution 8.29 validation enabling system requirements 8.30 maintenance constraints on solution 8.31 maintenance enabling system requirements 8.32 disposal constraints on solution 8.33 disposal enabling systems requirement verification facilities system requirements integration strategy non-conformance diagnosis acceptance criteria interfaces availability operational site conditions operating environment dependencies commissioning instructions acceptance conditions operator induction activation conditions acceptance requirements operational location installation skills fault identification operational location access operator availability renewable materials acceptance criteria validation enabling system verification facilities system requirements installation strategy non-conformance diagnosis acceptance criteria operators competence interfaces maintenance enabling systems re-use strategy logistics strategy system element holdings re-supply limitations maintenance scenarios maintenance locations maintenance environments maintenance staff competence maintenance enabling systems service level agreement operational situation activation procedure required instances/continuous service service conformance audits transfer/changeover of services disassembly location and access disposal enabling systems availability of storage locations disposal skill levels disposal support services disposal location environmental legislation ISO/IEC 2015 All rights reserved 70

Annex E (informative) Target audiences of the document and uses E.1 Audiences Table E.1 lists for each process category the target audiences, the types of organizational risks addressed and the types of decisions made. NOTE For more information on specific risks and benefits, see F.1. Table E.1 Audiences, risks and decisions made for each process category Process category Target audience [type of] Organizational risks addressed [type of] Decisions made Ensure enterprise focus on humancentred quality Executive management Executive responsible for human-centred quality Usability Management in terms of facilitating usability across the organization Image/society Business survival Human-system issues in governance Human-system issues in services Approach to policy Investment Strategy/ic Development Enable humancentred design across projects and systems The group that makes things happen (or not) Program managers Project Managers Product Manager Usability Managers Resource Functional Human-system issues in programme Human-system issues across systems Governance Programme Lifecycle Standards Process improvement Process owners Technical specialists with cross-project / organizational responsibilities Execute humancentred design within a project Project Managers Product Manager Technical leadership responsible for usability and ergonomics Human-system issues in project Quality of system Technical Human-system issues in the system Project Technique and design Process implementation ISO/IEC 2015 All rights reserved 71

Process category Target audience [type of] Organizational risks addressed [type of] Decisions made Introduction, operation and retirement of a system Service Managers Support Managers Senior Usability Professionals Operational Human-system issues in services Quality of service Support Contextual Investment Note: Educators and trainers of human-centred design are also a primary audience. E.2 Different uses E.2.1 Implementing human-centred design The human-centred process model describes a complete set of the processes and sub-processes that are required to make systems human-centred. This makes it a useful resource for enterprises (organisations, departments or projects) designing a system development process and/or support lifecycle which needs to be human-centred. The recommended approach is for the enterprise to set up a process to define their needs for such a lifecycle. The outcomes of the processes in this model (and other models) are compared with the needs for this lifecycle. The processes in ISO 9241-220 can be used as input at this stage. The next step is to define a lifecycle which implements and integrates the base and management practices to the required level to achieve the business purposes of the organisation, department or project. The lists of work products in Annex D assist in this definition. More detailed information on most of the practices is provided in ISO 9241-210 human-centred design for interactive systems. Advice on the particular methods that implement the practices is available from textbooks and human factors service providers. E.2.2 Assessing an enterprise s existing capability to carry out the human-centred processes The model presented in this document can be used in the assessment of an enterprise s capability to carry out the human-centred processes described in the model. This enterprise can be an internal sub-organisation (e.g. an IT department) or a system supplier. The intended assessment process is that defined in ISO 15504 [this reference will be changed to the forthcoming 33000 series if that is approved in time]. The reader is referred to ISO 15504 Software process assessment for details of the qualification of assessors, quality processes associated with assessments etc. The first step is the tailoring of the model for the assessment. This consists of selection of relevant processes and definition of the maximum capability that is likely to be observed. The processes selected are representative of the activities carried out by the enterprise. The model is not sacrosanct and can be tailored as much as necessary. The purpose of assessment is usually to gain a clear picture of the processes in a particular enterprise for the purpose of process improvement. The benefit to the enterprise is only realised if the model is tailored to suit the purposes of the assessee. Processes and practices are selected for assessment if the enterprise wishes to know how well that particular activity is carried out. If it is not important to the business that a particular process is performed well then there is no need to assess it. In a third party assessment for the purposes of accreditation the situation is different. A purchaser or other client is looking for evidence that the processes that it considers necessary are performed to the level it requires. In this case the processes to be covered are defined by the client. ISO/IEC 2015 All rights reserved 72

The next step is to select typical projects for assessment. For a thorough assessment the range of projects are selected to be representative of the spread of work, size of project and diligence of the enterprise. The assessment itself can be achieved by various approaches, including interviewing selected staff. Firstly, to ascertain how many of the practices are performed for each process. Secondly, to ascertain how well these processes are implemented in terms of the performance of the management practices. The work products described in this part of ISO 9241 can be used as evidence of the performance of the practices. The enterprise being assessed needs to understand and prepare for the assessment. In an ideal case the relevant staff will have studied the model and prepared a description of how the enterprise s processes and practices map onto the human-centred lifecycle processes. E.2.3 Improving the application of human-centred design as part of an existing system development process The human-centred processes, the practices and the work products provide a description of how enterprises carry out activities that take account of user issues. ISO 15504 Software process assessment Part 2 A reference model for processes and process capability presents a number of levels of maturity with regard to these processes. These descriptions can be used in setting the agenda and goals for improvement of a human-centred approach in systems development. The management practices provide a description of what is required in order to take the next step in increasing the maturity of the enterprise with respect to a humancentred approach. Assessments will be required to diagnose existing process capability and to monitor performance. However, the goal of process performance is business benefit, not a score or certificate. The best approach to assessment for the purpose of process improvement is for the enterprise to define a desired profile of performance in human-centred processes based on their business need. The scope of initial and monitoring assessments is then designed to match that profile. The assessment approach described below is rigorous and is intended to give reproducible results across a variety of enterprises. In some cases this degree of rigour and the associated formality are not appropriate. The model can also be used in a more informal setting, such as a workshop or discussion group. A description of the development process and the discussion about whether or not the management practices are performed is retained, but the scoring need not be introduced or, if it is, the assessment as to whether attributes are performed or not would become a group decision. The result need not be recorded, but a general agreement is reached about the achieved level, the required level for the business or project, and the actions required to attain it. A discussion group approach is intended to increase awareness amongst participants. Their discussion with each other in the assessment meeting could well be more valuable than recommendations given by improvement experts. Even where assessment is carried out by external assessors an element of group discussion can be built in so as to promote awareness and organisational learning. In informal assessment a group can assess itself and retain the results for comparison with their next discussion or project; improvement actions can still be planned and responsibility for making changes should be allocated. The human-centred processes presented in this model can be used to augment the set of processes in other process models. This augmentation is likely to be carried out when a capability assessment is being performed on an organisation or department that develops or supports systems that gain business benefit from meeting the needs of their users. The human-centred processes for a particular assessment are selected and adapted using the tailoring process described in Annex B. The processes are described in a standard format in order to make this process as easy as possible. It is advisable to take advice from a human factors expert when selecting processes to include in the assessment. ISO/IEC 2015 All rights reserved 73

E.2.4 Development of competence in human-centred design Competence can be seen in terms of two dimensions or axes. One axis is the set of processes considered relevant to the discipline of interest, in this case the processes in this part of ISO 9241. The other axis defines the levels of proficiency in performing these processes; typically using a progression of increasing-value cardinal points that are defined in terms of attainment or performance criteria. The model in this part of ISO 9241 can be used to identify appropriate content for education and training courses in human-centred design and usability. E.3 Organisational context for implementing human-centred design This part of ISO 9241 can be applied to implement human-centred design in a wide range of organisational contexts described below. a) Degree of formality Governance-centred organisations with governance and management systems (usually based on standards such as ISO/IEC 38500, ISO 9001, ISO/IEC 20000) are a widespread tool for control of organisations and enterprises. This part of 9241, particularly in HCP1 and HCP2, embodies this approach to management. Such organisations will recognise this approach and the uptake of humancentred design will be facilitated. Less formal organisations; that take a more ad-hoc or trust-based approach to management this material can be used as informal guidance on the management of enterprise risk. b) Manufacturers and acquirers Manufacturers of systems: need to be human-centred in designing both bespoke systems for individual clients and systems to be sold off-the-shelf, whether as complete systems or as components of larger systems. Acquirers of systems: retain most of the responsible for ensuring that a system meets user needs. A process perspective makes this clearer and assists communications between parties. It is particularly important when off-the-shelf systems and components to be integrated into systems are being acquired. c) Large and small organisations. In large organisations activities and responsibilities are fragmented between groups/departments. In small organisations a small number of people carry out all activities. In both cases this part of ISO 9241 provides clarity regarding what needs to be done and why, independent of structure or individual skills. d) Introduction and improvement of human-centred design Introducing human-centred design when there are no existing HCD processes. Improving existing HCD processes. e) Top down and bottom-up application of human-centred design: Top down application of human-centred design: follows the order of description of processes. Bottom up application of human-centred design: starts from the technical processes and as the need for formality and support develops the management and governance processes become useful. f) System and service providers ISO/IEC 2015 All rights reserved 74

System providers: are responsible for designing, integrating and implementing all parts of a usable system within an organisation. This is carried out as a project and is common in the transport, manufacturing, energy and defence sectors and to some degree public sector systems. This part of ISO 9241 provides a template for project activities and the deliverables necessary for communication about user needs and usability. Services: need to be usable and this can be achieved through a human-centred approach. In corporate IT, information services, entertainment, and social media functionality is assembled from generic components. In this context what is managed is a service and usability is a more dynamic attribute. In the service context this part of ISO 9241 provides a set of objectives for monitoring and maintenance of user needs and usability. NOTE See ISO DIS 27500 for more information on opportunities, and managing and mitigating organisational risks, related to human-centred design. ISO/IEC 2015 All rights reserved 75

Annex F (informative) Human-centred quality F.1 General The objectives of human-centred design stated in ISO 9241-210 include: "increasing accessibility", "improving user experience", "reducing risk of harm" and "reducing the risk of the product failing to meet stakeholder requirements". The term "human-centred quality has been adopted as an overall term for these objectives. Human-centred quality is thus composed of effectiveness, efficiency and satisfaction for specified user groups ("usability") with particular emphasis on usability for people with the widest range of capabilities ("accessibility"), and on satisfaction from an individual perspective ("user experience"), and the reduction of risk associated with inadequate usability, accessibility or user experience. More specifically: Usability means that delivered solutions can be used by the intended users to achieve specified goals with effectiveness, efficiency and satisfaction. Accessibility is the usability of a product, service, environment or facility by people with the widest range of capabilities. User experience is a person's perceptions and responses that result from the use and/or anticipated use of a product, system or service. Reduced risk is the extent to which the quality of a product or system mitigates or avoids risk to the users, organisation or project, including threats to economic status, human life, health, or the environment. 7.3.1.1 includes examples of specific goals for human-centred quality. NOTE 1 Quality in use (defined in ISO/IEC 25010) that is composed of effectiveness, efficiency, satisfaction and freedom from risk is a similar concept intended to characterize the impact that the quality of the product or system has on the user. Figure F.1 The components of human-centred quality ISO/IEC 2015 All rights reserved 76