CPUX-F

Curriculum and Glossary

Version 3.15 EN, 23 March 2018

Publisher: UXQB e. V.
Contact: [email protected]

www.uxqb.org

Author: UXQB
CPUX-F – Curriculum and Glossary – Version 3.15

Contents
Introduction............................................................................................................... 3
Overview of CPUX-F resources .............................................................................. 3
Learning Objectives................................................................................................. 3
Acknowledgments ................................................................................................... 4
1. The human-centred design process .................................................................. 5
2. Basic concepts .................................................................................................... 9
3. Plan the human-centred design process......................................................... 15
4. Analysis: understand and specify the context of use .................................... 16
5. Specify the user requirements ......................................................................... 27
6. Design: produce design solutions to meet user requirements ..................... 31
6.1. Dialogue principles and user interface guidelines ......................................... 37
7. Evaluate the design against user requirements ............................................. 43
7.1. Usability tests ................................................................................................ 43
7.2. Other evaluation methods ............................................................................. 50
Informative Appendix A. Model course for preparatory training ....................... 53
A.1. Day 1............................................................................................................. 53
A.2. Day 2............................................................................................................. 54
Informative Appendix B. Important changes to this document ......................... 55
Index ........................................................................................................................ 56

Copyright 2018 The User Experience Qualification Board, www.uxqb.org. The UXQB hereby
grants permission to use all or parts of this document for certification purposes and other
relevant purposes, provided that the source is clearly acknowledged.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 2 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Introduction
This document defines what you need to know in order to pass the certification test for
Certified Professional for Usability and User Experience - Foundation Level (CPUX-F). The
certification test will only cover concepts and knowledge that are described in this document.
Terms that are defined in the curriculum always appear in bold.

Overview of CPUX-F resources

All relevant information about the CPUX-F certification and other types of CPUX certifications
is freely available from UXQB.org – the website of the International Usability and User
Experience Qualification Board.
The information on UXQB.org includes:
• A complete list of recognised CPUX-F training providers and available courses.
Note that training is recommended but not required in order to take the CPUX-F
certification test.
• CPUX-F Curriculum and Glossary (this document) for download.
• A complete sample set of 40 CPUX-F certification questions with answers for
training purposes.
The Curriculum and Glossary document is available in several languages. For currently
available language versions, please check UXQB.org

We strongly recommend that you study the complete, publicly available sample set of
CPUX-F certification questions carefully before you take the certification test.

Learning Objectives

Learning objectives (LO) are brief statements at the start of each section that describe what
you are expected to know after studying that section.

The table at the beginning of each section shows that section’s learning objectives.
LO # Learning Objective

Learning Objectives are characterised by the keywords

Know – that is, recite, recognise
Understand – that is, compare, distinguish, explain, substantiate, summarise
Master – that is, analyse, communicate, document, execute, plan.
In other curricula, these 3 levels are designated “K1”, “K2” and “K3”, respectively.
The CPUX-F curriculum contains no learning objectives at the Mastering level.
CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 3 of 57
CPUX-F – Curriculum and Glossary – Version 3.15

Acknowledgments

This document was created by the following persons:

Chris Bailey
Nigel Bevan
Kay Behrenbruch
Holger Fischer
Thomas Geis
John Goodall
Rüdiger Heimgärtner
Oliver Kluge
Rolf Molich (Editor)
Sandra Murth
Knut Polkehn
Michael Richter
Julian Roland
Chris Rourke
Guido Tesch
Norbert Zellhofer
The following persons contributed to previous versions of the document: Peter Hunkirchen.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 4 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

1. The human-centred design process

LO # Learning Objective
1.1 Understand the basic elements of human-centred design: involving users; iteration based
on frequent usability evaluation; addressing the whole user experience
1.2 Understand the human-centred design activities and their interdependency
1.3 Understand the purpose of each deliverable of the human-centred design activities
1.4 Know what agile development and lean UX are
1.5 Know what usability maturity is
1.6 Know the usability maturity levels incomplete, performed, managed and innovating

Human-centred design is an approach to design that aims to make interactive systems

more usable by focusing on the use of the interactive system and applying usability
knowledge and methods.
Human-centred design is based upon an explicit understanding of users, goals, tasks,
resources and environments. Users are involved throughout the design. The design is
driven and refined by usability evaluation. The process is iterative – that is, it continues
until the user requirements are met. The design addresses the whole user experience
(UX).
Lean UX is an approach to human-centred design that focuses on a fast, iterative
approach through early usability evaluation and lightweight deliverables. Lean UX informs
and supports Agile development, where working but incomplete software is delivered early
and frequently, to enable quick feedback.
An organisation’s receptiveness to usability activities and findings may be influenced by its
usability maturity.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 5 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

PLAN THE HUMAN-CENTRED ANALYSIS: UNDERSTAND AND

DESIGN PROCESS SPECIFY THE CONTEXT OF USE

UX DELIVERABLES: UX DELIVERABLES:
• User experience project plan • Context of use description
• User group profiles
• Task models
• As-is scenarios
• Personas
• User journey maps

EVALUATE THE DESIGNS SPECIFY THE USER

AGAINST USER REQUIREMENTS REQUIREMENTS

UX DELIVERABLES: UX DELIVERABLES:
• Evaluation reports • User needs
• User requirements

PRODUCE DESIGN SOLUTIONS

TO MEET USER REQUIREMENTS

UX DELIVERABLES:
• Use scenarios
• Storyboards
• Task models
• Information architecture
• Navigation structure
• Style guide
• Wireframes
• Low-fidelity prototypes
DESIGN SOLUTION MEETS USER • High-fidelity prototypes
REQUIREMENTS

Figure 1. The interdependence of human-centred design activities according to the

ISO 9241-210 standard.
The black rectangles show the 5 key activities in an iterative, human-centred design
process. “UX deliverables” are common outputs from the corresponding activity. The grey
hatched arrows show iteration.
If a project has insufficient resources to produce all the UX deliverables specified in Figure 1,
some of the deliverables may be skipped, for example task models, user needs,
storyboards and user journey maps.
Human-centred design means planning for iterations, getting user feedback as early and
as often as possible. It is perfectly acceptable to run through the iterations often with
lightweight UX deliverables, for example in agile development.
All UX deliverables in Figure 1 are defined in the curriculum.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 6 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Human- An approach to design that aims to make interactive systems more usable by focusing on
centred design the use of the interactive system and applying human factors, ergonomics and usability
knowledge and methods.
Notes:
1. The concept “human-centred design” is used instead of “user-centred design” to
emphasise the need to consider additional stakeholders who may not be users.
2. Feedback from users through usability evaluation is a critical source of information in
human-centred design.
Iterative Repetitive.
An iterative process repeats steps in the human-centred design process until a usability
evaluation of the user interface shows that the user requirements have been adequately
met.
Agile A set of principles, methods and approaches for improving productivity by reducing
development documentation and unnecessary formalism, and focusing on iterative development in short
cycles, collaboration and communication, incremental improvement and adaptation to
changes.
Notes:
1. In an agile environment, design teams usually work in short development cycles, often
called sprints or iterations, of one week to one month. In each cycle, the goal is to
design, code and evaluate a feature or a group of features. Evaluation is carried out with
users and other stakeholders.
2. Usability methods that work well with agile development:
a. Frequent usability tests. Usability test participants are recruited well in advance
and scheduled each week, so whatever is ready can be usability tested. Appropriate
usability test tasks are prepared shortly before the usability test based on what is
available.
b. Low-fidelity prototyping with early mock-ups to prepare next iterations.
Lean UX An approach to human-centred design that integrates principles and methods for usability
and user experience into agile development, thereby achieving economic advantages.
Notes:
1. Agile development processes are the basis for lean UX, as the iterative approach in
teams and the realisation of small, well defined packages enables regular, small and fast
usability tests. The results from usability tests are then directly used in the next
iteration for the development.
2. Lean UX assumes that at first everything is a hypothesis and consequently needs to be
validated. The team learns through experiments with users in the context of use. Failure
is part of the learning process – not every hypothesis is validated, not every experiment
provides the desired results.
3. Instead of carrying out extensive user research upfront, lean UX derives the hypotheses
to be validated from known context of use information, e.g. from stakeholder
interviews. These hypotheses are then validated or questioned in subsequent contextual
interviews or usability test sessions.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 7 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Usability The level of understanding and implementation of a systematic human-centred design
maturity process within an organisation.
Notes:
1. Usability maturity can be expressed in a model with 4 levels:
a. Incomplete: The human-centred design process is not implemented, or fails to
achieve its process purpose.
Note: At this level there is little evidence of any systematic achievement of the
process purpose. Product managers may say that they care about usability, but when
it comes to spending budgets or making otherwise inconvenient decisions to achieve
usability, nothing happens. Usability is fine if it comes for free, but no one is
committed to delivering it.
b. Performed: The human-centred design process achieves its process purpose.
Note: Usability is achieved by enthusiastic individuals using ad-hoc processes.
c. Managed: The human-centred design process is implemented in a managed fashion,
and its work products are appropriately established, controlled and maintained.
Note: The process is planned, monitored and adjusted.
d. Innovating: The human-centred design process is continuously improved to respond
to change aligned with organisational goals.
Note: Process innovation objectives are defined that support the relevant business
goals.
2. To boost usability maturity in an organisation that is at level incomplete or performed,
carry out activities that clearly demonstrate the benefits of usability, for example:
a. Run usability tests. Invite stakeholders to participate in the planning of the usability
test. Ask stakeholders to observe usability test sessions and participate in writing
the usability test report.
b. Ask management and stakeholders to leave the office and put themselves in the
context of their users.
c. Ask management and staff to use their own products and services, like a customer.
They may never have used their company’s products.
d. Conduct usability tests of prototypes with project management as observers or test
participants.
3. The usability maturity model is based on the process measurement framework for
process capability in ISO 33020.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 8 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

2. Basic concepts
LO # Learning Objective
2.1 Understand usability and its three main criteria
2.2 Understand user experience (UX)
2.3 Understand the difference between usability and user experience
2.4 Know what a goal is
2.5 Understand user interface, dialogue and interactive system
2.6 Know what accessibility is
2.7 Know about important accessibility aids
2.8 Know the purpose and most basic contents of ISO 9241
2.9 Know the responsibilities that a user experience professional can have

Usability is the extent to which an interactive system is effective, efficient and satisfying
to use in a specified context of use.
An interactive system is effective if it supports what users need to do to reach their goals,
and if users can figure out how to do it.
An interactive system is efficient if it supports users in carrying out their tasks using as
few resources as possible. In most cases, this means that users must be able to complete
their tasks quickly.
An interactive system is satisfying if it is pleasant to use.
User experience (UX) considers satisfaction before, during and after use (whereas
usability considers satisfaction only during use). User experience before use may be
influenced by company branding, customer reviews, previous interactions, etc. User
experience after use may be influenced by product delivery, post-sales support, recent
interactions, etc.
Accessibility is the extent to which an interactive system enables users to interact with it,
regardless of their level of vision, hearing, dexterity, cognition, physical mobility, etc.
A user experience professional is a person who has specific responsibilities associated
with the human-centred quality of an interactive system. Their responsibilities include
analysis of the context of use, specifying user requirements, producing design solutions –
in particular prototypes – and carrying out usability evaluations.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 9 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Usability The 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.
Notes:
1. Usability depends on users, goals and tasks, and other aspects of the context of use.
2. Technical defects may lead to usability problems if they prevent users from solving
their tasks effectively or efficiently.
Effectiveness The accuracy and completeness with which users achieve specified goals.
Notes:
1. Accuracy is the extent to which an actual outcome matches an intended outcome.
2. Completeness is the extent to which the use of the system, product, or service produces
all intended outcomes.
3. Completeness can be measured as the success rate: (Number of users who achieve a
specified goal) / (Number of users who attempt to reach the specified goal).
4. Effectiveness is the attribute of usability that focuses on being able to accomplish tasks.
Example:
1. A car rental website does not offer users any opportunity to cancel a reservation. An
analysis of the context of use shows that users need this function. There is a problem
with the effectiveness of the website.
2. A car rental website enables users to cancel a reservation. A usability test shows that
only 5 out of 100 users are able to figure out how to cancel their reservation. Those who
are able to figure out how to do it, do so quickly. There is a problem with the
effectiveness but not with the efficiency of the website.
Efficiency The resources used in relation to the results achieved.
Notes:
1. Resources include time, human effort, financial and material resources.
2. Efficiency is the attribute of usability that focuses on being able to accomplish a task
using acceptable amounts of resources.
Example:
1. A car rental website enables users to cancel a reservation. A usability test shows that
the cancellation procedure is needlessly complicated even though all usability test
participants finally manage to cancel their reservations. The effectiveness of the
website is OK, since all users manage to achieve their goal. There is a problem with the
efficiency of the website.
2. Sluggish response caused for example by an overloaded interactive system is a
usability problem.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 10 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Satisfaction The extent to which the user’s physical, cognitive and emotional responses that result from
the use of an interactive system meet the user’s needs and expectations.
Notes:
1. Effectiveness and efficiency may influence satisfaction. For example, low effectiveness
or low efficiency may lead to low satisfaction.
Satisfaction may influence effectiveness and efficiency. For example, frustration may
cause users to quit a task, which influences effectiveness.
2. Satisfaction is often measured using a questionnaire. See the examples in the definition
of questionnaire.
3. The difference between satisfaction and user experience is that satisfaction results from
use, while user experience results from discovering, adopting and using the interactive
system, through to final use and recollections of use. In addition, user experience can
be influenced by more than just use, for example brand image, price and opinion of
others, but it is still related to actual or imagined use.
Examples of dissatisfaction and satisfaction:
1. Prolonged periods of use of a notebook without an external mouse causes muscular
discomfort.
2. Users say that it “takes forever” to reserve a car on a car rental website.
3. Users spontaneously say that they like the appearance of the home page of a car rental
website.
4. High prices or unacceptable terms of service in a web shop are not part of satisfaction
because satisfaction is about the usage of an interactive system. They may influence the
user experience.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 11 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
User A user’s perceptions and responses that result from the use and/or anticipated use of an
experience interactive system.
Notes:
1. Users’ perceptions and responses include the users’ emotions, beliefs, preferences,
comfort, behaviours, and accomplishments that occur before, during and after use.
2. User experience is a consequence of brand image, presentation, functionality, system
performance, interactive behaviour, and assistive capabilities of the interactive system.
It also results from the user’s internal and physical state resulting from prior
experiences, attitudes, skills, abilities and personality; and from the context of use.
3. Usability criteria can be used to evaluate aspects of user experience.
4. Usability is mainly about the interaction with the interactive system. User experience
also takes into account what happens before and after the interaction through to final use
and recollections of use. See the examples below.
5. User experience is mainly about satisfaction and fulfilment of expectations.
6. User experience is often referred to as UX.
7. The following figure shows the relationship between user experience and usability.
Usability is effectiveness, efficiency and satisfaction during actual use, while user
experience is the satisfaction or dissatisfaction during anticipated use, actual use and
after use.

User Experience
Fulfilment of
Expectation Satisfaction
expectations
Usability

Effectiveness

Efficiency

Anticipated use Actual use After use

Examples that illustrate the difference between usability and user experience:
When ordering flowers for delivery from a flower store’s website:
1. Usability problems encountered during checkout affect both the user experience and
usability.
2. The quality of the physical flowers delivered affects only the user experience. It does not
affect usability of the flower store’s website.
3. The experience of visiting the physical store affects the user experience of subsequent
visits to the website. It does not affect the usability of the flower store’s website.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 12 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Goal The intended outcome.
Notes:
1. Goals are used in human-centred design to express the intention of users on a high
level without foreclosing technical solutions. The concepts “goal” and “user need” are
related.
2. A goal is typically expressed in the form of a condition or state.
In contrast, a task is typically expressed in the form of an activity.
Examples:
1. Goal: Change the colour of my hair from brown to red.
Task: Book an appointment with my hairdresser using their website.
2. Goal: Visit a friend in a small city, 100 km away.
Task: Rent a car using the car rental website.
Renting a car is not a user goal.
User interface All components of an interactive system (software or hardware) that provide information
and controls for the user, to allow them to accomplish specific tasks with the interactive
system.
Dialogue An interaction between a user and an interactive system that consists of user actions
(input) and responses from the interactive system (output) in order to achieve a goal.
Interactive A combination of hardware, software and services that users interact with in order to
system achieve specific goals.
Notes:
1. This includes, where appropriate, packaging, user documentation, on-line help, support
and training.
2. Even systems that do not accept input from users are covered by this definition, for
example destination boards in an airport or signs in a train station.
Accessibility The extent to which an interactive system enables users to interact with it effectively,
efficiently and with satisfaction, regardless of their level of vision, hearing, dexterity,
cognition, physical mobility, etc.
Notes:
1. Standards and guidelines for accessibility are available; standards may be legally
enforced in some markets. Relevant guidelines include W3C’s Web Content
Accessibility Guidelines (WCAG) 2.0 and ISO 9241-171, Guidance on software
accessibility.
2. Assistive technologies, such as screen readers, may be used by people with visual
impairments to help them interact with an interactive system. Additional descriptions,
for example alt tags, can be added to the code of non-textual elements, such as pictures
and diagrams, to convey their meaning.
ISO 9241 A family of standards covering human-centred design.
Note:
1. ISO 9241 includes standards related to
a. Software ergonomics;
b. The human-centred design process;
c. Displays and display related hardware;
d. Physical input devices;
e. Workplace ergonomics;
f. Environment ergonomics;
g. Control centres.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 13 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
User A professional who has one or more of the following responsibilities in a project:
experience 1. Planning and managing the human-centred design process;
professional 2. Identifying and describing the context of use;
3. Deriving the user requirements;
4. Creating the information architecture and the navigation structure;
5. Defining and conceiving the interaction between humans and the interactive system
based on the context of use and the user requirements;
6. Designing the graphic part of the user interface;
7. Carrying out usability evaluations of user interfaces in various stages of realisation.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 14 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

3. Plan the human-centred design process

LO # Learning Objective
3.1 Know what the planning activities for a human-centred design project are
3.2 Understand what human-centred quality objectives are

In the planning activity, the user experience manager plans the human-centred part of the
design activities for an interactive system.
Planning activities include appointing the manager of human-centred design activities, and
either writing the user experience project plan or including human-centred design
activities in the project plan. The user experience project plan includes human-centred
quality objectives. Planning includes the appointment of other user experience
professionals who will participate in the project.

Term Definition
User A description of the human-centred design activities and deliverables for an interactive
experience system.
project plan
Notes:
1. The description can be an independent document or a part of the overall project plan.
2. The user experience project plan contains:
a. The human-centred quality objectives specific to the project;
b. The planned human-centred deliverables and the activities needed to produce those
deliverables as part of the project;
c. The time plan;
d. The cost estimate for the human-centred design activities.
Human- The goals that are to be achieved for the user of an interactive system when developing the
centred interactive system.
quality
Notes:
objectives
1. Human-centred quality objectives relate to one or more of the following components of
human-centred quality: usability, accessibility, user experience and avoidance of harm
from use.
Examples of human-centred quality objectives:
1. Travelers to the US must be able to pass through immigration twice as quickly as before
(usability, efficiency).
2. Blind users must be able to recognise and understand the content of the website
(accessibility).
3. Users must have a feeling of complete privacy when using the electronic voting booth
(user experience).
4. When using a system for creating prescriptions, the user must not be able to prescribe
drugs that are incompatible with each other (avoidance of harm from use).

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 15 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

4. Analysis: understand and specify the context of use

LO # Learning Objective
4.1 Understand the context of use
4.2 Understand the concept: user
4.3 Understand the differences between primary, secondary and indirect users
4.4 Understand the concept: stakeholder
4.5 Know what a user group and a user group profile are
4.6 Understand the concept: task
4.7 Understand the difference between a task and a subtask
4.8 Know what environment means
4.9 Know what a resource is
4.10 Know what a task model is
4.11 Know what a focus group is
4.12 Know what observation is
4.13 Understand what a contextual interview is
4.14 Understand the difference between an interview and a contextual interview
4.15 Understand the master-apprentice model
4.16 Understand the interview checklist
4.17 Understand the differences between open, closed, neutral and leading questions
4.18 Understand what an as-is scenario is
4.19 Understand what a persona is
4.20 Understand what a user journey map is and what touchpoints are

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 16 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

The purpose of “Analysis: understand and specify the context of use” is to understand and
describe who the users are, what they do, what problems they have, and what their needs
are, with respect to the planned interactive system.
To understand users and their needs, we can observe users performing tasks, interview
users and conduct focus groups.
In a focus group, a moderator leads a group of participants through a focused discussion
around a set of questions on specific topics.
Interviews should focus on gathering information about the current context of use rather
than the interactive system itself. They should be done contextually. A contextual
interview takes place at the location where the user’s interaction with the interactive
system usually takes place, for example the user’s workplace, their home or in a shop. An
ordinary interview takes place in a neutral environment, for example in a meeting room.
During a contextual interview, the interviewer treats the interviewee as the master while the
interviewer is the humble apprentice (master-apprentice model). The interviewer asks
because they sincerely want to learn – not because they want to demonstrate their
knowledge. The interviewer should use open and neutral interview questions rather than
closed and leading questions to avoid biasing the interviewee. The interviewer should rely
on an interview checklist to ensure that all relevant topics are addressed, rather than using
it to control or steer the interview.
The outcome of this activity is a description of the context of use. The context of use has
five components: Users (people who interact with the interactive system), Goals (what
users want to achieve), Tasks (what users do to achieve their goals), Environment (where
the interaction takes place), and Resources (the means required to perform the task).
The context of use is described in user group profiles and personas (who are the users),
as-is scenarios (how do users currently do tasks), task models (details about what the
tasks are) and user journey maps (how users interact with the interactive system and the
organisation providing it).
A user group profile is a generalised description of a collection of users with the same or
similar personal characteristics and context of use related to the interactive system.
A persona is a description of a fictitious but realistic user and what he or she intends to do
when using the interactive system.
An as-is scenario is a narrative text description of the procedure a specific user currently
follows to complete one or more tasks,
A task model is a list of subtasks for each task which the user has to complete to reach
their goals. Task models help the design team to design the right solution for each task.
User journey maps provide an overview of the touchpoints where users interact with the
interactive system and the organisation providing the interactive system. They help
stakeholders and user experience professionals understand and optimise the user
experience.
The main purpose of personas and as-is scenarios is to identify user needs and make it
easier for designers, developers and other stakeholders to understand who the users are,
what they do, what their obstacles are, and to facilitate discussions within the design team.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 17 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Context of use A combination of users, goals, tasks, resources, and environments.
Notes:
1. The context of use is determined by interviewing users or by observing them carry out
tasks.
2. The results from focus groups, observation and contextual interviews are described in
the context of use description.
Examples of contexts of use, users, goals and tasks, environments and resources:
1. Consider the interactive system “messaging app”:
Teenagers on a bus use their phones to send messages to their friends to make them
laugh.
a. Users: Teenagers;
b. Goal: Make friends laugh;
c. Task: Send message;
d. Social environment: Friends:
e. Physical environment: Bus;
f. Resource: Phone.
2. Consider the interactive system “text processor”:
Secretaries in a school office create certificates for students in time for graduation; they
validate the certificates with stamps.
a. Users: Secretaries;
b. Goal: Have the certificates ready in time for graduation;
c. Task: Create certificates;
d. Social environment: School staff and students;
e. Physical environment: School and school office;
f. Resource: Stamp.
Context of use A description of the users, goals, tasks, resources, and environments derived from
description observations, contextual interviews and focus groups.
Notes:
1. The context of use description is the basis for identifying user needs and tracing them
back to their source.
2. A context of use description describes:
a. Users, in the form of user group profiles and personas;
b. Goals in the form of as-is scenarios;
c. Tasks, in the form of task models, as-is scenarios or user journey maps;
d. Resources, in the form of lists or as-is scenarios;
e. Environments, in the form of as-is scenarios.
3. Examples of components within a context of use description are user group profiles,
personas, as-is scenarios, task models and user journey maps.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 18 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
User A person who interacts with an interactive system, or who uses the output of the system.
Notes:
1. A user is one of the following:
a. Primary user: a user who uses the interactive system for its intended purpose.
b. Secondary user: a user who carries out support tasks with the interactive system,
for example to maintain it or to train primary users.
c. Indirect user: a user who uses the output of the interactive system, but who does
not interact directly with it.
2. Stakeholders may or may not be users. Stakeholders are not considered to be users if
they are affected by an interactive system but don’t interact with it or use its output.
Examples of stakeholders who are not users:
1. The non-technical managers of a team of technical users.
2. People affected by the noise produced by an interactive system.
3. Marketers affected by the impact of the use of the interactive system on the brand.
Examples:
1. A customer (user) uses a car reservation website to make a reservation – The customer is
a primary user of the system.
2. A customer (user) calls the reservation centre where a customer service representative
uses the same system to make the reservation for them – The customer is an indirect
user of the system.
Primary user A user who uses the interactive system for its intended purpose.
Examples of primary users:
1. A bank customer who uses a cash dispenser to withdraw money is a primary user of the
cash dispenser.
2. A call centre operative who uses a reservation system to reserve cars for customers is a
primary user of the reservation system.
Secondary A user who carries out support tasks with the interactive system, for example to maintain it
user or to train primary users.
Note:
1. Secondary users – in particular maintenance staff – typically interact with a different
user interface than primary users. This user interface also requires context analysis
and specification of user requirements to be usable.
Examples of secondary users:
1. A user who prints a document on a printer is a primary user of the printer. When the
same user a moment later changes the ink on the printer, he or she is a secondary user of
the printer.
2. A bank employee who restocks a cash dispenser with cash is a secondary user of the
cash dispenser.
3. A trainer who teaches a call centre operative how to use a car reservation system is a
secondary user of the reservation system.
Indirect user A user who uses the output of the interactive system, but who does not interact directly
with the interactive system.
Examples of indirect users:
1. A bank customer who receives a paper or electronic statement is an indirect user of the
bank’s computer system.
2. A customer who contacts the call centre to reserve a car is an indirect user of the
computer system used by the call centre operative to make the reservation.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 19 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Stakeholder An individual or organisation with an active interest in an interactive system.
Notes:
1. All users are stakeholders, but not all stakeholders are users.
To highlight the distinction, you can use the phrase “users and other stakeholders”.
2. Market requirements and organisational requirements are examples of
requirements from stakeholders who are not users.
Examples:
1. Stakeholders might include: users, technical support, trainers, documentation writers
and developers.
2. Stakeholders who may not be users might include: designers, developers, managers of
development teams, shareholders, board members and marketing professionals.
User group A collection of users with the same or similar personal characteristics and contexts of use
related to the interactive system.
User group A generalised description of a user group.
profile
Example of a user group profile for the website of a van rental company:
1. Customers – Private people who want to move house
Private people rent a cargo van, for example because they want to move house. Most
rentals are booked in advance and last 2-3 days. Most customers are one-time only
customers.
Customers have no particular experience with cargo vans – they are used to smaller cars.
They are unfamiliar with business terms and conventions in cargo van rental.
Customers are reasonably familiar with the internet and are reluctant to provide their
email address unless there is an explicit guarantee that they won’t receive spam emails
as a result.
Task A set of activities undertaken in order to achieve a specific goal.
Notes:
1. Most tasks can be subdivided into subtasks – that is, activities.
2. A subtask does not in itself achieve a goal from the user’s point of view but is a
necessary decision or action to reach the user’s goals.
3. Most subtasks lead to choices or inputs by the user when using the interactive system.
4. Some subtasks can be subdivided into smaller subtasks.
5. Subtasks are unsuitable as usability test tasks, because they are very specific.
Examples of tasks and subtasks:
1. “Rent a car” is a task.
2. “Cancel a car rental reservation” is a task.
3. “Register on a car rental website” is a subtask.
4. “Log in to a car rental website” is a subtask.
5. The subtask, “Log in to a car rental website”, can be broken down into smaller subtasks,
such as:
a. Enter the username;
b. Enter the password;
c. Tick the ‘Remember me’ checkbox.
Environment The physical, social and technical conditions in which a user interacts with an interactive
system.
Note:
1. The social conditions include the organisational conditions.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 20 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Resource All means required to use an interactive system.
Note:
1. Resources can be
a. Reusable – for example: equipment, information and available human-based and
system-based support; or
b. Exhaustible – for example: time, human effort, financial resources and materials.
Task model A description of the subtasks within a task that have to be carried out in order to reach the
user’s goals.
Notes:
1. The purpose of a task model is to provide a precise description of a task.
2. Task models should be written so users can understand and validate them.
3. A task model describes a task’s contextual preconditions, the steps needed to carry out
the task, and its intended outcomes, whereas as-is scenarios and use scenarios describe
how one or more tasks are carried out by a person.
4. Task models are created during analysis to describe current tasks. They are also created
or updated during design to describe intended tasks.
Example of task model:
Setting:
1. Interactive system: Ticket machine for public transport;
2. User: Person using public transport;
3. Task: Purchase a ticket to allow travel from the user’s current location to a specific
destination using public transport;
4. Precondition: The user has decided they need to be at a specific location at a specific
time and will use public transport to get there;
5. Goal (intended outcome): The user has purchased a suitable ticket.
Subtasks:
1. Identify the available modes of transport to the destination, for example bus or
underground.
2. Establish the departure time for each mode of transport, factoring in any transfers.
3. Establish the costs for each mode of transport.
4. Select the preferred mode of transport (based on departure time; duration; cost; any
preferences for specific modes of transport).
5. Pay for the ticket.
6. Take the ticket.
Observation A method for gathering contextual information relating to user needs in which an observer
watches users who carry out tasks that are related to the interactive system.
Notes:
1. The observer behaves unobtrusively except that they may ask an occasional clarifying
question.
2. If no interactive system is available, existing procedures can be observed.
3. Observation should take place in a context that is as natural as possible, for example at
the user’s workplace, their home or in a shop.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 21 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Interview A data-gathering method that questions a few carefully selected individuals in depth to
arrive at a fuller understanding of the context of use for an existing or planned interactive
system. Through inquiry and interpretation, it reveals commonalities and differences across
the user base.
Notes:
1. In an interview, the interviewer (a user experience professional) typically conducts a
briefing and then asks questions to a user about the current context of use and, if
applicable, about the planned interactive system. The interviewer uses an interview
checklist to ensure that all relevant topics are covered.
2. Interview questions should be
a. Open rather than closed;
b. Neutral rather than leading.
3. The main purpose of an interview is to gather information about users, goals, tasks,
resources and environments – that is, how things are currently done.
In an iterative cycle, a low-fidelity prototype based on data collected from users
through observation and interviews may be subsequently evaluated with users to
clarify the understanding of the context of use, user needs, user requirements and the
use scenario for the interactive system.
4. Interview participants may make valuable suggestions regarding the expected future
system – these can be documented separately and should be probed in subsequent
interviews to check their validity. They can also be communicated through as-is
scenarios as shown in example 2 in the definition of as-is scenario.
5. Where possible, interviews should be done contextually, however any interview is better
than no interview at all.
6. Successful interviewers
a. Use open questions and avoid closed questions;
b. Use neutral questions and avoid leading questions;
c. Don’t talk too much;
d. Use an interview checklist but remain flexible;
e. Prepare for the interview;
f. Remain curious;
g. Check their notes before the interview participant leaves so they never leave unsure
about what happened.
7. Compare this definition to contextual interview, pre-session interview and post-
session interview.
Contextual An interview that takes place at the location where the user’s interaction with the
interview interactive system usually takes place and focuses on the context of use of the user.
Interview A written list of suitable questions and cues used by the interviewer during an interview to
checklist make sure that all relevant topics are covered.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 22 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Master- A principle for a successful contextual interview: The interviewer treats the user as the
apprentice master while the interviewer is the apprentice. The goal of the master-apprentice model is to
model understand users’ goals and tasks in detail by learning them as an apprentice would.
Notes:
1. The interviewer asks because they sincerely want to learn – not because they want to
demonstrate their knowledge.
2. Everything the master says is correct. Sometimes the apprentice must ask several
questions in order to fully understand the master – the interviewer must never leave
unsure about what happened.
3. Typical mistakes include:
a. Interrupting the master;
b. Attempting to influence the master;
c. Doubting or even trying to correct the master;
d. Using the interview checklist to steer the interview rather than letting the master
address issues in the way they prefer.
Open question A question in an interview that does not give any indication of the expected format or
content of the answer.
Notes:
1. Open questions are desirable in interviews because they invite users to start talking and
provide extensive answers to questions.
2. Compare this to a closed question.
Examples:
1. For examples of open (and neutral) interview questions see Neutral question.
Closed An interview question that requires an answer from a predetermined set of alternatives, for
question example yes and no.
Notes:
1. Avoid several closed questions in sequence. They stop users talking because they sound
like a police interrogation.
2. Compare this to an open question.
Example:
1. Closed question: “Have you ever rented a car?”
A corresponding open question might be: “Please tell me about the last time you rented
a car.”
Neutral A question in an interview that has no built-in assumptions, and no frame that excludes
question anything or directs the reply in a certain direction.
Note:
1. Compare this to a leading question.
Examples of neutral (and open) interview questions:
1. “What happened?”
2. “What do you mean by that?”
3. “What possibilities do you have now?”
4. “What should the home page of the new car rental website look like?”

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 23 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Leading A question in an interview that signals a preference for certain possibilities, or attempts to
question direct the reply in a certain direction.
Note:
1. Compare this to a neutral question.
Examples of leading questions:
1. “Would you like to have the ability to categorise clients by their annual spend with your
company?”
2. “What advantages does the current car rental website offer for your choice of rental
car?”
Focus group A focused discussion where a moderator leads a group of participants through a set of
questions on specific topics.
Note:
1. Do not use focus groups for usability evaluation. Focus groups are about attitude and
opinion. In comparison, usability tests are about observing actual user behaviour.
As-is scenario A narrative text description of the procedure a specific user currently follows to complete
one or more tasks.
Notes:
1. The specific user in the scenario is often a persona.
2. As-is scenarios are created by a user experience professional based on results from
observation and contextual interviews.
3. As-is scenarios are a suitable basis for developing personas as thinking about users in
their current context of use involves thinking about what they want to do, and thinking
about activities involves thinking about who will be undertaking them.
4. As-is scenarios are reviewed by users to detect misunderstandings that may have
occurred during contextual interview.
Examples:
1. As-is scenario
“John Miller is a business traveller who often takes flights in the course of a week. He
prefers to take his car to the airport. But every now and then he misses a flight and then
regrets not having taken a taxi or tram to the airport. He simply underestimates the
queues at the front of the car park and the walking time to the gate.”
Compare this example to the corresponding example in use scenario.
2. Suggestions from interview participants may be added to the as-is scenario:
John Miller suggests: “It would be wonderful if I could just pre-order a parking spot and
skip the queues. If I find out that no parking spots are available, I could simply call a
taxi. This would allow me to plan my time better. They could also offer an express valet
service, where I would simply leave my car and my keys and they would park the car for
me – for a fee, of course.”

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 24 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Persona A description of a fictitious but realistic user and what they intend to do when using an
interactive system.
Notes:
1. Personas are not real people; they are realistic representations of users, constructed from
empirically determined data, for example from observations or interviews.
2. Personas typically have a name, age, some background, goals and aspirations. A persona
description should include information about the persona’s knowledge about and interest
in the subject matter of the interactive system. Including a photo in a persona
description helps to create the illusion of a real person.
Example of a persona for an app to remotely control locks in private homes:

Carol Becker, 55, Stoke-on-Trent (UK):

“It must be simple and trouble free”
Education: Primary school.
Occupation: Helps out at the local library.
Family status: Widowed. Two children (son and
daughter), both are married and live elsewhere with
their families.
Hobbies and interests: Cooking and gardening.
Carol Becker lives in a large, old house several miles
outside Stoke-on-Trent, which is south of Manchester.
Mrs. Becker has an old Windows computer. She uses it
for her extensive collection of cooking recipes and has
recently been using it to keep in touch with the family via e-mail. She refers to the
computer as “the beast” because it sometimes issues scary messages, which require a
lot of time and help from others to resolve.
Her children gave her a smartphone for Christmas. She currently uses it just to make
calls.
Mrs. Becker maintains her house well. Because her house is old, she often has
craftsmen visiting. Mrs. Becker is often away from home and she has problems
letting the craftsmen in when she’s not present.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 25 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
User journey A graphical or tabular description of all encounters users have with the interactive system
map covering all touchpoints that influence the user experience, making the overall user
experience tangible for others.
Notes:
1. Besides depicting as-is scenarios or use scenarios, user journey maps can be used as a
general communications medium to exemplify scenarios for stakeholders that extend
beyond the pure interaction, for example from the discovery of the product to the
purchase situation to the usage of the product.
2. User journey maps do not replace as-is scenarios or use scenarios.
3. User journey maps are graphs or tables that show the full user experience for users in
general. User journey maps can also show the user experience for a persona.
4. User journey maps are created during analysis to describe current encounters. They are
also created or updated during design to describe intended encounters.
Examples:
1. Examples of touchpoints:
a. The first contact with the interactive system: “How I heard about that new service.”
Also: Ads, quotes and sales staff that answer users’ pre-sales questions;
b. The direct task-oriented interaction, including support staff, bills, instruction manuals
and people who deliver products;
c. Telling others about my user experience, for example, writing a report to colleagues
about my experience with the new interactive system.
2. Example of tabular user journey map for the task “Make a trip using a rented car”:
User task Touchpoint
Looks for a car rental company Google, ad in magazine or newspaper,
billboard.
Calls to ask questions Customer support, local station.
Rents a car Website, customer support.
Picks up the car at the airport Signs showing directions to the rental desk;
Staff at the rental desk;
Transfer by shuttle to the pick-up location;
Staff at pick-up;
Condition of the car and equipment;
Adjusting and starting car.
Drives the car Operating the car and equipment;
Instruction manual;
Customer support, roadside service.
Returns the car Signs showing direction to return location;
Staff at the return location.
Receives and pays the bill Bill, debit transaction, customer support.
Reads emails Post-rental emails;
Solicited or unsolicited marketing emails.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 26 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

5. Specify the user requirements

LO # Learning Objective
5.1 Know what user needs are
5.2 Know the relationship and difference between a user need and a user requirement
5.3 Understand user requirement
5.4 Understand the difference between market, organisational and user requirements
5.5 Understand the difference between qualitative and quantitative user requirements

The purpose of “Specify the user requirements” is to define precise, determinable

user requirements that must be met by the interactive system before it is released. User
requirements are based on the user needs identified based on the results of the previous
activity, “Understand and specify the context of use”. User needs may not have been
explicitly formulated.
User profiles, personas, as-is scenarios and task models from the analysis of the
context of use are used to identify solution-independent user needs.
Qualitative or quantitative user requirements are derived from user needs. User
requirements must be verifiable so it is possible to determine in a usability evaluation
whether a prototype fulfils them or not.
The user requirements are also used to guide the design in order to ensure that the
interactive system meets user’s expectations as closely as possible.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 27 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
User need A prerequisite identified as necessary for a user, or a user group, to achieve a goal, implied
or stated within a specific context of use.
The purpose of user needs is to serve as a helpful intermediate step in the transformation of
the context of use information into comprehensive user requirements.
Notes:
1. A user need is independent of any proposed solution for that need. In other words, a user
need must not reference, for example, “the system” or “the website”.
2. User needs are identified based on various approaches including interviews with users,
observations, user surveys, usability evaluations, expert analysis, etc.
3. User needs often represent gaps (or discrepancies) between what is and what should be.
4. User needs are transformed into user requirements. User requirements are then
prioritised for implementation, taking the context of use, user priorities, trade-offs with
other requirements and constraints into consideration.
Examples of user needs:
1. During a presentation with a fixed time limit (context of use), a presenter (user) needs
to know how much time is left (prerequisite) in order to complete the presentation in
time (goal).
2. As part of monitoring the cash flow (context of use), an account manager (user) needs
to know the number of invoices received and their amounts (prerequisite), in order to
complete the daily accounting log (goal).
See also the examples in User requirement.
Requirement A condition or capability that must be met or possessed by an interactive system to satisfy
an agreement, standard, specification or other formally imposed documents
Notes:
1. A requirement should have a determinable condition that makes it possible to validate it.
2. This curriculum defines the following types of requirements:
a. Market requirement;
b. Organisational requirement;
c. User requirement.
3. This curriculum further distinguishes between the following types of user
requirements:
a. Qualitative user requirement;
b. Quantitative user requirement.
Market A requirement for an interactive system based on marketing policy aimed at maximizing
requirement business opportunities, purchase and use.
Examples:
1. The website must be at least as usable as that of the two top competitors.
2. The colours used on the website must conform to the style guide.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 28 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Organisation- An organisational rule that users have to follow when conducting their tasks.
al requirement
Note:
1. Organisational requirements are requirements on the users that lead to requirements
on the interactive system.
2. Organisational requirement may be based on regulatory requirements.
Examples:
1. A salesperson must have a written approval from the director for offers that exceed
100.000 Euros.
2. A support staff member must send a user of the interactive system a gift card with a
value of up to 50€ if the user has a reasonable complaint.
3. Organisational requirements based on regulatory requirements:
a. Users must confirm that they have read the terms and conditions before continuing.
b. Minors are explicitly told that they are not allowed to proceed past the front page of a
sports betting website.
User A requirement for use that provides the basis for design and evaluation of an interactive
requirement system to meet identified user needs.
Notes:
1. User requirements are derived from user needs.
2. A user requirement can be a
qualitative user requirement or a quantitative user requirement.
3. Both qualitative and quantitative user requirements provide a basis for the design of
the interactive system and can be verified by evaluating the interactive system. While
qualitative user requirements address the way in which the interactive system is used
to arrive at a user goal, quantitative user requirements set measurable goals for
usability and user experience.
Examples of relationships between user need and user requirement:
1. User need: Users who frequently rent cars from a car rental company need to know
what options they chose for previous reservations so they can apply them to future
reservations.
Corresponding user requirements:
a. Users must be able to select the types of cars they chose in previous reservations;
b. Users must be able to select the payment methods they used for previous reservations.
2. User need: During a disaster in a motorway tunnel, car drivers in the tunnel need to
avoid breathing poisonous gases in order to survive the disaster.
Corresponding user requirements:
a. Users must be able to recognise immediately that poisonous gases are present around
them as soon as they have been technically detected.
b. At any location in the tunnel, users must be able to detect how to get to the next
rescue room.
Corresponding organisational requirements:
c. The organisation operating the tunnel must ensure that rescue rooms are available at
regular intervals throughout the tunnel.
d. The air pressure in the rescue rooms must exceed the air pressure of the surroundings.
3. User need: During heart surgery, the anaesthetist needs to be aware of the patient’s vital
signs in order to keep them stable.
Corresponding user requirements:
a. Users must be able to monitor changes in the blood pressure during the operation.
b. At any time, users must see the heart activity of the patient.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 29 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Qualitative A statement of what users must be able to locate, recognise, understand, select or input as
user part of conducting a task with the interactive system to meet identified user needs in a
requirement specified context of use.
Note:
1. Qualitative user requirements are not features. They provide the basis for features.
Examples:
1. Reasonable qualitative user requirements:
a. “The user must be able to see the number of people and suitcases that can fit into the
cars available within a specific price range at the car rental website.”
b. “The user must be able to select a car with automatic transmission on the car rental
website.”
c. “The user must be able to see the opening hours of a specific car rental location.”
2. Incorrect qualitative user requirements:
a. “The user interface must be usable and support all user tasks” (too general).
b. “The user interface must have a big, red ‘Rent this car’ button” (too detailed, and
there is no user requirement, only a solution).
Quantitative A required level of usability to meet identified user needs expressed in terms of measures
user of effectiveness, efficiency, satisfaction, accessibility, user experience and avoidance of
requirement harm from use in a specified context of use.
Notes:
1. Quantitative user requirements are acceptance criteria for usability and user
experience, for example whether users can solve particular tasks with the interactive
system in an acceptable time or with a specified maximum number of use errors.
2. When defining suitable quantitative user requirements:
a. Look for guidance from existing systems – users will expect the new interactive
system to perform better than or at least as well as the existing system.
b. Consider quantitative user requirements set by stakeholders who have an interest in a
specific minimum performance of the interactive system.
c. Verify quantitative user requirements with users to determine whether or not they are
appropriate from their perspective.
Examples:
1. Measure of effectiveness: “95% of 25 users who have used the car rental website at least
twice within the past 6 months must be able to rent an economy size car at Frankfurt
Airport (Germany) for two days starting tomorrow at 09.00.”
2. Measure of efficiency: “80% of 25 users who have used the car rental website at least
twice within the past 6 months must be able to rent an economy size car at Frankfurt
Airport (Germany) for two days starting tomorrow at 09.00, within 5 minutes.”
3. Measure of satisfaction: “80% of 25 users who have used the car rental website at least
twice within the past 2 months must answer ‘Agree’ or ‘Strongly agree’ to the statement
‘I would recommend this website to a friend.’ ”
4. Measure of accessibility: “80% of 25 people using screen readers must be able to rent a
car as specified in example 2 within 10 minutes.”
5. Measure of user experience: “After using the interactive system for a month, 80% of 200
users must answer ‘Agree’ or ‘Strongly agree’ to the statement
‘I would recommend this product to a friend.’ ”.
6. Measure of avoidance of harm from use: “99% of 100 users who have booked a flight
must be fully aware of the dates they have selected, and of any additional costs.
7. Compare the above example to the examples in qualitative user requirement.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 30 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

6. Design: produce design solutions to meet user requirements

LO # Learning Objective
6.0.1 Understand what a use scenario is
6.0.2 Know what information architecture and navigation structure are
6.0.3 Know what card sorting is
6.0.4 Know what a storyboard is
6.0.5 Understand prototypes and wireframes
6.0.6 Know the difference between low-fidelity and high-fidelity prototypes
6.0.7 Know what user assistance is

The purpose of “Design: produce design solutions to meet user requirements” is to convert
user needs and user requirements into a working interactive system – that is, a design
solution. Deliverables from the analysis of the context of use, such as user groups,
as-is scenarios and personas are also used. The conversion considers dialogue
principles, heuristics, style guides and design concepts like affordance and mental
models as described in section 6.1. Design patterns are existing design solutions that have
been shown to work for users and can therefore be reused in the designs of new interactive
systems.
The approach is iterative as indicated by the following diagram:

EARLY DESIGN FIRST SKETCHES REFINED DESIGN

• Convert user needs and user • Wireframe • High-fidelity prototype

requirements into: • Low-fidelity prototype • Visual design
• Use scenarios • Information architecture • Style guide
• Storyboards • Navigation structure
• User journey maps

The approach is iterative. The hatched arrows indicate iterative cycles that are required
when a usability evaluation shows that user requirements have not yet been fully met.
Many iterations may be required before the interactive system meets the user
requirements.
Use scenarios, storyboards and user journey maps are cheap and fast methods of
describing how tasks could be accomplished with the intended interactive system. They tell
stakeholders how user needs could be met. Use scenarios are text-based; user journey
maps are graphic; storyboards are comic-book like depictions.
The primary purpose of a prototype is to serve as the basis for a usability evaluation, often
a usability test. The results from the usability evaluation guide the redesign and
refinement of the prototype. A secondary purpose of a prototype is to give stakeholders
and users an early impression of the design of the interactive system, in order to promote
constructive discussions.
CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 31 of 57
CPUX-F – Curriculum and Glossary – Version 3.15

Prototypes can be low-fidelity prototypes or high-fidelity prototypes containing varying

amounts of detail and interaction.
Low-fidelity prototypes are based on use scenarios and storyboards. They may look
sketchy. They are cheap to create and thus easy to discard if they don’t work. They may
include wireframes, which are screens that consist solely of straight lines, rectangles and
text. They may also include screens drawn on paper. In a usability evaluation of a paper-
based low-fidelity prototype, a human being replaces the computer.
The iterative process gradually refines low-fidelity prototypes into high-fidelity
prototypes, which in turn inform and steer a working interactive system that can be
released once it meets user requirements.
The information architecture and the navigation structure are developed in parallel with
the prototypes. From a human-centred point of view, the information architecture is the
naming and structuring of the information that is accessible to users. The navigation
structure is the logical organisation of the screens, pages and windows that comprise the
user interface – that is, the links and menus that enable users to get from one set of
information to another.
Card sorting can be used to create a human-centred navigation structure.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 32 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Use scenario A narrative text description that describes an intended usage situation with the interactive
system under development.
Notes:
1. The purpose of use scenarios is to provide a very early, tangible basis for discussions
about what the future interactive system could be like for the user, before prototypes
are constructed. Use scenarios are based on a deep understanding of the context of use,
user needs, user requirements as well as discussions with users and stakeholders.
2. The specific user in the use scenario is often a persona.
3. Use scenarios illustrate use of the interactive system in a real context. They can be
viewed as textual representations of the initial prototypes of a new interactive system.
They enable developers to understand processes and context.
4. A use scenario should avoid placing unnecessary constraints on the design by
referencing specific objects, such as command buttons, in the user interface.
Example of a use scenario:
1. “Before leaving for the airport, John Miller checks the availability at the airport car park
with his new application. If enough parking spaces are available, he reserves one with
his new application and then calmly drives to the airport. He knows that since the
application has been launched there is a separate entry for cars with reservations.”
Compare this example to the example in as-is scenario.
2. The following text is a bad example because it is too specific and violates note 5:
“John Miller looks at the ‘Overview of available parking spaces’ screen and selects one
by clicking the ‘Select’ button. He then clicks the ‘Reserve’-button and reserves the
parking space.”
Information The naming and structuring of the information that must be accessible to the user.
architecture
Note:
1. Examples of UX-related deliverables in the information architecture:
a. Data model from the user perspective; content and content hierarchy;
b. The words used in the user interface, for navigation and content;
c. Navigation structure, for example menu structure and site map.
Navigation The logical organisation of the units of displayed information that comprise the user
structure interface.
Notes:
1. In practice, the “units of displayed information” are often screens, pages or windows.
2. The navigation structure comprises:
a. The logical structure, for example hierarchy, the order and grouping of elements of
the user interface and navigation items.
b. The navigation elements that are used to navigate the structure, for example menus
and breadcrumbs.
3. The navigation structure is part of the information architecture.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 33 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Storyboard A sequence of visual frames illustrating the interplay between a user and an envisioned
interactive system.
Notes:
1. The purpose of a storyboard is similar to the purpose of a use scenario.
2. A storyboard is a comic book style representation of a use scenario.
3. Storyboards can also be used to illustrate a current user experience.
Example: Parking assistant, similar to example 1 in the definition of Use scenario

Before leaving for the airport, John MiIler

checks the availability at the airport car park
with his new app. He sees that parking spaces
are available, so he reserves a place to park…

… and then calmly drives to He knows that since

the airport with his car. the app has been
launched, there is a
separate entry for cars
with reservations.

John parks his car… … and arrives with plenty

of time to catch his flight.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 34 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Card sorting A method for structuring information – such as menus in a navigation structure – that
involves writing key concepts onto different cards and asking users to sort these cards into
groups.
Notes:
1. There are two methods of card sorting – open and closed:
a. During open card sorting, users are asked to sort the cards into groups that they feel
represent distinct domains of information.
b. With closed card sorting, the group names are pre-defined, usually by a prior round
of open card sorting, and users are asked to populate those groups with the cards.
2. After an open card sort, users are asked to name each group. If a majority of users
suggest the same name, use that name as the group title.
3. The groups provide important clues as to how human-centred menus could be structured
and named. The group titles may be used as menu titles.
4. If users ask about the meaning of a concept, explain it to them and ask, “what do you
call this concept?”
5. Encourage users to add additional concepts that are important to them during the card
sort. Have blank cards ready for this purpose.
6. If several users consider a concept superfluous or irrelevant, consider dropping it from
the menu.
7. Various tools are available to help you prepare, execute and analyse card sorting
sessions.
Prototype A representation of all or part of an interactive system that, although limited in some way,
can be used for analysis, design and usability evaluation.
Notes:
1. The key purposes of a prototype are
a. To facilitate early evaluation of the effectiveness and efficiency of an interactive
system at a time when it is still reasonably cheap to make fundamental changes to
information architecture and design.
b. To increase the interest of prospective users in the new interactive system based on
a concrete example. Users often find it easier to criticise something than to answer
the open question “What do you want?”.
c. To show stakeholders and colleagues a concrete example of what it is that you are
planning.
d. To serve as a specification for the implementation of the interactive system. This
particularly applies to high-fidelity prototypes.
2. This curriculum distinguishes between low-fidelity prototype and high-fidelity
prototype.
Wireframe A screen or page in a low-fidelity prototype for a graphical user interface comprised of
lines, rectangular boxes and text that represent the intended interaction design.
Note:
1. Wireframes typically do not address visual design and precise layout.
Low-fidelity A low-cost, simple illustration of a design or concept used to gather feedback from users
prototype and other stakeholders during the early stages of design.
Notes:
1. A low-fidelity prototype is often created using paper, pens, sticky notes and so on.
Screen mock-ups are often made using a prototyping tool.
2. A low-fidelity prototype may be operated by a human being instead of a computer.
3. A low-fidelity prototype should be capable of being updated in moments.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 35 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
High-fidelity A software prototype of the user interface to the interactive system that is being designed.
prototype A high-fidelity prototype more closely resembles the finished interactive system.
User Information to help a user to interact with an interactive system.
assistance
Notes:
1. User assistance can include describing the user interface, but it also focuses on how to
help the user to best apply the capabilities of the interactive system to their needs.
2. User assistance incorporates all forms of help available to a user, for example
a. User documentation: Written or other information for users about an interactive
system, how it works, and how to use it;
b. Online help: Assistance delivered through computer software that can be topic-
oriented, procedural or reference information;
c. System-initiated guidance: Unsolicited, explicit information about an event or a
condition from an interactive system to a user.
Examples of system-initiated guidance are:
a. Messages (informative, warning, error), for example “Your battery is almost empty.
Please connect your notebook to a charger”;
b. Status information, for example “You have 7 new messages”;
c. Instructions, for example “Separate e-mail addresses by a space, comma, semicolon or
line break.”

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 36 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

6.1. Dialogue principles and user interface guidelines

LO # Learning Objective
6.1.1 Understand the concept: dialogue principle
6.1.2 Know each of the seven dialogue principles
6.1.3 Know what a heuristic is
6.1.4 Understand the concept: affordance
6.1.5 Know what a mental model is
6.1.6 Understand the purpose of user interface guidelines and style guides
6.1.7 Understand the differences between dialogue principles and user interface guidelines
6.1.8 Know what a user interface element is
6.1.9 Know what a design pattern is

Dialogue principles and user interface guidelines are rules, of varying levels of specificity,
used to guide the design of the interaction (see section 6). They are intended to make the
interaction effective, efficient and satisfying, to avoid common usability problems and to
ensure a consistent user interface.
Dialogue principles and heuristics are general guidance for the design of usable
dialogues. There are seven dialogue principles; examples of dialogue principles are
conformity with user expectations and error tolerance. Dialogue principles are not
bound to any specific technology or method.
The concepts of affordance and mental model supplement the dialogue principles.
Affordance is an aspect of an object that makes it obvious how the object could be used. A
mental model is the perception people have of themselves and of the things with which they
interact.
User interface guidelines are low-level, specific rules or recommendations for user
interface design that leave little room for interpretation, allowing designers to implement
them consistently.
Style guides are collections of user interface guidelines; they are used to ensure
consistency in the appearance and behaviour of user interfaces across interactive
systems produced by the same organisation.
A user interface element is a discreet component of the user interface. User interface
elements include text, hyperlinks and command buttons.
A design pattern is a general solution to a commonly occurring problem within a given
context in software design. Examples of design patterns are log-in dialogues and check-out
process in a web shop.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 37 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Dialogue General goals for the design of useful and usable dialogues.
principles
Notes:
1. Dialogue principles are not bound to any specific technology or method.
2. ISO 9241-110 lists the following seven dialogue principles:
a. Suitability for the task;
b. Self-descriptiveness;
c. Conformity with user expectations;
d. Suitability for learning;
e. Controllability;
f. Error tolerance;
g. Suitability for individualisation.
3. Comparison of dialogue principle, heuristic and user interface guideline:
Concept Applicability
Dialogue principle General
Heuristic General, but more specific than a dialogue
principle
User interface Specific to a user interface platform, technology,
guideline application domain or organisation
Suitability for The property of an interactive system to support the user in the completion of the task –
the task that is, to base the functionality and the dialogue on the task characteristics (rather than the
technology chosen to perform the task).
Notes:
1. Examples of recommendations from ISO 9241-110 for observing the dialogue
principle:
a. The dialogue should present the user with information related to the successful
completion of the task.
b. The dialogue should avoid presenting the user with information not needed for the
successful completion of relevant tasks.
c. The format of input and output should be appropriate to the task. If typical input
values are required for a task, these values should be available to the user
automatically as defaults.
d. The steps required by the dialogue should be appropriate to the completion of the
task – that is, necessary steps should be included and unnecessary steps should be
avoided.
2. Suitability for the task is a dialogue principle.
Self- The property of a dialogue to, at any time, make it obvious to the users which dialogue they
descriptive- are in, where they are within the dialogue, which actions can be taken, and how they can be
ness performed.
Notes:
1. Clear and descriptive titles, breadcrumbs, appropriate feedback and progress indicators,
and affordances, including clear instructions, are means to make an interactive system
self-descriptive.
2. Self-descriptiveness is a dialogue principle.
Conformity Correspondence to predictable contextual needs of the user and to commonly accepted
with user conventions.
expectations
Notes:
1. Consistency is an aspect of Conformity with user expectations.
2. Compliance with style guides is a means to establish consistency.
3. Conformity with user expectations is a dialogue principle.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 38 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Suitability for A dialogue is suitable for learning when it supports and guides the user in learning to use the
learning interactive system.
Notes:
1. Examples of recommendations from ISO 9241-110 for observing the dialogue
principle:
a. The dialogue should provide sufficient feedback about the intermediary and final
results of an activity so that the user learns from successfully accomplished activities.
b. If appropriate to the tasks and learning goals, the interactive system should allow
the user to explore (“try out”) dialogue steps without negative consequences.
2. Suitability for learning is a dialogue principle.
Example of suitability for learning:
1. When a user downloads a new app, very often it will have a step-by-step guide on how
to use some of the key features. Initially, the guide will display a short explanation of a
feature. On pressing ‘next’ it will explain the next feature, and so on.
Control- The ability of a user to initiate and control the direction and pace of the interaction until the
lability point at which the goal has been met.
Notes:
1. Properly placed and labelled exit-buttons (“Cancel”, “Skip” or “Stop”), undo and redo
are means to make an interactive system controllable.
2. Controllability is a dialogue principle.
Error The property of a dialogue to achieve the intended result with either no, or minimal,
tolerance corrective action by the user despite evident errors in input.
Note:
1. Error tolerance is a dialogue principle.
Examples of error tolerance:
1. When an error occurs, the interactive system should provide a precise and
comprehensible explanation. The explanation must also be constructive – that is, it must
suggest a solution to the problem.
2. If severe consequences could result from a user action, the interactive system should
provide explanation and request confirmation from the user before carrying out the
action.
Suitability for The property of a dialogue that allows users to modify interactions and the presentation of
individualisati information to suit their individual capabilities and needs.
on
Note:
1. Suitability for individualisation is a dialogue principle.
Example:
1. A news app lets users individualise which news topics or content they want to see, for
example, they can choose to see technology news but not sports or entertainment news.
It also lets users adjust certain characteristics of the user interface, for example, text
size and contrast.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 39 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Consistency The same information is presented in the same way throughout the interactive system, in
accordance with the user’s expectation.
Notes:
1. Consistency is an aspect of Conformity with user expectations.
2. Consistency is relevant on several levels, for example;
a. Within a screen;
b. Across screens in the same interactive system;
c. Across interactive systems from the same manufacturer;
d. Across similar interactive systems from different manufacturers.
Heuristic A generally recognised rule of thumb that helps to achieve usability.
Note:
1. For a comparison of dialogue principle, heuristic and user interface guideline, see
dialogue principle, note 3.
Examples of generally recognised heuristics:
1. Speak the users’ language (related to the dialogue principle, conformity with user
expectations).
2. Follow platform conventions (related to the dialogue principle, conformity with user
expectations.
3. Minimise the user’s memory load by making objects, actions, and options visible
(related to the dialogue principle, suitability for the task).
4. Visibility of system status (related to the dialogue principle, self-descriptiveness).
5. Help users recognise, diagnose, and recover from errors (related to the dialogue
principle, error tolerance).
Affordance An aspect of an object that makes it obvious how the object could be used.
Examples of affordances:
1. A handle on a teapot or teacup provides an obvious affordance for holding.
2. A command button on a web page provides an affordance for clicking.
3. The “swipe to delete” design pattern has no affordance at all.
Mental model The perception people have of themselves, others, the environment, and the things with
which they interact.
Notes:
1. Alternative, popular definition: A person’s thought process about how something works
in the real world.
2. People form mental models through experience, training and instruction. The mental
model of an interactive system is formed largely by interpreting its perceived actions
and its visible structure. Expectations resulting from the use of other or similar systems
are also of importance.
3. If a user’s mental model of an interactive system is incomplete or contradictory, then
the user cannot easily use the interactive system.
Example:
1. For a word processing system, a user’s mental model may be that all changes to a
document are saved instantly. An alternative mental model is that changes are saved
only when the user selects “Save”. The two mental models make a difference for the
user’s actions if the word processing system crashes.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 40 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
User interface A low-level, specific rule or recommendation for user interface design that leaves little
guideline room for interpretation, allowing designers to implement it consistently.
Notes:
1. Collections of user interface guidelines are called style guides.
2. For a comparison of dialogue principle, heuristic and user interface guideline, see
dialogue principle, note 3.
Examples of user interface guidelines:
1. For all controls, such as radio buttons, select the safest, most secure value by default to
prevent loss of data or system access. If safety and security aren’t factors, select the
most likely or convenient value.
2. The company logo must appear in the upper left corner of each page. Its position must
be exactly the same as on the home page. Clicking the logo must cause the home page to
be displayed.
3. The height of a command button must be 23 pixels.
Style guide A collection of user interface guidelines used to ensure consistency in the appearance and
behaviour of user interfaces across interactive systems produced by the same organisation
Note:
1. Many organisations have a style guide to ensure the consistency of their corporate
design, for example how to use and how not to use the logo, corporate colours and
standard layouts for print and advertising.
Examples of style guides:
1. Windows User Experience Interaction Guidelines for Windows Desktop apps
(“UX Guide”)
2. IOS Human Interface Guidelines
User interface A basic component of a user interface that is presented to the user by the interactive
element system.
Note:
1. User interface elements are the basis for creating the functions that users need in order
to complete tasks with the interactive system.
2. User interface elements may or may not be interactive
Examples:
1. Common examples of user interface elements include paragraphs of text, hyperlinks,
push buttons, radio buttons, check boxes and tool tips.
2. A single word in a paragraph of text or the words on a push button are not user interface
elements.
3. A log-in window, consisting of some text, two input boxes (for user name and
password), and a log-in push button, is not a user interface element; it is composed of
several user interface elements.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 41 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Design A solution to a commonly occurring design problem within a given context of use, that
pattern describes the design problem, a general solution, and examples of how to apply it.
Notes;
1. A single user interface element to solve a certain design problem can be considered a
design pattern, for example a tab.
2. Design patterns must comply with relevant user interface guidelines.
Examples:
1. Accordions, tabs
Solve the design problem “The interactive system has more data to display than can fit
in the available screen area.”
2. Wizards
Solve the design problem “Novice users need a complicated procedure explained in
small, easy-to-digest steps.”
3. Frequently asked questions (FAQ)
Solve the design problem “Users may have one of many questions concerning an
interactive system.”

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 42 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

7. Evaluate the design against user requirements

7.1. Usability tests

LO # Learning Objective
7.1.1 Understand usability evaluation
7.1.2 Understand the role of usability evaluation in human-centred design
7.1.3 Understand the key differences between usability tests, usability inspections and user
surveys
7.1.4 Understand why interviews and focus groups are unsuitable for usability evaluation
7.1.5 Understand usability test and the main activities in a usability test
7.1.6 Know what a remote usability test and an unmoderated usability test are
7.1.7 Know how a usability test is prepared
7.1.8 Know what a usability test plan and a usability test script are
7.1.9 Understand usability test task
7.1.10 Know how usability test participants are recruited
7.1.11 Understand the activities in a usability test session: Briefing, pre-session interview,
moderation and post-session interview
7.1.12 Know what a usability lab is
7.1.13 Know what usability evaluation reports and usability test reports are
7.1.14 Understand usability findings
7.1.15 Know the importance of positive usability findings
7.1.16 Know the ratings used for usability findings
7.1.17 Understand the responsibilities in a usability test: Moderator, note-taker, observer and
usability test participant

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 43 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

The purpose of a usability evaluation is to determine whether or not an interactive

system, or a prototype of an interactive system, meets the user requirements and
applicable dialogue principles, heuristics and user interface guidelines.
This curriculum addresses three forms of usability evaluation: usability test, usability
inspection and user survey. In usability tests and user surveys, users are involved in the
usability evaluation, while usability inspections are carried out solely by user experience
professionals.
A usability test shows what representative users are able to accomplish with the
interactive system when they carry out representative tasks. Eliciting personal opinions
from users, or discussing them, is not part of a usability test.
The main activities in a usability test are shown in the diagram below:

PREPARE FOR THE USABILITY CONDUCT THE USABILITY TEST REPORT THE RESULTS
TEST SESSIONS

• Write a usability test plan • Briefing • Write the usability test report
• Write the usability test script • Pre-session interview • Communicate the usability
• Include usability test tasks • Solve usability test tasks findings
• Recruit test participants • Post-session interview

The first activity in a usability test is to write the usability test plan. This describes the
purpose of the usability test and provides cost and time estimates.
The usability test script contains the usability test tasks and checklists for the briefing
and interviews that are part of each usability test session.
The preparation of the usability test also includes recruiting usability test participants –
these are representative users of the interactive system.
A usability test typically consists of 4 to 25 usability test sessions. In each usability test
session, a usability test participant carries out specific, representative usability test
tasks with the interactive system.
The moderator starts the usability test session by briefing the usability test participant
about what will happen during the session. The moderator then conducts a pre-session
interview with the usability test participant to learn about their background and knowledge
of the interactive system they will be testing. The moderator quietly observes the usability
test participant, who is encouraged to think aloud as they solve usability test tasks. A
note-taker documents successes and failures. Stakeholders often observe usability test
sessions to see for themselves how the interactive system is performing. Finally, the
moderator conducts a brief post-session interview with the usability test participant to
understand their overall impressions of the interactive system.

After all usability test sessions have been completed, the results are analysed and
documented. A usability test report is written which describes the usability findings from
the usability test. The usability test report contains both usability problems and positive
usability findings.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 44 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Usability A process through which information about the usability of an interactive system is
evaluation gathered in order to improve the interactive system (known as formative usability
evaluation) or to assess the merit or worth of an interactive system (known as summative
usability evaluation).
Note:
1. Usability evaluation is a common term for
a. Usability test;
b. User survey;
c. Usability inspection.
Usability test A usability evaluation that involves representative users performing specific tasks with the
interactive system to enable identification and analysis of usability problems, or the
measurement of effectiveness, efficiency, and user satisfaction.
Notes:
1. A usability test usually has three phases:
a. Planning – this includes writing the usability test plan, writing the usability test
script and recruiting suitable usability test participants;
b. Conducting usability test sessions as described in note 2;
c. Communicating usability findings – this includes writing the usability test report.
2. A usability test consists of a number of usability test sessions. In each session, a
usability test participant attempts to carry out representative usability test tasks using
the interactive system or a prototype of the interactive system.
3. Moderators often encourage usability test participants to think aloud during a
usability test session, because they need to understand the thought processes of the
usability test participants. Such qualitative usability tests are sometimes referred to as
“think aloud tests”.
4. The usability test participant and the moderator are usually in the same physical
location during a usability test. During a remote usability test the usability test
participant and the moderator are in different locations. During an unmoderated
usability test there is no moderator.
5. Usability tests may occur at any time during the human-centred design process, from
early analysis through interactive system delivery and beyond. Usability tests may be
based on paper sketches or display mock-ups, as well as on interactive systems under
design and completed interactive systems.
6. Usability test sessions are conducted by a moderator and viewed by a number of
observers – these are often stakeholders. A note-taker records important usability
findings.
Remote A usability test where the usability test participant and the moderator are in different
usability test physical locations.
Notes:
1. The moderator observes the usability test participant using an internet connection.
2. The moderator communicates with the usability test participant over the telephone or
via an internet connection.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 45 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Unmoderated A usability test where usability test participants solve usability test tasks without a
usability test moderator.
Notes:
1. The usability test participant’s actions are usually video recorded for later analysis.
2. Unmoderated usability tests are usually conducted on the usability test participant’s
computer. The usability test session is recorded using specialist software installed on
the computer. After each usability test session, the software sends the video recording
to the client for analysis.
3. An unmoderated usability test is sometimes called an unmoderated remote usability test.
Usability test A brief description of the purpose and extent of a usability test.
plan
Notes:
1. The usability test plan is intended for management to decide whether the usability test
should be conducted or not. It is deliberately brief and focuses on the resources required
for the usability test.
2. The usability test plan includes:
a. The goal of the usability test;
b. The number of planned usability test participants;
c. The approximate length of each usability test session;
d. The name of the moderator;
e. A time plan.
3. The usability test plan may also include a cost estimate for the usability test including
person hours.
4. Further details about the usability test such as usability test tasks, test method and
required software and hardware are provided in the usability test script.
Usability test A checklist used by a moderator in a usability test to keep track of briefing and pre-
script session interview questions, usability test tasks, and post-session interview questions.
Usability test A description of a task that a moderator asks a usability test participant to carry out
task during a usability test.
Examples of usability test tasks for a car rental website:
1. What would you do if you needed to speak to someone about renting a car?
2. Please rent a car that suits your needs and is in a price range that you’d normally
consider. You can choose the location you pick it up from and the amount of time you
hire it for.
3. Please rent a small car from London Heathrow Airport, from 9.00 tomorrow morning.
You’ll need to return the car 4 days later, to the same location, at midday.
4. Please could you cancel the reservation that you made earlier.
Examples of invalid usability test tasks:
1. Tell me what you think of the home page (opinion).
2. Stroll around on the website for 5 minutes and tell me what you think (hazy, opinion).
3. Are the rental conditions agreeable? (does not address usability).
Recruiting A process for selecting candidates that have the appropriate characteristics to participate in a
human-centred activity such as a focus group, contextual interview, or usability test.
Notes:
1. A recruitment screener is often used to determine whether candidates have the
appropriate characteristics to participate in the human-centred activity. It consists of a
series of questions for prospective participants to identify whether they represent the
intended users
2. Relevant characteristics might include: Personal and professional background,
knowledge of the subject matter, attitudes and interests.
CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 46 of 57
CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Usability test A part of a usability test where one usability test participant carries out representative
session usability test tasks using the interactive system or a prototype of the interactive system.
Note:
1. In a usability test session, the moderator typically:
a. Greets the usability test participant;
b. Conducts the briefing and pre-session interview;
c. Hands out usability test tasks to the usability test participant;
d. Quietly observes the usability test participant while they carry out usability test
tasks;
e. Conducts the post-session interview.
Usability test A representative user who carries out usability test tasks in a usability test session.
participant
Briefing The first activity in an interview or a usability test session where the usability test
participant is informed about the purpose of the interview or usability test and what their
role and contribution will be.
Pre-session An activity in a usability test session where the usability test participant answers
interview questions about their background and previous experience with the interactive system and
related interactive systems.
Note:
1. The pre-session interview takes place after the briefing but before the usability test
participant starts carrying out usability test tasks.
Post-session An activity in a usability test session where the usability test participant answers
interview questions about their user experience and general impression of the interactive system.
Notes:
1. The post-session interview takes place after the usability test participant has carried
out as many usability test tasks as time allows.
2. The opinions that surface during the post-session interview can help the moderator in
understanding causes for usability problems, rating usability problems and
understanding what the usability test participant liked.
Usability lab Two or more rooms that are specially equipped for usability tests or focus groups.
Note:
1. A usability lab often consists of
a. a test room where the usability test participant sits;
b. an observation room where stakeholders can watch usability test participants as
they solve usability test tasks.
The two rooms are usually separated by a one-way mirror which enables observers to
watch usability test sessions without usability test participants being aware.
Usability A document reporting the results of a usability test, a usability inspection or a user survey.
evaluation
Note:
report
1. The usability evaluation report for a usability test is usually referred to as a usability
test report.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 47 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Usability test A document that describes the results of a usability test.
report
Notes:
1. A usability test report typically contains:
a. An executive summary;
b. 5-50 usability findings (including positive usability findings);
c. The usability test script used for the usability test;
d. Screenshots or pictures that supplement the description of important usability
findings.
2. A usability test report is always required. A basic usability test report may consist of 3-5
pages or slides:
a. A 1-page executive summary;
b. 1-2 pages communicating the 5-6 most important usability findings;
c. 1-2 pages detailing the usability test tasks.
Usability A result from a usability evaluation.
finding
Note:
1. A usability finding can describe:
a. A usability problem;
b. Something that users liked – that is, a positive usability finding.
2. Reporting positive usability findings ensures that
a. Teams are aware of aspects of the interactive system that currently work well, so that
they are not unintentionally changed.
b. Features that usability test participants liked are not removed simply because the
development team was not aware that test participants appreciated them.
c. A more positive attitude is adopted towards the usability test report and the
usability evaluation in general.
Usability A difficulty in using the user interface that affects the ability of the user to achieve their
problem goals effectively, or efficiently, or with satisfaction.
Note:
1. Usability problems can lead to confusion, error, delay, or outright failure to complete a
task.
Examples of usability problems are:
1. Search is not error tolerant.
For example, a city search for “brigton” (instead of “brighton”) provides no results.
2. A car rental website uses terms that users don’t understand, for example CDW
(Collision Damage Waiver), and the website provides no explanation of the terms.
3. A website has complicated rules for new passwords.
4. A loud video starts playing the moment a user lands on a web page.
5. A virus scan of a disc takes several hours. The anti-virus program offers no way of
pausing or stopping the scan.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 48 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Rating A measure given to a usability finding from a usability test to indicate the impact and
criticality on the user experience and the consequences.
Notes:
1. Usability findings are rated from the usability test participants’ point of view.
Sometimes, the ratings are done in cooperation with a domain expert.
2. Typical ratings are:
a. Positive finding;
b. Minor problem;
c. Major problem;
d. Critical problem;
e. Catastrophic problem – existential threat (life-threatening problem).
Examples:
1. Inability to book a flight, or booking a wrong, expensive, non-refundable flight due to
poor usability are critical usability problems.
2. Renting a car with an inadequate liability insurance, or administering a lethal dose of
medication due to poor usability are catastrophic usability problems.
Moderator A neutral person who conducts a usability test session or a focus group session.
Notes:
1. The moderator’s tasks during a usability test session are described under usability test
session.
2. Facilitator is a frequently used synonym for moderator.
Moderation The activity carried out by a moderator in a usability test or focus group.
Note-taker A user experience professional who makes notes of usability findings during a usability
test session, focus group or interview.
Notes:
1. Note-taking can be handled by the moderator in order to keep costs down.
2. The use of an additional note-taker allows the moderator to concentrate fully on the
usability test participant.
Observer A person who watches users in an observation, usability test session or focus group.
Note:
1. Observers do not interfere with the usability activity. Observers may be actively
involved in the analysis of the results.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 49 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

7.2. Other evaluation methods

LO # Learning Objective
7.2.1 Know what a usability inspection is
7.2.2 Know what a heuristic evaluation is
7.2.3 Know what a user survey is
7.2.4 Know what a questionnaire is, in particular its fields of application and the need for it to be
usable

Usability inspection is a form of usability evaluation. It is based on the judgment of one or

more evaluators who examine or use an interactive system to identify potential usability
problems, and deviations from established dialogue principles, heuristics, user interface
guidelines and user requirements. The evaluators base their evaluation on their
experience as user experience professionals or as users of the interactive system that is
being evaluated.
A heuristic evaluation is a specific form of a usability inspection that is guided by a list of
approximately 10 heuristics.
User surveys evaluate users’ satisfaction with an interactive system. In a user survey,
users report subjective data into a questionnaire based on their experience of using an
interactive system. The usability of a questionnaire is important; for example, the
questions in the questionnaire must be easy to understand and the questionnaire must
keep users informed of their progress.
User surveys are also used to gather context of use information as part of understanding
the context of use.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 50 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Usability A usability evaluation based on the judgment of one or more evaluators who examine or
inspection use an interactive system to identify potential usability problems and deviations from
established dialogue principles, heuristics, user interface guidelines and user
requirements.
Notes:
1. Usability inspection is often performed by user experience professionals or subject
matter experts, who base their judgement on prior experience of usability problems
encountered by users and their own knowledge of user interface guidelines and style
guides.
2. Unlike usability tests, usability inspections do not involve users, except where a user
adopts the role of evaluator.
3. Heuristic evaluation is a usability inspection method.
Heuristic A usability inspection in which one or more evaluators compare an interactive system to a
evaluation list of heuristics and identify where the interactive system does not follow those heuristics.
Notes:
1. The list of heuristics must be manageable. Usually about 10 heuristics are used.
2. Evaluators can be user experience professionals or subject matter experts (“single
experts”), or both (“double experts”).
User survey A usability evaluation where users are asked to report subjective data into a questionnaire
based on their experience of using an interactive system.
Notes:
1. User surveys can be used to evaluate users’ satisfaction with an interactive system and
to gather information on the context of use.
2. User surveys should be developed in accordance with the human-centred design
process outlined in Figure 1.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 51 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Term Definition
Questionnaire A set of questions that is used to collect data from users, often in a user survey.
Notes:
1. Two important uses of questionnaires in human-centred design are:
a. To understand the context of use. Questions are about the users’ experience with the
current interactive system and their expectations for the intended interactive
system. Questions are answered in text form.
b. To evaluate the user experience before, during and after the use of an interactive
system.
2. Questionnaires must be usable. They must adhere to dialogue principles, for example:
a. Each question must contribute significantly to the purpose of the questionnaire;
b. Questions must be easy to understand;
c. The questionnaire must keep users informed of their progress.
3. As with any product, testing the questionnaire for clarity with representative users
before launch should be considered essential.
4. This definition applies to both digital and paper questionnaires.
Examples of questions to understand context of use:
1. “When did you last use the car rental website? What was your business? How did it
go?”
2. “What do you expect from a car rental website?”
Examples of questions to evaluate satisfaction:
1. On a scale from 1 to 5, where 1 means ‘strongly disagree’, 3 means ‘neutral’, and
5 means ‘strongly agree’, please rate the following statements:
a. The new car rental website looks cool.
b. The new car rental website is easy to use.
c. The new car rental website lets me rent cars quickly.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 52 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Informative Appendix A. Model course for preparatory training

This appendix describes a model course that teaches the entire curriculum in 2 days.
The structure of the model course is not mandatory; trainers are free to organise their CPUX-
F course in any way they consider optimal. The length of the course is not mandatory either;
trainers may organise courses based on students’ expectations and prior knowledge lasting
for example 3 days, 1 day or even 3 hours.

A.1. Day 1
Basic concepts, section 2
- Show a few examples of certification questions so students have an idea of what they are
studying for and how the test will be conducted. We recommend that examples of certification
questions are presented throughout the course.

Exercise for Basic concepts:

- Simple examples of user interfaces that illustrate basic characteristics of usability
▪ Effective and less effective
▪ Efficient and less efficient
▪ Satisfying and less satisfying
▪ Accessible and less accessible
Plan the human-centred design process, section 3

Analysis: understand and specify the context of use, section 4

Exercises for Understand and specify the context of use:

- Interview
▪ The trainer selects a suitable interactive system.
▪ Students conduct an interview to understand the context of use for the chosen interactive
system. One student is the interviewee, another student is the interviewer. The other
students take notes.
▪ Students discuss important insight gained from the interview.
▪ Students discuss interview mistakes, for example missing questions and leading questions.
- Context of use description
▪ Students brainstorm users, tasks, resources and environment for the system.
▪ Students compare their suggestions to context of use information provided by the trainer for
the system.

Specify the user requirements, section 5

Exercise for Specify the user requirements:

- Derive user requirements from user needs
▪ The trainer provides a list of user needs for the interactive system.
▪ Students derive user requirements from the user needs.
▪ Students present and discuss the user requirements.
CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 53 of 57
CPUX-F – Curriculum and Glossary – Version 3.15

A.2. Day 2

Preparatory exercise for Dialogue principles and user interface guidelines:

- Evaluate a user interface
The purpose of the exercise is to establish a common understanding of the user interface of the
website, which can be used as a source for specific examples of usability problems to illustrate
the dialogue principles
▪ Students walk through a given user interface, for example a car rental website, and use
common sense to find usability problems

Dialogue principles and user interface guidelines, section 6.1

Design: produce design solutions to meet user requirements, section 6

Exercise for Design: produce design solutions to meet user requirements:

- Students create a low-fidelity-prototype of the interactive system which was analysed in the
exercises on day 1.

Evaluation in general and usability test, section 7.1

Exercise for Usability test:

- Conduct a usability test session of a public website, for example ryanair.com or
theguardian.com. The trainer moderates the test session. A student is the test participant.

Other evaluation methods, section 7.2

Exercises for Other evaluation methods:

- Students review a page from a website containing usability problems that can be found with
heuristic evaluation.
- Students comment on a questionnaire provided by the trainer
Summary exercise:
- Example of certification test: Students have 20 minutes to answer 15 sample certification
questions which they haven’t seen before. Subsequently, the trainer reveals and discusses the
answers. The goal is to familiarise students with the conditions for the certification test, and the
style and concepts used in the test.

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 54 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Informative Appendix B. Important changes to this document

Date, Version Changes compared to version 2.10, 10-04-2014

23-03-2018, v3.15 Added learning objectives throughout the document.

Added compact summaries of each activity at the start of each section.
Removed the following definitions:
1. Intuitive;
2. Task object;
3. Usability engineer, user requirements engineer, information architect, interaction
designer, user interface designer. Parts of these definitions have been moved to the
definition of User experience professional;
4. Role;
5. Direct user;
6. Stakeholder requirement;
7. Recruitment screener (the screener is still mentioned in Recruiting);
8. Quality;
9. User documentation, online help, system-initiated guidance. Parts of these
definitions have been moved to the definition of User assistance.
Deleted the table “Responsibility of roles for key deliverables.”
Added the following definitions:
1. Agile development;
2. Lean UX;
3. Usability maturity;
4. User experience professional;
5. Plan the human-centred design process;
6. User experience project plan;
7. Human-centred quality objectives;
8. User interface element;
9. Card sorting;
10. User journey map.
Major changes to the following definitions:
- Scenario split into as-is scenario and use scenario.
- Effectiveness, efficiency, satisfaction – updates reflect new ISO 9241-011 standard.
Added index

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 55 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Index

Accessibility, 13 Human-centered design Maturity. See Usability Rating, 49

Affordance, 40 activities, 6 maturity Recruiting, 46
Agile development, 7 Human-centered quality Mental model, 40 Regulatory requirement,
As-is scenario, 24 objectives, 15 Moderation, 49 29
Moderator, 49 Remote usability test, 45
Briefing, 47 Incomplete (maturity Report. See Usability test
level), 8 Navigation structure, 33 report
Card sorting, 35 Indirect user, 19 Need. See User need Requirement, 28
Checklist for interview, Individualization. See Neutral question, 23 Market, 28
22 Suitability for Note-taker, 49 Organization, 29
Closed question, 23 individualization Qualitative user, 30
Conditions. See Information architecture, Observation, 21 Quantitative user, 30
Environment 33 Observer, 49 Regulatory, 29
Conformity with user Innovating (maturity Open question, 23 User, 29
expectations, 38 level), 8 Organizational Resource, 21
Consistency, 40 Inspection. See Usability requirement, 29
Context of use, 18 inspection Satisfaction, 11
Contextual interview, 22 Interactive system, 13 Pattern. See Design Scenario
Controllability, 39 Interface. See User pattern As-is scenario, 24
interface Performed (maturity Usescenario, 33
Design pattern, 42 Interface element. See level), 8 Secondary user, 19
Dialogue, 13 User interface element Persona, 25 Self-descriptiveness, 38
Dialogue principle, 38 Interface guideline. See Post-session interview, 47 Social conditions, 20
Dissatisfaction, 11 User interface Pre-session interview, 47 Sprint, 7
guideline Primary user, 19 Stakeholder, 20
Effectiveness, 10 Interview, 22 Problem. See Usability Storyboard, 34
Efficiency, 10 Checklist, 22 problem Style guide, 41
Environment, 20 Contextual, 22 Project plan. See User Subtask. See Task
Error tolerance, 39 Post-session, 47 experience project Suitability for
Evaluation. See Usability Pre-session, 47 plan individualization, 39
evaluation ISO 9241, 13 Prototype, 35 Suitability for learning,
Iterative, 7 High-fidelity, 36 39
Finding. See Usability Low-fidelity, 35 Suitability for the task, 38
finding Journey map. See User Summative usability
Focus group, 24 journey map Qualitative user evaluation, 45
Formative usability requirement, 30 Survey. See User survey
evaluation, 45 Leading question, 24 Quality objectives. See
Lean UX, 7 Human-centered Task, 20
Goal, 13 Learning. See Suitability quality objectives Task model, 21
Guideline. See User for learning Quantitative user Technical conditions, 20
interface guideline Learning objective, 3 requirement, 30 Test. See Usability test
Low-fidelity prototype, Question Test participant. See
Heuristic, 40 35 Closed, 23 Usability test
Heuristic evaluation, 51 Leading, 24 participant
High-fidelity prototype, Managed (maturity level), Neutral, 23 Test plan. See Usability
36 8 Open, 23 test plan
Human-centered design, Market requirement, 28 Questionnaire, 52 Test report. See Usability
7 Master-apprentice model, test report
23

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 56 of 57

CPUX-F – Curriculum and Glossary – Version 3.15

Test script. See Usability Usability finding, 48 Usability test task, 46 User interface, 13
test script Usability inspection, 51 Use scenario, 33 User interface element,
Test session. See Usability lab, 47 User, 19 41
Usability test session Usability maturity, 8 Indirect, 19 User interface guideline,
Test task. See Usability Usability problem, 48 Primary, 19 41
test task Usability test, 45 Secondary, 19 User journey map, 26
Touchpoint, 26 Remote, 45 User assistance, 36 User need, 28
Unmoderated, 46 User experience, 12 User requirement, 29
Unmoderated usability Usability test participant, User experience User survey, 51
test, 46 47 professional, 14 UX. See User experience
Usability, 10 Usability test plan, 46 User experience project
Usability evaluation, 45 Usability test report, 48 plan, 15 Wireframe, 35
Usability evaluation Usability test script, 46 User group, 20
report, 47 Usability test session, 47 User group profile, 20

CPUX-F – Curriculum and Glossary Copyright 2018, UXQB e.V. Page 57 of 57