ISO 13407:1999
(Main)Human-centred design processes for interactive systems
Human-centred design processes for interactive systems
Processus de conception centrée sur l'opérateur humain pour les systèmes interactifs
General Information
- Status
- Withdrawn
- Publication Date
- 09-Jun-1999
- Withdrawal Date
- 09-Jun-1999
- Technical Committee
- ISO/TC 159/SC 4 - Ergonomics of human-system interaction
- Drafting Committee
- ISO/TC 159/SC 4 - Ergonomics of human-system interaction
- Current Stage
- 9599 - Withdrawal of International Standard
- Start Date
- 03-Mar-2010
- Completion Date
- 12-Feb-2026
Relations
- Consolidates
EN ISO 13407:1999 - Human-centred design processes for interactive systems (ISO 13407:1999) - Effective Date
- 12-Feb-2026
- Effective Date
- 07-Nov-2009
ISO 13407:1999 - Human-centred design processes for interactive systems
ISO 13407:1999 - Processus de conception centrée sur l'opérateur humain pour les systemes interactifs
Get Certified
Connect with accredited certification bodies for this standard
NSF International
Global independent organization facilitating standards development and certification.
CIS Institut d.o.o.
Personal Protective Equipment (PPE) certification body. Notified Body NB-2890 for EU Regulation 2016/425 PPE.
Kiwa BDA Testing
Building and construction product certification.
Sponsored listings
Frequently Asked Questions
ISO 13407:1999 is a standard published by the International Organization for Standardization (ISO). Its full title is "Human-centred design processes for interactive systems". This standard covers: Human-centred design processes for interactive systems
Human-centred design processes for interactive systems
ISO 13407:1999 is classified under the following ICS (International Classification for Standards) categories: 13.180 - Ergonomics. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 13407:1999 has the following relationships with other standards: It is inter standard links to EN ISO 13407:1999, ISO 9241-210:2010. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
ISO 13407:1999 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 13407
First edition
1999-06-01
Human-centred design processes for
interactive systems
Processus de conception centrée sur l'opérateur humain pour les systèmes
interactifs
A
Reference number
Contents Page
1 Scope .1
2 Terms and definitions .1
3 Structure of this International Standard.2
4 Rationale for adopting a human-centred design process .2
5 Principles of human-centred design.3
5.1 General.3
5.2 The active involvement of users and a clear understanding of user and task requirements.3
5.3 An appropriate allocation of function between users and technology.3
5.4 Iteration of design solutions.3
5.5 Multi-disciplinary design.4
6 Planning the human-centred design process.4
7 Human-centred design activities .5
7.1 General.5
7.2 Understand and specify the context of use .6
7.3 Specify the user and organizational requirements .7
7.4 Produce design solutions.8
7.5 Evaluate designs against requirements .9
8 Conformance.12
Annex A (informative) Guidance on other relevant standards .13
Annex B (informative) Example of a structure of a usability evaluation report .17
Annex C (informative) Sample procedure for demonstrating conformance to this International Standard.20
Bibliography.25
© ISO 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 • CH-1211 Genève 20 • Switzerland
Internet iso@iso.ch
Printed in Switzerland
ii
© ISO
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 3.
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.
International Standard ISO 13407 was prepared by Technical Committee ISO/TC 159, Ergonomics, Subcommittee
SC 4, Ergonomics of human-system interaction.
Annexes A, B and C of this International Standard are for information only.
iii
© ISO
Introduction
Human-centred design is an approach to interactive system development that focuses specifically on making
systems usable. It is a multi-disciplinary activity which incorporates human factors and ergonomics knowledge and
techniques. The application of human factors and ergonomics to interactive systems design enhances effectiveness
and efficiency, improves human working conditions, and counteracts possible adverse effects of use on human
health, safety and performance. Applying ergonomics to the design of systems involves taking account of human
capabilities, skills, limitations and needs.
Human-centred systems support users and motivate them to learn. The benefits can include increased productivity,
enhanced quality of work, reductions in support and training costs, and improved user satisfaction. Although there is
a substantial body of human factors and ergonomics knowledge about how such design processes can be
organized and used effectively, much of this information is only well-known by specialists in these fields. This
International Standard aims to help those responsible for managing hardware and software design processes to
identify and plan effective and timely human-centred design activities. It complements existing design approaches
and methods.
.
iv
INTERNATIONAL STANDARD © ISO ISO 13407:1999(E)
Human-centred design processes for interactive systems
1 Scope
This International Standard provides guidance on human-centred design activities throughout the life cycle of
computer-based interactive systems. It is aimed at those managing design processes and provides guidance on
sources of information and standards relevant to the human-centred approach.
This International Standard is concerned with both hardware and software components of interactive systems.
NOTE Computer-based interactive systems vary in scale and complexity. Examples include off-the-shelf (shrink wrap)
software products, custom office systems, plant monitoring systems, automated banking systems and consumer products.
This International Standard addresses the planning and management of human-centred design. It does not address
all aspects of project management.
This International Standard provides an overview of human-centred design activities. It does not provide detailed
coverage of the methods and techniques required for human-centred design, nor does it address health and safety
aspects in detail.
The main users of this International Standard will be project managers. This International Standard therefore
addresses technical human factors and ergonomics issues only to the extent necessary to allow managers to
understand their relevance and importance in the design process as a whole. Such issues are dealt with more fully
in ISO 9241 (see bibliography) which is complementary to this International Standard and is aimed at system
developers, specifiers and purchasers of systems. Nonetheless, all parties involved in human-centred system
development, including the end-users of systems, should find the guidance in this International Standard relevant.
2 Terms and definitions
For the purposes of this International Standard, the following terms and definitions apply.
2.1
interactive system
combination of hardware and software components that receive input from, and communicate output to, a human
user in order to support his or her performance of a task
NOTE The term “system” is often used rather than “interactive system”.
2.2
prototype
representation of all or part of a product or system that, although limited in some way, can be used for evaluation
2.3
usability
extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency
and satisfaction in a specified context of use
[ISO 9241-11:1998, definition 3.1]
© ISO
2.4
effectiveness
accuracy and completeness with which users achieve specified goals
[ISO 9241-11:1998, definition 3.2]
2.5
efficiency
resources expended in relation to the accuracy and completeness with which users achieve goals
[ISO 9241-11:1998, definition 3.3]
2.6
satisfaction
freedom from discomfort, and positive attitudes to the use of the product
[ISO 9241-11:1998, definition 3.4]
2.7
context of use
users, tasks, equipment (hardware, software and materials), and the physical and social environments in which a
product is used
[ISO 9241-11:1998, definition 3.5]
2.8
user
individual interacting with the system
[ISO 9241-10:1996, definition 2.2]
3 Structure of this International Standard
Clause 4 outlines the reasons for adopting a human-centred design process. These can be used to provide a
rationale for the use of human-centred methods, or to determine priorities for resource allocation during a project.
Clause 5 gives guidance on the principles of human-centred design. Clause 6 lists the issues to be considered
when planning human-centred design activities and discusses how these should relate to system design goals.
Clause 7 is the core of this International Standard. It describes each of the four essential human-centred activities
which should take place during the design process. Clause 8 gives further guidance on reporting human-centred
activities.
4 Rationale for adopting a human-centred design process
All work systems should follow the ergonomic principles described in ISO 6385:1981. Making interactive systems
more human-centred has substantial economic and social benefits. In most countries, employers and system
providers have legal obligations to protect users from risks to their health and safety. Making systems more usable
means systems can contribute to these aims, meeting user and organizational needs better. They
a) are easier to understand and use, thus reducing training and support costs,
b) improve user satisfaction and reduce discomfort and stress,
c) improve the productivity of users and the operational efficiency of organizations, and
d) improve product quality, appeal to the users and can provide a competitive advantage.
The complete benefits of human-centred design can be determined by taking into account the total life-cycle costs
of the system including conception, design, implementation, support, use and maintenance.
© ISO
5 Principles of human-centred design
5.1 General
There are many industry and proprietary standard methods for the design of computer-based interactive systems.
This International Standard does not assume any one standard design process, nor does it cover all the different
activities necessary to ensure effective system design. It is complementary to existing design methods and provides
a human-centred perspective that can be integrated into different forms of design process in a way that is
appropriate to the particular context. All the human-centred design activities identified in clause 7 are applicable, to
a greater or lesser extent, at any stage in the development of a system.
Whatever the design process and allocation of responsibilities and roles adopted, the incorporation of a human-
centred approach is characterized by the following:
a) the active involvement of users and a clear understanding of user and task requirements;
b) an appropriate allocation of function between users and technology;
c) the iteration of design solutions;
d) multi-disciplinary design.
5.2 The active involvement of users and a clear understanding of user and task requirements
The involvement of users in the development process provides a valuable source of knowledge about the context of
use, the tasks, and how users are likely to work with the future product or system. The effectiveness of user
involvement increases as the interaction between the developers and the users increases. The nature of user
involvement varies depending on the design activities which are being undertaken.
When custom-made products are being developed, the proposed users and the tasks performed can be directly
linked to the development process. The organization procuring the system has the opportunity to have a direct
influence on the design as it emerges, and solutions can be evaluated by those who are actually going to be
working with them. Such involvement and participation also increase user acceptance and commitment.
When generic or consumer products are being developed, the user population is dispersed and is perhaps not
easily accessible. It is still essential that users or appropriate representatives are involved in development, in order
that the relevant user and task requirements can be identified for inclusion in the system specification, and in order
to provide feedback through testing of the proposed design solutions.
5.3 An appropriate allocation of function between users and technology
One of the most important human-centred design principles concerns the appropriate allocation of function – the
specification of which functions should be carried out by the users and which by the technology. These design
decisions determine the extent to which a given job, task, function or responsibility is to be automated or assigned
to human performance.
The decisions should be based on many factors, such as relative capabilities and limitations of humans versus
technology in terms of reliability, speed, accuracy, strength, flexibility of response, financial cost, the importance of
successful or timely accomplishment of tasks and user well-being. They should not simply be based on determining
which functions the technology is capable of performing and then simply allocating the remaining functions to users,
relying on their flexibility to make the system work. The resulting human functions should form a meaningful set of
tasks. Representative users should generally be involved in these decisions. For further guidance, see ISO 9241-2
and ISO 10075.
5.4 Iteration of design solutions
In iterative design approaches, feedback from users becomes a critical source of information. Iteration, when
combined with active user involvement, provides an effective means of minimizing the risk that a system does not
meet user and organizational requirements (including those requirements that are hidden or difficult to specify
© ISO
explicitly). Iteration allows preliminary design solutions to be tested against “real world” scenarios, with the results
being fed back into progressively refined solutions.
Iteration can be incorporated in other design approaches. Even in the “waterfall” model, where there is a systematic
top-down hierarchy of design decisions and the relationship between the stages generally precludes iteration
between them, there can be extensive iteration within a stage.
5.5 Multi-disciplinary design
Human-centred design needs a variety of skills. A range of personnel is necessary to address the human aspects of
the design. This means that multi-disciplinary teams should be involved in a user-centred design process. These
can be small, dynamic and need only last the life of the project. The composition of the teams should reflect the
relationship between the organization responsible for technical development and the customer. The roles can
include the following
a) end-user;
b) purchaser, manager of user;
c) application domain specialist, business analyst;
d) systems analyst, systems engineer, programmer;
e) marketer, salesperson;
f) user interface designer, visual designer;
g) human factors and ergonomics expert, human-computer interaction specialist;
h) technical author, trainer and support personnel.
Individual team members can cover a number of different skill areas and viewpoints. Multi-disciplinary teams do not
have to be large but the team should be sufficiently diverse to make appropriate design trade-off decisions.
6 Planning the human-centred design process
A plan should be developed to specify how the human-centred activities fit into the overall system development
process.
The plan should identify:
a) the human-centred design process activities described in clause 7, i.e. understanding and identifying context of
use, specifying user and organizational requirements, producing prototypes and evaluating designs according
to user criteria;
b) procedures for integrating these activities with other system development activities, e.g. analysis, design,
testing;
c) the individuals and the organization(s) responsible for the human-centred design activities and the range of
skills and viewpoints they provide;
d) effective procedures for establishing feedback and communication on human-centred design activities as they
affect other design activities, and methods for documenting these activities;
e) appropriate milestones for human-centred activities integrated into the overall design and development
process;
f) suitable timescales to allow feedback, and possible design changes, to be incorporated into the project
schedule.
© ISO
This human-centred design process plan should form part of the overall system development project plan and
should also be subject to the same project disciplines (e.g. responsibilities, change control) as other key activities to
ensure that it is followed through and implemented effectively. The plan should be revised as requirements change
and updated to reflect the status of activities.
Project planning should allow for iteration and for incorporating user feedback. Some time is also required for
effective communication among design team participants and for reconciling potential conflicts and trade-offs.
Projects benefit from additional creativity and ideas from the interaction of team members who, collectively have an
extensive skill base. Extra communication and discussion to identify and resolve problems early on in the project
can result in significant savings at later stages when changes are generally more costly.
Design organizations should incorporate human-centred design into their existing internal procedures and
development standards. This can include organization procedures for prototyping, for testing, for establishing
appropriate user involvement, for ensuring the right mix of skills and competence in the development team.
If the developing organization has a quality system and associated quality plans for system development, then a
specific plan should be included for the human-centred design process covering both the type of development
process adopted and the quality control measures.
7 Human-centred design activities
7.1 General
There are four human-centred design activities that should take place during a system development project.
These activities are
a) to understand and specify the context of use,
b) to specify the user and organizational requirements,
c) to produce design solutions,
d) to evaluate designs against requirements.
The human-centred design process should start at the earliest stage of the project (e.g. when the initial concept for
the product or system is being formulated), and should be repeated iteratively until the system meets the
requirements, as illustrated in Figure 1.
The need for a human-centred design approach will be identified from the operational objectives of the system, for
example, to satisfy customer requirements for usability.
When planning a system development project, the description of each activity and its sub-tasks should be studied
and used as guidance in designing or selecting the human-centred design methods and techniques for carrying out
the activity and reporting progress and findings. Whereas all of the human design activities described in this clause
are generally relevant, the relative focus and overall investment in them will depend on the size and type of the
product; for example, a large project, new product or new system could have a full multi-disciplinary team with a
member for each relevant role and implement all the human-centred design activities recommended in this clause.
In contrast, small projects, existing legacy products or systems or products targeted at niche or small markets could
have a smaller design team with individual members representing multiple roles and use a more limited range of
methods and techniques to support the activities.
© ISO
Figure 1 — The interdependence of human-centred design activities
7.2 Understand and specify the context of use
7.2.1 The characteristics of the users, tasks and the organizational and physical environment define the context in
which the system is used. It is important to understand and identify the details of this context in order to guide early
design decisions, and to provide a basis for evaluation.
Information should be gathered about the context of use of new products and systems. If an existing system is to be
upgraded or enhanced, this information may already be available but should be checked. If there are extensive
results from user feedback, help desk reports and other data, these provide a basis for prioritizing user
requirements for system modifications and changes.
The context in which the system is to be used should be identified in terms of the following.
a) The characteristics of the intended users: relevant characteristics of the users can include knowledge, skill,
experience, education, training, physical attributes, habits, preferences and capabilities. If necessary, define
the characteristics of different types of users, for example, with different levels of experience or performing
different roles (maintainers, installers, etc.).
b) The tasks the users are to perform: the description should include the overall goals of use of the system. The
characteristics of tasks that can influence usability should be described, e.g. the frequency and the duration of
performance. If there are implications for health and safety, e.g. controlling the behaviour of a computer-
controlled production machine, these should also be described. The description should include the allocation of
activities and operational steps between the human and technological resources. Tasks should not be
described solely in terms of the functions or features provided by a product or system.
c) The environment in which the users are to use the system: the environment includes the hardware, software
and materials to be used. Their description can be in terms of a set of products, one or more of which can be
the focus of human-centred specification or evaluation, or it can be in terms of a set of attributes or
performance characteristics of the hardware, software and other materials.
© ISO
Relevant characteristics of the physical and social environment should also be described. These can include
relevant standards, attributes of the wider technical environment (e.g., a local area network), the physical
environment (e.g., workplace, furniture), the ambient environment (e.g., temperature, humidity), the legislative
environment (e.g., laws, ordinances and directives) and the social and cultural environment (e.g., work practices,
organizational structure and attitudes).
7.2.2 The output from this activity should be a description of the relevant characteristics of the users, tasks and
environment which identifies what aspects have an important impact on the system design. (See ISO 9241-11 for
more information about the context of use and a sample report.)
NOTE This description is unlikely to be a single output that is issued once. It is more often a “working document” that is
first produced in outline terms and is then reviewed, maintained, extended and updated during the design and development
process.
The context of use description should
a) specify the range of intended users, tasks and environments in sufficient detail to support design activity;
b) be derived from suitable sources;
c) be confirmed by the users or if they are not available, by those representing their interests in the process;
d) be adequately documented;
e) be made available to the design team at appropriate times and in appropriate forms to support design activities.
7.3 Specify the user and organizational requirements
7.3.1 In most design processes, there is a major activity specifying the functional and other requirements for the
product or system. For human-centred design, this activity should be extended to create an explicit statement of
user and organizational requirements in relation to the context of use description. The following aspects should be
considered in order to identify relevant requirements:
a) required performance of the new system against operational and financial objectives;
b) relevant statutory or legislative requirements, including safety and health;
c) cooperation and communication between users and other relevant parties;
d) the users’ jobs (including the allocation of tasks, users’ well-being, and motivation);
e) task performance;
f) work design and organization;
g) management of change, including training and personnel to be involved;
h) feasibility of operation and maintenance;
i) the human-computer interface and workstation design.
7.3.2 User and organizational requirements should be derived and objectives set with appropriate trade-offs
identified between the different requirements. This specification should define the “allocation of function” — the
division of system tasks into those performed by humans and those performed by technology. These requirements
should be stated in terms that permit subsequent testing and should be confirmed or updated during the life of the
project.
NOTE Specific guidance on specifying software in a form that can be tested is contained in ISO/IEC 14598-1.
The specification of user and organizational requirements should
© ISO
a) identify the range of relevant users and other personnel in the design,
b) provide a clear statement of the human-centred design goals,
c) set appropriate priorities for the different requirements,
d) provide measurable criteria against which the emerging design can be tested,
e) be confirmed by the users or those representing their interests in the process,
f) include any statutory or legislative requirements, and
g) be adequately documented.
7.4 Produce design solutions
7.4.1 General
Potential design solutions are produced by drawing on the established state of the art, the experience and
knowledge of the participants and the results of the context of use analysis. The process therefore involves the
following activities:
a) use existing knowledge to develop design proposals with multi-disciplinary input;
b) make the design solutions more concrete using simulations, models, mock-ups, etc.;
c) present the design solutions to users and allow them to perform tasks (or simulated tasks);
d) alter the design in response to the user feedback and iterate this process until the human-centred design goals
are met;
e) manage the iteration of design solutions.
7.4.2 Use existing knowledge to develop design proposals with a multi-disciplinary input
There is a substantial body of scientific knowledge and theory from ergonomics, psychology, cognitive science,
product design and other relevant disciplines that can indicate potential design solutions. Many organizations have
internal user interface style guides, product knowledge and marketing information which can be useful in supporting
the initial design, particularly when designing similar products. Generic human factors and ergonomics design
guidance and standards are also available from national and international standards bodies. See annex A for
relevant standards and bibliography for further sources of information.
7.4.3 Make the design solution more concrete using simulations, models, mock-ups, etc.
Using simulations, models and mock-ups or other forms of prototype allows designers to communicate more
effectively with users and reduces the need and cost of reworking that can occur when products need to be revised
later in the life cycle — in some cases after initial release to real customers.
The benefits are the following:
a) to make design decisions more explicit (this enables members of the design team to communicate with each
other early in the process);
b) to allow designers to explore several design concepts before they settle on one;
c) to make it possible to incorporate user feedback into the design early in the development process;
d) to make it possible to evaluate several iterations of a design and alternative designs;
e) to improve the quality and completeness of the functional design specification.
© ISO
Prototyping can be carried out at most stages of design, from earliest design ideas based on the context of use
information (for example, using scenarios) to pre-production prototypes that are virtually complete in all details. A
prototype can be as simple as a pencil and paper sketch or as complex as a computer-based simulation, barely
distinguishable from the real thing.
7.4.4 Present the design solution to users and allow them to perform tasks (or simulated tasks)
Users can be involved very early in the design through the use of static, paper-based mock-ups. This could involve
presenting users with sketches of screen images of what a product/system is to look like and asking them to try
them out in a realistic context. Some aspects of the design (e.g., how easy it is to work with the menu hierarchies)
can then be quickly and inexpensively assessed. For hardware products, three-dimensional models constructed of
simple materials can yield similar benefits.
Simple prototypes are valuable at an early stage to explore alternative design solutions. Although there is benefit in
making the design solutions as realistic as possible, it is important not to invest so much time, money or
commitment on realistic prototypes, that there is reluctance to change the design.
In a human-centred approach, prototypes are not simply demonstrations to show users a preview of the design but
are used to collect user feedback that is then used to drive the design process.
If it is impractical to show prototypes to users early in the design process (for example, for reasons of
confidentiality), evaluation can be conducted by experts. Expert evaluation can be valuable and cost-effective and
can complement user testing. However, for a design process to be human-centred, the final testing (at least) should
take place with real users.
See 7.5 for details of design evaluation.
7.4.5 Alter the design in response to the user feedback and iterate this process until design objectives are
met
The level of prototype and the degree of iteration vary depending on several factors, including the importance
attached to optimizing the design. In software developments, prototyping can start with paper visualizations of
screen designs and progress through several stages of iteration to interactive software with just enough functionality
to support a subset of user tasks. Later in design, prototypes can be evaluated in a more realistic context. To obtain
the maximum benefits, it is best to carry out several iterations with users. In order to determine whether the overall
objectives have been met, more formal evaluation should be conducted in a realistic context, for example, without
help or interruptions from the evaluator.
User comments, and difficulties observed when using a prototype, offer guidance on functional design changes that
can improve system usability. In some cases such feedback can also help to refine the scope and purpose of an
interactive system (see 7.5.1)
7.4.6 Manage the iteration of design solutions
In order to manage the progress of iterative design, the results of activities 7.4.2 to 7.4.5 should be recorded. These
records can be wholly documentary or can include the design artefact itself, for example, some prototype hardware
or software. They include
a) the sources of existing knowledge and standards used, with an indication of how they have been incorporated
(or why they have not been followed, if appropriate),
b) the steps taken to ensure that the prototype covered key requirements and followed good practice, and
c) the nature of the problems identified and the subsequent changes to the design.
7.5 Evaluate designs against requirements
7.5.1 General
Evaluation is an essential step in human-centred design and should take place at all stages in the system life cycle.
Evaluation can be used:
© ISO
a) to provide feedback which can be used to improve design,
b) to assess whether user and organizational objectives have been achieved, and
c) to monitor long-term use of the product or system.
Early in design the emphasis is on obtaining feedback that can be used to guide design, while later when a more
complete prototype is available it is possible to measure whether user and organizational objectives (see 7.3) have
been achieved.
In the early stages of the development and design process, changes are relatively inexpensive. The longer the
process has progressed and the more fully the system is defined, the more expensive the introduction of changes
is. It is therefore important to start evaluation as early as possible.
7.5.2 Evaluation plan
An evaluation plan should be developed which identifies the relevant aspects of the following;
a) the human-centred design goals;
b) who is responsible for the evaluation;
c) what parts of the system are to be evaluated and how they are to be evaluated, for example, the use of test
scenarios, mock-ups or prototypes;
d) how evaluation is to be performed and the procedures for carrying out the tests;
e) resources required for evaluation and analysis of results and access to users (as necessary);
f) scheduling of evaluation activities and their relation to the project timetable;
g) feedback and use of results in other design activities.
Evaluation techniques vary in their degree of formality, rigour and user involvement, depending on the environment
in which the evaluation is conducted. The choice is determined by financial and time constraints, the stage in the
development life cycle and the nature of the system under development.
7.5.3 Provide design feedback
Evaluations should take place at all stages in the system life cycle in order to influence the system to be delivered.
Particular evaluation goals should reflect one or more of the objectives below:
a) to assess how well the system meets its organizational goals;
b) to diagnose potential problems and identify needs for improvements in the interface, the supporting material,
the workstation environment or the training proposals;
c) to select the design option that best fits the functional and user requirements;
d) to elicit feedback and further requirements from the users.
Expert evaluation can be fast and economical and is good for identifying major problems but is not sufficient to
guarantee a successful interactive system. The standards and guidelines referenced in annex A and the
bibliography provide processes and criteria which can be used as a basis for this type of evaluation.
User-based evaluation can be used to provide feedback at any stage of design. In the early stages, users can be
involved in the evaluation of scenarios, simple paper mock-ups or partial prototypes (see 7.4.5 for details of
prototyping and iteration).
As design solutions become more developed, evaluations involving users are based on progressively more
complete and concrete versions of the system. When trying to improve a prototype to meet human-centred design
© ISO
objectives, cooperative evaluation can be valuable, where the evaluator discusses problems with the user as they
occur. See the bibliography for sources of further information.
7.5.4 Assess whether objectives have been achieved
Evaluation can be used
a) to demonstrate that a particular design meets the human-centred requirements and
b) to assess conformity to international, national, local, corporate or statutory standards.
Further information on evaluation criteria can be found in the standards listed in annex A. To obtain valid results, the
evaluation should use appropriate methods, with a representative sample of users performing realistic tasks.
The choice of evaluation criteria for human-centred goals depends on the requirements for the product and the
needs of the organization setting the criteria. Objectives can relate to a primary goal (e.g. produce a letter) or a sub-
goal (e.g. successfully search and replace an item) or secondary goals (e.g. maintainability). Focusing objectives on
the most important user goals can mean ignoring other functions, but is normally the most practical approach.
Setting objectives for specific sub-goals can permit evaluation earlier in the development process. It may be
necessary to specify criteria both for the minimum acceptable levels and for the target levels to be achieved. For
further information, see ISO 9241-11.
7.5.5 Field validation
The aim of field validation is to test the functioning of the final system to ensure that it meets the requirements of the
users, the tasks and the environment. The main techniques which can be used include help desk data, field reports,
real user feedback, performance data, reports of health impacts, design improvements, and requests for changes.
7.5.6 Long-term monitoring
There should be a plan and a process for long-term monitoring of the use of the product or system. Systematic
collection of user input is needed as part of the design and evaluation activities in a human-centred design process.
Long-term monitoring means collecting user input in different ways, over a period of time. There is an important
difference between short-term evaluation and long-term evaluation. Some effects of working with an interactive
system are not recognizable until the system has been used for a period of time or there may be effects which result
from external factors, for example, unforeseen changes in working practices.
Performance criteria and company health reports can provide assessment parameters for the long-term evaluation
process. Attention to human-centred design principles during the design phase can identify those parameters most
important to assess. Performance criteria can be quite straightforward: does the system achieve its productivity
goals? Information can be gained from standard economic and marketing studies, analyses of support costs,
modification requests and other data.
Criteria and measurements should be sensitive enough to identify system failure, or system problems, at an early
stage.
NOTE Identifying unsafe behaviour is clearly preferable to registering accidents, and identifying mental or physiological
overload is preferable to registering medical disorders.
7.5.7 Reporting the results
7.5.7.1 In order to manage the progress of iterative design, the results of the evaluations should be recorded in a
systematic way. Annex B provides an example of the structure of a report used to provide feedback to design based
on user testing. If claims are to be made about a design process meeting the recommendations in this International
Standard, then those assessing the claims, whether customers, third-party assessors or the suppliers themselves
will require suitable evidence of adequate evaluation. See annex A and the bibliography for examples of standards
giving information on suitable evidence of adequate evaluation. In particular, there should be suitable evidence that
a) an adequate number of users took part in the testing and these users were representative of those identified in
the context of use,
b) there was testing of the major human-centred objectives,
© ISO
c) there were valid testing and data collection methods,
d) there was an appropriate treatment of test results, and
e) the conditions of testing were appropriate.
There are three types of evaluation reporting that can be useful during the design process, depending on whether
the purpose of the evaluation is to feedback to design, to test against specific standards or to provide evidence of
achieving human-centred goals, for example, in terms of usability or user health and safety.
7.5.7.2 Reporting of feedback to design should
take place at an appropriate time in the development process,
be based on appropriate sources of evaluation e.g. users, design reviews,
provide design feedback in a form which supports design decisions, and
result in demonstrable changes in the system, where applicable.
7.5.7.3 Reporting on tests of the design against specific standards should
identify relevant standards and provide a rationale for their use,
provide evidence that the assessment was conducted by a competent person using appropriate procedures,
provide evidence that sufficient parts of the system were tested to give meaningful results for the system as a
whole,
report how non-conformities were dealt with in the design, and
justify any deviations from applicable standards.
7.5.7.4 Reporting on user testing should
define the context of use which was used for evaluation,
provide information on the user and organizational requirements,
describe the product tested and its status, e.g. production prototype,
describe the measurements undertaken, users and methods used,
contain results with relevant statistical analysis, and
indicate a pass/fail decision in relation to the requirements.
8 Conformance
If a development process is claimed to have met the recommendations in this International Standard, the
procedures used, the information collected and the use made of the results shall be specified. The level of
specification of the procedure and the level of detail for reporting the information collected are a matter of
negotiation between the involved parties.
Users of this International Standard can either utilize the procedure and forms provided in annex C or develop
another procedure tailored to their particular development and/or environment.
© ISO
Annex A
(informative)
Guidance on other relevant standards
A.1 General
Standards related to human-centred design fall into two categories:
process-oriented: these specify procedures and processes to be followed;
product-oriented: these specify required attributes of the user interface.
Some product-oriented standards specify the requirements in terms of performance rather than product
attributes. These standards describe the users, tasks, and context of use and assess usability in terms of
user performance and satisfaction to be achieved.
A.2 Process-oriented
ISO 6385:1981, Ergonomic principles in the design of work systems.
ISO 6385 sets out the ergonomic principles which should be applied to the design of work systems. This
International Standard is bas
...
NORME ISO
INTERNATIONALE 13407
Première édition
1999-06-01
Processus de conception centrée sur
l'opérateur humain pour les systèmes
interactifs
Human-centred design processes for interactive systems
A
Numéro de référence
Sommaire
1 Domaine d’application .1
2 Termes et définitions.1
3 Structure de la présente Norme internationale.2
4 Raisons motivant l’adoption d’un processus de conception centrée sur l'opérateur humain.2
5 Principes de la conception centrée sur l’opérateur humain .3
5.1 Généralités .3
5.2 Participation active des utilisateurs et compréhension claire des exigences liées à l’utilisateur et
à la tâche.3
5.3 Répartition appropriée des fonctions entre les utilisateurs et le système .4
5.4 Itération des solutions de conception.4
5.5 Conception pluridisciplinaire .4
6 Planification du processus de conception centré sur l’opérateur humain.5
7 Activités de conception centrée sur l’opérateur humain.6
7.1 Généralités .6
7.2 Comprendre et spécifier le contexte d’utilisation .6
7.3 Spécifier les exigences liées à l’utilisateur et à l’organisation .8
7.4 Produire des solutions de conception .9
7.5 Évaluer les solutions conçues par rapport aux exigences .11
8 Conformité.14
Annexe A (informative) Orientations quant aux normes correspondantes.15
Annexe B (informative) Exemple de structure d'un rapport d'évaluation relatif à l'utilisabilité.20
Annexe C (informative) Exemple de procédure de démonstration de la conformité à la présente
Norme internationale.23
Bibliographie.28
© ISO 1999
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l'éditeur.
Organisation internationale de normalisation
Case postale 56 • CH-1211 Genève 20 • Suisse
Internet iso@iso.ch
Imprimé en Suisse
ii
© ISO
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée aux
comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du comité
technique créé à cet effet. Les organisations internationales, gouvernementales et non gouvernementales, en
liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI, Partie 3.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
La Norme internationale ISO 13407 a été élaborée par le comité technique ISO/TC 159, Ergonomie, sous-comité
SC 4, Ergonomie de l'interaction homme/système.
Les annexes A, B et C de la présente Norme internationale sont données uniquement à titre d'information.
iii
© ISO
Introduction
La conception centrée sur l’opérateur humain est une manière de concevoir les systèmes interactifs, ayant pour
objet spécifique de rendre les systèmes utilisables. Il s’agit d’une activité pluridisciplinaire faisant appel aux
connaissances et techniques du domaine des facteurs humains et de l’ergonomie. L’application des facteurs
humains et de l’ergonomie à la conception des systèmes interactifs favorise leur efficacité et leur efficience,
améliore les conditions du travail humain et réduit les effets nuisibles de leur utilisation sur la santé, la sécurité et
les performances. L’application de l’ergonomie à la conception des systèmes suppose la prise en compte des
aptitudes, des compétences, des limitations et des besoins propres à l’être humain.
Les systèmes centrés sur l’opérateur humain assistent les utilisateurs et les motivent pour apprendre. Il est alors
possible, entre autres avantages, d’accroître la productivité, de renforcer la qualité du travail, de réduire les frais
d’assistance technique et de formation, et d’améliorer la satisfaction de l’utilisateur. Bien qu’il existe un ensemble
substantiel de connaissances relatives aux facteurs humains et à l’ergonomie concernant l’organisation et la mise
en œuvre de processus de conception efficaces, seuls les spécialistes de ces domaines détiennent la plupart des
informations. La présente Norme internationale a pour objet d’aider les responsables de la conception des matériels
et logiciels à identifier et planifier les activités de conception centrée sur l’opérateur humain, de manière efficace et
à bon escient. Elle vient en complément des approches et des méthodes de conception déjà existantes.
iv
NORME INTERNATIONALE © ISO ISO 13407:1999(F)
Processus de conception centrée sur l'opérateur humain pour les
systèmes interactifs
1 Domaine d’application
La présente Norme internationale énonce des recommandations relatives aux activités de conception centrée sur
l’opérateur humain, durant toute la durée de vie des systèmes interactifs informatisés. Elle s’adresse aux personnes
responsables des processus de conception et fournit un guide des sources d’information et des normes traitant de
l’approche centrée sur l’opérateur humain.
La présente Norme internationale concerne les composants matériels aussi bien que logiciels des systèmes
interactifs.
NOTE Les systèmes interactifs informatisés présentent des différences de taille et de complexité. Ils comprennent par
exemple les produits logiciels disponibles immédiatement (prêts à l’emploi), les logiciels de bureautique personnalisés, les
systèmes de surveillance des unités de production, les systèmes bancaires automatisés et les produits destinés au grand
public.
La présente Norme internationale concerne la planification et la gestion de la conception centrée sur l’opérateur
humain. Elle ne traite pas de l’ensemble des aspects relatifs à la conduite de projet.
La présente Norme internationale donne un aperçu des activités de conception centrée sur l’opérateur humain. Elle
ne couvre pas de manière exhaustive les méthodes et techniques de conception centrée sur l’opérateur humain, ni
le détail de tous les aspects liés à la santé et à la sécurité.
Les chefs de projet sont les principaux utilisateurs de la présente Norme internationale. Celle-ci n’aborde donc les
aspects techniques des facteurs humains et de l’ergonomie que dans la mesure où les chefs de projet ont besoin
d’appréhender l’adéquation et l’importance de ces données par rapport au processus de conception dans son
ensemble. Ces problèmes font l’objet d’un traitement plus complet dans l’ISO 9241 (voir la Bibliographie),
complémentaire de la présente Norme internationale et s’adressant aux développeurs, spécificateurs et acheteurs
de systèmes. Il convient néanmoins que toutes les parties impliquées dans la mise au point de systèmes centrés
sur l’opérateur humain, y compris les utilisateurs finaux de ces systèmes, puissent exploiter de manière adéquate
les recommandations de la présente Norme internationale.
2 Termes et définitions
Pour les besoins de la présente Norme internationale, les termes et définitions suivants s'appliquent.
2.1
système interactif
combinaison d’éléments matériels et logiciels qui échangent des données en provenance et en direction d’un
utilisateur, afin d’aider celui-ci à accomplir sa tâche
NOTE Le terme «système» est souvent préféré à «système interactif».
2.2
prototype
représentation de tout ou partie d’un produit ou système qui, bien que partielle, peut être utilisée pour une
évaluation
© ISO
2.3
utilisabilité
degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour atteindre des buts définis avec
efficacité, efficience et satisfaction, dans un contexte d'utilisation spécifié
[ISO 9241-11: 1998, définition 3.1]
2.4
efficacité
précision et degré d'achèvement selon lesquels l’utilisateur atteint des objectifs spécifiés
[ISO 9241-11: 1998, définition 3.2]
2.5
efficience
rapport entre les ressources dépensées et la précision et le degré d'achèvement selon lesquels l’utilisateur atteint
des objectifs spécifiés
[ISO 9241-11: 1998, définition 3.3]
2.6
satisfaction
absence d'inconfort et attitudes positives dans l'utilisation du produit
[ISO 9241-11: 1998, définition 3.4]
2.7
contexte d’utilisation
utilisateurs, objectifs, tâches, équipement (matériel, logiciel et documents) et environnements physique et social
d'utilisation d’un produit
[ISO 9241-11: 1998, définition 3.5]
2.8
utilisateur
personne qui interagit avec le produit
[ISO 9241-10: 1996, définition 2.2]
3 Structure de la présente Norme internationale
L’article 4 expose les raisons motivant l’adoption d’un processus de conception centrée sur l’opérateur humain. Ces
raisons peuvent servir à justifier l’usage des méthodes centrées sur l’opérateur humain ou à définir les priorités qui
président à l’affectation des ressources d’un projet.
L’article 5 donne une orientation relative aux principes de conception centrée sur l’opérateur humain. L’article 6
recense les problèmes à prendre en considération lors de la planification des activités de conception centrée sur
l’opérateur humain et argumente leur relation aux objectifs de conception du système.
L’article 7 constitue l’essentiel de la présente Norme internationale. Il décrit chacune des quatre activités principales
centrées sur l’opérateur humain, généralement comprises dans un processus de conception. L’article 8 apporte des
recommandations supplémentaires pour rendre compte des activités centrées sur l’opérateur humain.
4 Raisons motivant l’adoption d’un processus de conception
centrée sur l'opérateur humain
Il convient que tous les systèmes de travail satisfassent aux principes ergonomiques décrits dans l’ISO 6385:1981.
La création de systèmes interactifs davantage centrés sur l’opérateur humain permet de réaliser des gains
substantiels sur le plan socio-économique. Dans la plupart des pays, les employeurs et les fournisseurs de
© ISO
systèmes sont astreints à des obligations juridiques qui protègent les utilisateurs des risques concernant leur santé
et leur sécurité. Accroître l’utilisabilité des systèmes signifie qu’ils peuvent mieux atteindre les objectifs fixés, en
apportant une meilleure satisfaction des besoins liés à l’utilisateur et à l’organisation. Ainsi, les systèmes
a) sont plus faciles à comprendre et à utiliser, d’où une réduction des frais de formation et d’assistance technique,
b) accroissent la satisfaction de l’utilisateur et diminuent les gênes et les contraintes,
c) augmentent la productivité des utilisateurs et l’efficience opérationnelle des entreprises,
d) et renforcent la qualité, l’esthétique et l’impact du produit, et peuvent être à l’origine d’avantages par rapport
aux concurrents.
Il est possible de mesurer la totalité des avantages de la conception centrée sur l’opérateur humain en prenant en
compte la totalité des coûts pendant la durée de vie du produit, y compris les phases d'étude, de conception, de
mise en œuvre, d’assistance technique, de fonctionnement et de maintenance.
5 Principes de la conception centrée sur l’opérateur humain
5.1 Généralités
De nombreuses méthodes normalisées propres à un secteur industriel ou à une entreprise permettent de concevoir
des systèmes informatisés interactifs. La présente Norme internationale ne présuppose pas une démarche unique
de conception normalisée, et ne couvre pas l’ensemble des activités nécessaires à la garantie d’efficacité de la
conception du système. Elle est complémentaire des méthodes de conception existantes et offre une perspective
centrée sur l’opérateur humain pouvant s’intégrer à différentes formes de processus de conception, en accord avec
les particularités du contexte. Toutes les activités de conception centrée sur l’opérateur humain répertoriées dans
l'article 7 s'appliquent, dans une mesure plus ou moins large, à toute étape du développement d'un système.
Quel que soit le processus de conception ainsi que la répartition des responsabilités et des rôles adoptés,
l'intégration d'une approche centrée sur l’opérateur humain se caractérise par
a) la participation active des utilisateurs et une compréhension claire des exigences liées à l’utilisateur et à la
tâche;
b) une répartition appropriée des fonctions entre les utilisateurs et la technologie;
c) l’itération des solutions de conception;
d) une conception pluridisciplinaire.
5.2 Participation active des utilisateurs et compréhension claire des exigences liées à
l’utilisateur et à la tâche
La participation des utilisateurs au processus de développement représente une source non négligeable de
connaissances sur le contexte d’utilisation, les tâches et la manière dont les utilisateurs seront amenés à travailler
par la suite avec le produit ou système. L’incidence de la participation des utilisateurs augmente parallèlement à
l'accroissement de l'interaction entre les développeurs et les utilisateurs. La nature de la participation des
utilisateurs varie suivant les activités de conception considérées.
Lors de la mise au point de produits personnalisés, les utilisateurs proposés et les tâches effectuées peuvent être
directement impliqués dans le processus de développement. L’organisme fournisseur du système a l’occasion
d’exercer une influence directe sur la conception à mesure que celle-ci progresse, et les solutions peuvent être
évaluées par les personnes amenées à travailler effectivement avec le produit. Une implication et une participation
de cet ordre permettent également de renforcer l’adhésion et l’intérêt manifestés à l’égard du produit.
Lors de la mise au point de produits génériques ou grand public, les utilisateurs forment une population dispersée et
pas toujours aisément accessible. Il demeure essentiel que les utilisateurs ou des représentants appropriés soient
impliqués dans le développement, de sorte que les exigences liées à l’utilisateur et à la tâche puissent être
© ISO
identifiées et faire partie des spécifications du système, et pour qu’un retour d’informations puisse avoir lieu après la
mise à l’essai des solutions de conception proposées.
5.3 Répartition appropriée des fonctions entre les utilisateurs et le système
La conception centrée sur l’opérateur humain compte, parmi ses principes essentiels, la répartition appropriée des
fonctions, c’est-à-dire la spécification des fonctions qu’il convient d’assigner soit aux utilisateurs, soit à la
technologie. Ces décisions de conception visent à déterminer dans quelle mesure un travail, une tâche, une
fonction ou une responsabilité doivent faire l’objet d’un traitement automatisé ou être assignés à un opérateur
humain.
Il convient de prendre des décisions sur la base de nombreux facteurs, tels que les capacités et les limites de l’être
humain et de la technologie, en termes de fiabilité, de rapidité, de précision, de force, de souplesse de réponse, de
coût financier, selon l’importance revenant à une exécution correcte des tâches dans les délais fixés ainsi qu’au
bien-être de l’utilisateur. Il convient de ne pas prendre de décisions en se contentant de déterminer quelles sont les
fonctions qui peuvent être exécutées par les moyens techniques, et d’assigner seulement aux utilisateurs les
fonctions restantes, en se reposant sur leurs capacités d’adaptation pour assurer le fonctionnement du système. Il
convient que les fonctions humaines retenues forment un ensemble de tâches dotées d’une signification. Il convient
généralement de permettre à des utilisateurs représentatifs d’être impliqués dans ces décisions. Pour plus de
détails, consulter l’ISO 9241-2 et l’ISO 10075.
5.4 Itération des solutions de conception
Dans le cadre d’approches itératives de conception, le retour d’informations en provenance des utilisateurs devient
une source d’information importante. L’itération, conjuguée à une implication active de l’utilisateur, est un moyen
efficace pour minimiser les risques de se trouver face à un système ne répondant pas aux exigences liées à
l’utilisateur et à l’organisation (y compris aux exigences non apparentes ou difficiles à formuler de manière
explicite). L’itération permet de mettre à l’essai des solutions de conception préliminaires dans des scénarios de
situations réelles, les informations récoltées en retour servant à élaborer progressivement des solutions affinées.
L’itération peut être intégrée à d’autres approches de conception. Une itération de grande envergure peut
également exister au niveau d’une étape, ce qui est également le cas pour le modèle en «cascade», dans lequel il
existe une hiérarchie descendante systématique de solutions de conception, où les relations entre les étapes
empêchent généralement leur itération.
5.5 Conception pluridisciplinaire
La conception centrée sur l’opérateur humain fait appel à une grande variété de compétences. Une catégorie de
personnel est sollicitée pour l’étude des aspects humains de la conception, ce qui signifie qu’un processus de
conception centrée sur l’opérateur humain suppose l’implication d’équipes pluridisciplinaires. Il peut s’agir de petites
équipes dont le temps d’existence n’excède pas la durée du projet. Il convient de composer des équipes qui
reflètent les relations entre l’organisme responsable du développement et le client. Les fonctions suivantes peuvent
être représentées:
a) utilisateur final;
b) acheteur, supérieur hiérarchique de l'utilisateur;
c) spécialiste du domaine de l’application, analyste économique;
d) analyste de systèmes, ingénieur système, programmeur;
e) responsable marketing, vendeur;
f) concepteur d’interface utilisateur, concepteur graphique;
g) expert en facteurs humains et ergonomie, spécialiste de l’interaction homme-machine;
h) auteur de documents techniques, personnel de formation et d’assistance technique.
© ISO
Les membres d’une équipe peuvent, à titre individuel, représenter une diversité de domaines de compétence et de
points de vue. L’effectif des équipes pluridisciplinaires ne doit pas être nécessairement élevé, mais il convient que
l’équipe soit suffisamment diversifiée pour que les compromis de conception soient décidés de manière appropriée.
6 Planification du processus de conception centré sur l’opérateur humain
Il convient d’élaborer un plan visant à spécifier de quelle manière les activités centrées sur l’opérateur humain
peuvent trouver leur place dans le processus global de développement du système.
Il convient que le plan permette d’identifier
a) les activités relatives au processus de conception centrée sur l’opérateur humain décrites à l’article 7, c’est-à-
dire comprendre et identifier le contexte d’utilisation, spécifier les exigences liées à l’utilisateur et à
l’organisation, créer des prototypes et évaluer les conceptions conformément aux critères de l’utilisateur;
b) les procédures permettant d’intégrer ces activités à d’autres activités de développement de systèmes, par
exemple analyse, conception, essais;
c) les individus, le ou les organisme(s) responsable(s) des activités de conception centrée sur l’opérateur humain,
ainsi que l’étendue de leurs compétences et de leurs points de vue;
d) des procédures concrètes visant à instaurer un retour d’informations et une communication relatifs aux activités
centrées sur l’opérateur humain, dans la mesure où celles-ci touchent à d’autres activités de conception, ainsi
que les méthodes de documentation de ces activités;
e) des points de contrôle portant sur les activités centrées sur l’opérateur humain intégrés à la totalité du
processus de conception et de développement;
f) des échéanciers permettant d’incorporer convenablement les retours d’informations et d'éventuelles
modifications de conception au plan du projet.
Il convient que ce processus de conception centrée sur l’opérateur humain fasse partie intégrante du plan de projet
global de développement du système et qu’il soit soumis aux mêmes disciplines de projet (par exemple
responsabilités, contrôle des changements) que les autres activités fondamentales, afin d’assurer un suivi
permanent et une mise en œuvre concrète du plan. Il convient de réviser le plan lorsque les exigences changent et
de le mettre à jour pour qu’il reflète l’état des activités.
Il convient que la planification de projet permette l’itération et l’incorporation d’un retour d’informations en
provenance de l’ utilisateur. Il est également nécessaire de consacrer du temps, d’une part à l’instauration d’une
communication effective entre les membres des équipes de conception, d’autre part à la résolution des conflits et
des désaccords potentiels. Les projets bénéficient d’une créativité supplémentaire et des idées recueillies du fait
des interactions des membres d'une équipe qui, collectivement, réunissent une base étendue de compétences. Le
complément de communication et d’échanges, nécessaires pour identifier et surmonter les difficultés aux stades les
plus précoces du projet, peut entraîner la réalisation d’économies notables à des stades ultérieurs, lorsque
d’éventuels changements se révèlent généralement plus coûteux.
Il convient que les organismes concepteurs incorporent la conception centrée sur l’opérateur humain à leurs
procédures et normes internes de développement déjà existantes, par exemple pour le prototypage, la mise à
l’essai, l’implication appropriée des utilisateurs, l’assurance d’un bon équilibre des compétences et des
connaissances au sein de l’équipe de développement.
Lorsque l’organisme développeur met au point des systèmes en s’appuyant sur un système d’assurance qualité et
de plans qualité associés, il convient dans ce cas d’ajouter un plan spécifique qui couvre le processus de
conception centrée sur l’opérateur humain et intègre des mesures de maîtrise de la qualité.
© ISO
7 Activités de conception centrée sur l’opérateur humain
7.1 Généralités
Il existe quatre activités de conception centrée sur l’opérateur humain, qu’il convient d’intégrer au projet de
développement du système.
Ces activités visent à
a) comprendre et spécifier le contexte d’utilisation;
b) spécifier les exigences liées à l’utilisateur et à l’organisation;
c) proposer des solutions de conception;
d) évaluer les conceptions par rapport aux exigences.
Il convient que le processus de conception centrée sur l’opérateur humain commence dès la première étape du
projet (c'est-à-dire lors de la formulation des spécifications initiales du produit ou du système) et soit répété de
façon itérative jusqu’à ce que les objectifs soient atteints, comme l’illustre la Figure 1.
La nécessité d’une approche de conception centrée sur l’opérateur humain sera identifiée à partir des objectifs
opérationnels du système, par exemple la satisfaction des exigences de l’utilisateur en termes d’utilisabilité.
Lors de la planification d’un projet de développement de système, il convient que la description de chaque activité
et de ses tâches soit étudiée et serve de guide pour sélectionner les méthodes et techniques de conception centrée
sur l’opérateur humain, qui serviront à réaliser l’activité et à rendre compte des progrès et des résultats. Bien que
toutes les activités humaines de conception décrites dans l'article 7 soient généralement concernées, l’intérêt relatif
et l’investissement consacrés à ces activités dépendent généralement de la taille et du type de produit; par exemple
un grand projet, un produit nouveau ou un nouveau système peuvent nécessiter une équipe pluridisciplinaire au
complet, composée d’un membre représentant chaque rôle significatif, et peuvent impliquer la mise en œuvre de
toutes les activités de conception centrée sur l’opérateur humain recommandées dans l'article 7. Par opposition,
des projets d’importance réduite, des produits ou systèmes issus de versions précédentes, ou des produits ciblés
sur des créneaux ou des marchés restreints, peuvent donner lieu à une équipe de conception moins importante,
dont chaque membre représente plusieurs rôles, et ne recourir qu’à certaines des méthodes et techniques de mise
en œuvre des activités.
7.2 Comprendre et spécifier le contexte d’utilisation
7.2.1 Les caractéristiques des utilisateurs, des tâches et des environnements organisationnels et physiques
définissent le contexte dans lequel le système est utilisé. Il est primordial de comprendre et d’identifier ce contexte
en détails, afin de guider les premières décisions de conception et définir une base pour l’évaluation.
Il convient de rassembler des informations sur le contexte d’utilisation des produits et systèmes nouveaux. En cas
de mise à jour ou d’extension d’un système déjà existant, il convient de vérifier ces informations si elles existent
déjà. Lorsqu’un grand nombre de résultats est collecté par le biais de retours d’informations côté utilisateur, de
rapports des groupes d’assistance ou d’autres données, ces résultats servent de base pour définir les exigences
prioritaires de l’utilisateur en ce qui concerne les modifications et les changements du système.
Il convient d’identifier, dans les termes suivants, le contexte dans lequel le système est censé fonctionner.
a) Les caractéristiques des utilisateurs potentiels: les caractéristiques propres aux utilisateurs peuvent inclure
les connaissances, les compétences, l’expérience, l’éducation, la formation, les caractéristiques physiques, les
habitudes, les préférences et les aptitudes. Si nécessaire, définir les caractéristiques de différents types
d’utilisateurs, en tenant compte des différences de niveaux d’expérience et des rôles tenus (personnel chargé de la
maintenance, de l’installation, etc.).
© ISO
Figure 1 — Interdépendance des activités de conception centrée sur l’opérateur humain
b) Les tâches confiées aux utilisateurs: il convient que les enjeux globaux de l’utilisation du système fassent
partie de la description. Il convient de décrire les caractéristiques des tâches susceptibles d’influer sur l’utilisabilité,
telles que la fréquence et la durée d’exécution. En cas de risque pour la santé ou la sécurité, par exemple dans le
cas de la surveillance du comportement d’une machine pilotée par un ordinateur, il convient également de décrire
ces risques. Il convient d’inclure, dans la description, la répartition des activités et des phases opérationnelles entre
les composantes humaines et techniques. Il convient de ne pas décrire les tâches uniquement en termes de
fonctions ou d’attributs d’un produit ou système.
c) L'environnement dans lequel le système sera utilisé: l’environnement comprend les éléments matériels,
logiciels et les produits employés. Il est possible de les décrire sous forme d’un ensemble de produits, dont l’un ou
plusieurs peu(ven)t être d’intérêt essentiel pour les spécifications et évaluations centrées sur l’opérateur humain, ou
encore sous forme d’une série d’attributs ou de caractéristiques de performances qualifiant les éléments matériels,
logiciels et autres.
Il convient également de décrire les caractéristiques pertinentes de l’environnement physique et social. Ceci peut
consister en normes pertinentes, attributs de l’environnement technique (par exemple un réseau local de
communication), l’environnement physique (par exemple poste de travail, mobilier), l’environnement ambiant (par
exemple température, humidité), l’environnement juridique (par exemple les lois, règlements et directives), ainsi que
l’environnement socioculturel (par exemple les pratiques, la structure et les attitudes au sein de l’entreprise).
7.2.2 Il convient que cette activité aboutisse à une description des caractéristiques pertinentes des utilisateurs,
des tâches et de l’environnement identifiant les aspects dont l’impact est déterminant sur la conception du système
(voir l’ISO 9241-11 pour de plus amples informations sur le contexte d’utilisation et un exemple de rapport).
NOTE Il est peu probable que cette description constitue un résultat définitif obtenu en une seule fois. Il s’agit plus
couramment d’un «document de travail» produit dans un premier temps en termes généraux, et qui est ensuite critiqué,
corrigé, augmenté et mis à jour au fur et à mesure que le processus de conception et de développement progresse.
© ISO
Il convient que la description du contexte d’utilisation
a) spécifie la gamme d’utilisateurs potentiels, les tâches et les environnements, de façon suffisamment détaillée
pour que l’activité de conception soit possible;
b) soit obtenue à partir de sources fiables;
c) soit confirmée par les utilisateurs ou, si ceux-ci ne sont pas disponibles, par les personnes chargées de les
représenter durant tout le processus;
d) soit convenablement documentée;
e) soit mise à la disposition de l’équipe de conception, aux moments opportuns et sous une forme appropriée
pour exécuter l’activité de conception.
7.3 Spécifier les exigences liées à l’utilisateur et à l’organisation
7.3.1 Dans la plupart des processus de conception, l’une des activités majeures consiste à spécifier les exigences
fonctionnelles et autres, relatives au produit ou au système. Dans le cas de la conception centrée sur l’opérateur
humain, il convient que l’étendue de cette activité permette de définir explicitement les exigences liées à l’utilisateur
et à l’organisation, par rapport à la description du contexte d’utilisation. Il convient de prendre en compte les
éléments suivants pour identifier quelles exigences s'imposent:
a) les performances requises par le nouveau système, en regard des objectifs opérationnels et financiers;
b) les exigences d’ordre statutaire ou juridique, y compris les aspects relatifs à la sécurité et à la santé;
c) la coopération et la communication entre les utilisateurs et le reste des parties prenantes;
d) le travail confié aux utilisateurs (y compris la répartition des tâches, le bien-être et la motivation);
e) l’exécution des tâches;
f) la conception et l’organisation du travail;
g) la gestion des changements, y compris la formation et le personnel à impliquer;
h) la faisabilité du traitement et de la maintenance;
i) la conception de l’interface homme-machine et du poste de travail.
7.3.2 Il convient que les exigences liées à l'utilisateur et à l'organisation soient établies et que les objectifs soient
fixés en identifiant les compromis entre les différentes exigences. Il convient que cette spécification définisse
«l’allocation des fonctions», c’est-à-dire le partage entre les tâches système attribuées à l’homme et celles
accomplies par les moyens techniques. Il convient que ces exigences soient définies selon des termes qui
autorisent leur test ultérieur, et qu’elles soient confirmées ou mises à jour pendant toute la durée de vie du projet.
NOTE L’ISO/CEI 14598-1 énonce des recommandations particulières pour la spécification des logiciels dans une forme
pouvant être soumise à l’essai.
Il convient que les exigences liées à l’utilisateur et à l’organisation soient spécifiées
a) en identifiant la gamme d’utilisateurs potentiels et les autres personnels impliqués dans la conception;
b) en fournissant une définition claire des objectifs de conception centrée sur l’opérateur humain;
c) en fixant les priorités nécessaires en fonction des différentes exigences;
d) en fournissant des critères mesurables permettant le diagnostic de la conception en cours;
© ISO
e) après confirmation par les utilisateurs et par leurs représentants lors du processus de conception;
f) en incluant toute exigence d’ordre statutaire ou juridique;
g) en les documentant convenablement.
7.4 Produire des solutions de conception
7.4.1 Généralités
Les solutions de conception potentielles sont produites en mettant à profit l’état de la technique, l’expérience et les
connaissances des participants, ainsi que les résultats de l’analyse du contexte d’utilisation. Le processus implique
donc les activités suivantes:
a) utiliser les connaissances existantes pour développer des propositions de conception à partir de données
pluridisciplinaires;
b) matérialiser davantage les solutions de conception à l’aide de simulations, modèles, maquettes, etc.;
c) présenter les solutions de conception aux utilisateurs et leur donner la possibilité d’exécuter des tâches (ou des
simulations de tâches);
d) modifier la conception en fonction de retour d’information de la part de l’utilisateur et procéder à l’itération de ce
processus jusqu’à ce que les objectifs centrés sur l’opérateur humain soient atteints;
e) contrôler l’itération des solutions de conception.
7.4.2 Utiliser les connaissances acquises pour mettre au point des propositions de conception à partir de
données pluridisciplinaires
Il existe une grande quantité de connaissances scientifiques et théoriques sur l’ergonomie, la psychologie, les
sciences cognitives, la conception de produits et autres disciplines pertinentes, qui peuvent suggérer des solutions
potentielles de conception. De nombreux organismes disposent en interne de guides stylistiques relatifs aux
interfaces utilisateur, de connaissances sur les produits et d'informations marketing sur lesquels peut s’appuyer la
conception initiale, particulièrement utiles pour la conception de produits similaires. Les organismes de
normalisation nationaux et internationaux délivrent également des recommandations et des normes de conception
génériques relatives aux facteurs humains et à l'ergonomie. Voir les normes correspondantes dans l'annexe A et
les sources d’informations dans la Bibliographie.
7.4.3 Matérialiser davantage les solutions de conception à l’aide de simulations, modélisations, maquettes
et autres formes de prototypes
Le recours à des simulations, modélisations, maquettes et autres formes de prototypes permet aux concepteurs
d’établir une communication plus efficace avec les utilisateurs et de réduire les coûts de post-production
occasionnés, durant toute la durée de vie du produit, par les révisions ultérieures, ce qui, dans certains cas, a lieu
après la première présentation aux clients réels.
Les avantages escomptés sont les suivants:
a) rendre les décisions de conception plus explicites (ce qui permet aux membres de l’équipe de conception de
communiquer entre eux dès le début du processus);
b) permettre aux concepteurs d’explorer plusieurs options de conception avant d’en choisir une;
c) permettre la prise en compte des informations venant de l’utilisateur, dès le commencement du processus;
d) rendre possible l’évaluation de plusieurs itérations d’une conception et de variantes de conception;
e) améliorer la qualité et l'exhaustivité des spécifications de conception fonctionnelle.
© ISO
Le prototypage peut avoir lieu à différents stades d’une conception, depuis les idées de conception initiales issues
des informations relatives au contexte d’utilisation (par exemple au moyen de scénarios), jusqu’aux prototypes de
pré-production quasiment complets dans leurs moindres détails. Un prototype peut n’être qu’un simple croquis ou
se présenter sous forme complexe d’une simulation informatique, dont l’aspect est proche du produit final.
7.4.4 Présenter les solutions de conception aux utilisateurs et leur donner la possibilité d’accomplir des
tâches (ou des simulations de tâches)
Les utilisateurs peuvent être impliqués très tôt dans la conception, à l’aide de maquettes statiques sur support
papier. Cette démarche peut consister à présenter aux utilisateurs des croquis ou des images sur écran
représentant l’aspect final du produit/système, et à leur demander d’essayer de les exploiter dans un contexte
réaliste. Certains aspects de la conception (par exemple la facilité d’utilisation des arborescences de menus)
peuvent être évalués rapidement et à moindres frais. Dans le cas des produits matériels, des modélisations
tridimensionnelles construites à partir de produits simples peuvent donner un résultat tout aussi probant.
Les prototypes simples présentent un intérêt lors des étapes initiales, pour explorer les variantes possibles des
solutions de conception. Bien qu’il soit souhaitable de parvenir à des solutions de conception aussi réalistes que
possible, il est important que les investissements temporels, financiers et participatifs, consacrés à l’élaboration de
prototypes, ne soient pas élevés au point que des modifications ultérieures de la conception donnent lieu à des
réticences.
Dans le cadre d’une approche centrée sur l’opérateur humain, les prototypes ne sont pas simplement des
démonstrations destinées à proposer aux utilisateurs une vision préalable de la conception, mais ils sont utilisés
pour obtenir les informations de la part des utilisateurs et les exploiter ensuite pour mener à bien le processus de
conception.
Lorsqu’il n’est pas possible de présenter aux utilisateurs des prototypes lors des étapes initiales du processus de
conception (par exemple pour des raisons de confidentialité), l’évaluation peut être confiée à des experts.
L’évaluation par expertise peut se révéler valable, rentable et complémentaire des essais par les utilisateurs.
Toutefois, pour qu’un processus de conception soit centré sur l’opérateur humain, il convient de procéder, à l'étape
finale du test (au plus tard), à des essais avec des utilisateurs réels.
Voir les détails de l’évaluation de conception en 7.5.
7.4.5 Modifier la conception en fonction des informations provenant des utilisateurs et procéder à
l’itération de ce processus jusqu’à ce que les objectifs de conception soient atteints
Le niveau du prototype et le degré d’itération varient suivant plusieurs facteurs, dont l’importance attachée à
l’optimisation de la conception. Pour les développements de logiciels, le prototypage peut commencer par des
visualisations de conceptions sur écran, et se poursuivre par différentes étapes d’itération, aboutissant à un logiciel
interactif dont les fonctionnalités sont suffisantes pour accueillir un sous-ensemble de tâches utilisateur. À des
stades ultérieurs de la conception, les prototypes peuvent être évalués dans un contexte plus réaliste. Pour obtenir
les meilleurs résultats, il est préférable de procéder à plusieurs itérations avec les utilisateurs. Pour déterminer si
les objectifs généraux ont été atteints, il convient d’effectuer une évaluation moins formelle dans un contexte
réaliste, par exemple sans aide ni interruptions par l’évaluateur.
Les commentaires des utilisateurs et les difficultés observées lors de l'utilisation d'un prototype permettent
d'orienter les modifications de la conception fonctionnelle visant à améliorer l'utilisabilité du système. Dans certains
cas, le retour d'informations de la part des utilisateurs peut également contribuer à affiner la portée et l'objectif d'un
système interactif (voir 7.5.1).
7.4.6 Gérer l’itération des solutions de conception
Pour gérer l’évolution de la conception itérative, il convient d’enregistrer les résultats des activités répertoriées en
7.4.2 à 7.4.5. Ces enregistrements peuvent se présenter sous forme entièrement documentaire ou inclure des
produits de la conception elle-même, telle que des prototypes de logiciel ou de matériel. Elles comprennent
a) l’origine des connaissances et normes existantes employées, avec une indication de la manière dont elles ont
été prises en compte (ou les raisons pour lesquelles elles n’ont pas été suivies, selon les cas);
© ISO
b) les mesures garantissant que le prototype répond aux exigences fondamentales et aux règles de bonne
pratique;
c) la nature des problèmes identifiés ainsi que les modifications de la conception adoptées pour y remédier.
7.5 Évaluer les solutions conçues par rapport aux exigences
7.5.1 Généralités
L’évaluation constitue une étape essentielle de la conception centrée sur l’opérateur humain, qu’il convient
d’accomplir à tous les stades de la durée de vie du système. L’évaluation peut être utilisée pour
a) fournir un retour d’informations pouvant contribuer à améliorer la solution conçue;
b) juger si les objectifs liés à l’utilisateur et à l’organisation ont été atteints;
c) adapter l’utilisation à long terme du produit ou du système.
Au début du projet, l’accent est mis sur l’obtention d’un retour d’informations pouvant être utilisé pour orienter la
conception, tandis que lorsqu’un prototype plus complet est disponible, il est possible de déterminer dans quelle
mesure les objectifs liés à l’utilisateur et à l’organisation (voir 7.3) ont été atteints.
Aux stades initiaux du processus de développement et de conception, les modifications sont généralement peu
coûteuses. À mesure que le processus avance et que la définition du système se précise, l’introduction de
changements occasionne des frais plus élevés. Il est donc essentiel de commencer l’évaluation le plus tôt possible.
7.5.2 Plan d’évaluation
Il convient de mettre au point un plan d’évaluation qui identifie les aspects pertinents des éléments suivants:
a) les objectifs de conception centrée sur l’opérateur humain;
b) l’identification des personnes responsables de l’évaluation;
c) les parties du système à évaluer, ainsi que le procédé d’évaluation, par exemple l’usage de scénarios, de
maquettes ou de prototypes;
d) le mode d’évaluation et les procédures d'exécution des essais;
e) les moyens nécessaires pour évaluer et analyser les résultats et pour impliquer les utilisateurs (autant que
nécessaire);
f) le plan des activités d’évaluation et leur correspondance avec l’échéancier du projet;
g) les retours d’informations et l’utilisation des résultats dans d’autres activités de conception.
Les techniques d’évaluation présentent des différ
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...