UCD Glossary

Within the SAMS project, a UCD Glossary was developed to make sure that the project team has the same understanding of UCD terminologies. The glossary of UCD terms was first created as one of the strategies to achieve effective teamwork within the international UCD group, considering different background knowledge, understanding, and way of working. It was important for the UCD team to have the same understanding and definition of each term used in the working process; and from time to time in the research and reporting process, the UCD team in each country referred to the UCD Glossary in order to make sure that the research process is still following the agreed methodologies.

In order to make the UCD collaborative process more understandable, Some of the terms in the UCD Glossary was enriched with stories on how the terms and methodologies were used within the SAMS project.

These are several terms that are being used during the SAMS project timeline: Lean UX, Market Requirement, Organizational Requirement, Persona, Qualitative User Requirement, Quantitative User Requirement, Requirement, Stakeholder Requirement, User Group, User Need, User Requirement, User Role, User Want.

Lean UX

Why lean UX for SAMS

The SAMS team has professional experience in all components of lean UX. All partners have adapted the lean startup practice of rapid prototyping. This opens up the opportunity to create a common understanding of the SAMS product development strategy very fast and use methods for research, prototyping and documentation that are already known and established.

Definition

A keyword used to describe an approach for a human-centred design that is based on a combination of different approaches (agile development, design thinking, lean startup) and tries to integrate principles and methods for usability and user experience into agile development, thereby achieving economic advantages from a cost-benefit perspective. ( CPUX-UR – Curriculum (Version 1.3, June 2016))

Notes of CPUX-UR Curriculum (uxqb.org):

1. The user requirements engineer must know about Lean UX so as to be able to communicate with members of a Lean UX project in a professional way.
2. Agile development processes are the basis for Lean UX, as the iterative approach in teams and the realisation of small, well-defined packages makes it possible for small and quick tests to be regularly carried out. The results from tests are then directly used in the next iteration (called “sprint”) for further development. See also SCRUM.
3. Design thinking is the basis for Lean UX, as it helps project members to incorporate the users’ perspective into the development process through its solution-oriented way of thinking based on an in-depth understanding of the problem context.
4. Lean startup is the basis for Lean UX, as it suggests that at first, everything is a hypothesis and consequently needs to be validated. The team learns through experiments about the user and the market. Failure is part of the learning process – not every hypothesis is validated, not every experiment provides the desired results.

Market Requirement

Definition

A requirement for an interactive system based on the marketing policy of the supplier aimed at maximizing business opportunities, purchase and use of the interactive system.

Note: Market requirements are often referred to as customer requirements.

Example in SAMS context

1. “The advisory support system must be at least as usable as those of the two strongest competitors”

(CPUX-UR – Curriculum (Version 1.3, June 2016))

Organizational Requirement

Definition

An organisational rule that users have to follow when performing their tasks.

Notes:

1. Organisational requirements are often requirements for the users that originate from requirements for the interactive system or that lead to requirements for the interactive system.
2. Organisational requirements formulate rules about how users are to perform their tasks, e.g. “The radiological assistant must keep an eye on the patient while adjusting the patient table.”
3. In practice, the term “business requirement” is sometimes used. While business requirements provide the rationale for why an interactive system is to be created or purchased for the organisation, organisational requirements are requirements that have to be implemented within the project and are relevant for the operation of the interactive system.

Example in SAMS context

The Decision Support System must provide all measurement values in metric units in order to meet EU regulations.

(CPUX-UR – Curriculum (Version 1.3, June 2016))

Persona

Remark:

Persona as a term is used in many ways, sometimes it refers to the description of a real person, especially if this person is very relevant as a user for the future system. Sometimes it refers to fiction, constructed user description that was developed out of a context of use analysis involving many real persons. Sometimes the term “real persona” is used in opposite to “abstract or fictive persona”.

For SAMS, part of our context of use analysis is, to describe real beekeepers and other potential users of future SAMS software and hardware. This description is then used to create personas that describe the user for the implementations.

Please Note:

In the strict definition of the International Usability and UX Qualification Board (uxqb) a Persona is never a real person. So be aware of this fact when speaking to an expert familiar with these definitions to avoid misunderstandings.

Definition

A description of a user and what he or she intends to do when using an interactive system. (uxqb.org)

Notes of CPUX-UR Curriculum (uxqb.org):

1. Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.
2. Personas typically have a name, age, some background information, goals and desires. A persona description should include information about the persona’s knowledge about and interest in the subject matter of the interactive system. Persona descriptions often but not always include a photo.
3. Personas provide a “face” for the users so that all project members have a good idea of who the users of the interactive system will be, which characteristics they have, what motivates them and what goals they have.
4. There are primary and secondary personas. Primary personas represent the main target user groups, whereas secondary personas provide insight into further goals or characteristics that are also relevant for the derivation of user requirements but would overload the descriptions of primary personas.
5. Personas based on assumptions are called proto-personas. Lean UX uses proto-personas. They can be used as a starting point for a model-based context of use analysis.
6. So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.

Quality factors for the development of personas:

1. A persona is created by those people who performed the context of use analysis.
2. The persona description does not represent a real person but is equivalent to the description of a real person.
3. The persona combines characteristics of real users.
4. The persona description contains all important characteristics and the most important goals.
5. The basis for a persona must be empirical data, it must not be purely imaginary.
6. Proto-personas must be clearly labelled as such.
7. The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.
8. Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.
9. The responsibility for the creation, quality and maintenance of personas lies with the product team, even if the personas were initially created by others (e.g. an agency). It must be assured that all Context of Use information on which the creation and maintenance of personas are based remains available to the product team.

(uxqb.org)

Example in SAMS context

Ethiopia

In the UCD process, one of the first challenges was to identify user groups in the Ethiopian context. The beekeepers are early stage. At the first Persona creation experience, we didn’t consider all the necessary parameters of the persona we produced adequately. We later iterate the exercise with close work with UCD experts in SAMS.

Indonesia

In the SAMS Project, we made personas for the first time after we did our first round of user research (with an in-depth interview and shadowing methods). At that time, we misunderstand how to generate a persona and make one out of a real person. But then after a discussion with the International team through the weekly UCD call meeting, we understand that persona is not a real person. Instead, a persona should describe a “typical” of a user that can help us understand more about what kind of a solution we should offer to fulfil his/her needs.

Qualitative User Requirement

Definition

A statement of what users must be able to locate, recognize, understand, select or input as part of performing a task with the interactive system. (CPUX-UR – Curriculum (Version 1.3, June 2016))

Notes

1. Qualitative user requirements are the basis for efficient use of the interactive system. In contrast, quantitative user requirements can enable the efficiency of the interactive system to be measured – that is, whether users can solve particular tasks with the interactive system, e.g. in an acceptable time or with a specified maximum number of user errors.
2. Qualitative user requirements are not features. They provide the basis for features.
3. For each qualitative user requirement, it must be possible to trace it back to the underlying user needs and corresponding context of use information (“Traceability”).
4. Qualitative user requirements are specified with the aid of the following elements:

   • User group
   • Type of usage (recognise, select, input)
   • Special condition(s) of the context of use for which the User Requirement is relevant

5. Sources of qualitative user requirements

   • The direct source is always one or more user needs.
   • Indirect sources:
     • Human-centred quality objectives
     • Legal/regulatory requirements
     • Market requirements
     • Organisational requirements
     • Requests
     • Identified or anticipated problems with usage
     • Dialogue principles and heuristics that are used for the specification of user requirements

(CPUX-UR – Curriculum (Version 1.3, June 2016))

Example in SAMS Context

(User Storie Format) As a Beekeeper, I want to see the recommended date of my next honey harvest so that I can avoid disturbing the bees unnecessarily. (from UN005)

User Group	Context of Use	Task (Describing the present situation without the future system)	User Need (In the scope of the future system – independent of the technical solution)
Beekeeper	In order to know if there is enough honey to have a profitable harvest, the beekeeper needs to open the hive regularly. Every time he opens the hive, the bees are disturbed. The beekeeper is in danger to get stings.	(T001) Open the hive to see if there is enough honey in the hive to harvest.	(UN005) The beekeeper needs information about the best time of harvest. (from T001)

Quantitative User Requirement

Definition

Required level of usability to meet identified user needs to be expressed in terms of effectiveness, efficiency and user satisfaction in a specified context of use. (CPUX-UR – Curriculum (Version 1.3, June 2016))

Notes:

1. Quantitative user requirements are acceptance criteria for the effectiveness, efficiency and user satisfaction of the interactive system, for example, whether users can solve a particular task with the system in an acceptable time or with a specified maximum number of use errors.
2. The elements of a quantitative user requirement

   • The stakeholder who issued the requirement (e.g. employer or legislator)
   • User group(s) concerned who have to fulfil the requirement during use
   • The number or percentage of users who have to fulfil the requirement
   • Object of use (task object (in the user interface), tool)
   • Quantities (e.g. maximum available time, error rate, precision)
   • Special condition(s) of the context of use under which the use takes place

3. Sources of quantitative user requirements

   • Quantitative user needs in the context of use (e.g. “The patient must close his/her eye within 60 seconds in order to have enough moisture on the retina.”)
   • Stakeholders who define acceptance criteria for the usability of an interactive system (e.g. for a usability test)

(CPUX-UR – Curriculum (Version 1.3, June 2016))

Example in SAMS context

90% of all Beekeepers who have used the advisory support system at least twice must be able to find information about the beehive temperature in 30 seconds.

Requirement

Definition

"Requirement" is a widely used technical term, in context with product and process development, Wikipedia delivers the following definition:
In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary (or sometimes desired) function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholders. Requirements can come with different levels of specificity; for example, a requirement specification or requirement “spec” (often imprecisely referred to as “the” spec/specs, but there are actually different sorts of specifications) refers to an explicit, highly objective/clear (and often quantitative) requirement (or sometimes, set of requirements) to be satisfied by a material, design, product, or service.

The International Usability and UX Qualification Board (UXQB) uses a definition that is focused on interactive systems: 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 glossary defines the following other types of requirements:

   • Stakeholder requirement
   • Market requirement
   • Organisational requirement
   • User requirement

3. This glossary further distinguishes between

   • Qualitative user requirement, and
   • Quantitative user requirement