UCD Glossary

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

Some of the terms in the UCD Glossary were enriched with examples in SAMS context. These stories show how the SAMS team uses the terms and methodologies 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.

Other than providing definitions and example in SAMS context, this glossary also including more terms to show the SAMS team's work philosophy. Those terms incorporated here are Innovation, Usability Evaluation, and Hardware Adaption.

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 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. 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 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

Stakeholder Requirement

Definition

What the interactive system should be capable of from the point of view of the stakeholders.

Notes:

1. Stakeholder requirements can be classified as follows:

   • Legal / regulatory requirements (stakeholder is “Legislator”)
   • Market requirements (stakeholder is “Purchaser / Purchase decision maker”)
   • Organisational requirements (stakeholder is “Management of the organisation”)
   • Functional requirements (stakeholder is “indirect user”, i.e. a user of the work products that were created by the direct user using the interactive system)
   • User requirements
     • qualitative: (stakeholder is “direct user”)
     • quantitative: (stakeholder is from one or more of the stakeholder groups mentioned above)

2. Stakeholder requirements from one category can lead to further stakeholder requirements in other categories.
3. Requirements for the interactive system are formulated so as to implement the stakeholder requirements. (see system requirements)
4. The degree to which stakeholder requirements are implemented determines the human-centered quality of the interactive system.

User Group

Definition for User Centered Design (UCD)

A collection of users with the same or similar personal characteristics and context of use related to the interactive system.

Divergent Definition

A users’ group(also user’s groupor user group) is a type of club focused on the use of a particular technology, usually (but not always) computer-related.

Important: Be careful not to confuse “user Group” with user role or persona

Example in SAMS context

Ethiopia

As it mentioned at the Persona section, identifying the User group for SAMS technology was challenging. The user groups were first identified with site selection exercise. In Ethiopian context, it was mandatory that users from different regions need to be considered (especially when a government institution is a key partner in the project implementation). This will make the culture, language and category of the user group difficult to reach within the time frame, and that extends some of the time frame we originally planned. But with close discussion with our Ethiopian partners (Holeta), we managed to identify sites and user groups that are appropriate for SAMS technology.

Indonesia

As referring to the term 'user' itself, the 'user group' is a collection of users who share similar characteristics, needs, and problems. One of the purposes of User Research is identifying the suitable User Group. In our initial process in the User Research phase, we encountered difficulties in identifying relevant user groups for SAMS technology. But along the way, as the project progressed to give us some time to explore and meet more types of beekeepers, we finally find/recognized certain kinds of beekeepers that might suitable for our target User Group. They are beekeepers with a certain level of curiosity towards data, technology, and an innovation temper.

User Need

Definition

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.

Notes:

1. A user need is independent of any proposed solution for that need. In other words, a user need must not refer for example to “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 should be and what is.
4. User needs are transformed into user requirements which take into account the context of use, user priorities, and interaction with other system requirements and constraints.
5. User needs are different from user wants. User needs can be transformed into user requirements, whereas user wants are transformed into market requirements.
6. User needs can be divided into resource needs, informational needs and competency needs.
7. Every component of the context of use (user, task, resources, physical environment, social environment) can be a source for user needs.

Example in SAMS context

Ethiopia

While we are doing our in-depth interviews, user research and documentation of the insights, the level of our users' experience with any technology wasn’t close to the estimated experience that is expected by the research planning phase. On our first user research phase, we have identified for some of our targeted user groups that it was their first time to use any digital technology products. And It was challenging to capture the user needs in a conclusive manner for our next UCD phases. Most of the users' needs identified in the research cannot be directly addressed with a digital solution (e.g. financial support). On follow up plans we needed to do continuous interviews with a small number of user groups to get into the bottom of the user needs that can be addressed by SAMS agendas.

Indonesia

After the "User Research" phase (in-depth interview and shadowing methods), lately, we use to summarize the research findings into several "user needs". But when we first did this process with the SAMS Project back then two years ago in 2018, we made lots of biases in generating the "User Needs". One of the reasons we made it is that the product (the SAMS monitoring system), as in "The Solution" was already made. We found it hard to focus on the real "User Need" while putting aside the solution already generated temporarily.

User Requirement

The International Usability and UX Qualification Board (UXQB) distinguishes between:

• qualitative user requirement, and
• quantitative user requirement

Definition of Qualitative User Requirements

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.

Definition of Quantitative User Requirements

Required level of usability to meet identified user needs expressed in terms of effectiveness, efficiency and user satisfaction in a specified context of use.

User Role

User Role is a term that has it’s origin in software development and is therefore strongly related to the (future) interactive system. The International Usability and UX Qualification board does not define it.

User roles are extremely helpful for prototyping to identify, which views are needed for the human machine interfaces. A user can take different user roles. For example if I as a person add data to a system, I am in the role of a data provider, if I seek information in a system I am in the role of an information retriever etc.

Definition

1. A user role is an abstract collection of needs, interests, expectations, behaviors, and responsibilities characterizing a relationship between a class or kind of users and a system

Users are of interest to developers, not as people, but because of the roles they will play in relationship with the system to be designed and built.

1. While each user comes to your software with a different background and with different goals, it is still possible to aggregate individual users and think of them in terms of user roles. A user role is a collection of defining attributes that characterize a population of users and their intended interactions with the system.

Form of Documentation

User Role Map

Example of User Map Role

Example: Training app for Ethiopian runners

• Data Collector: An athlete or coach collecting data during work out.
• Data Analyst: An athlete or coach who analyses collected data.
• Information Seeker: An athlete or coach who seeks and retrieves information (eg. about training methods or nutrition) from the system.
• Information Provider: An athlete, coach or expert who provides data for the system.
• Community Member: An athlete or coach who is member of a social running community.
• Data Maintainer: An expert, responsible to verify and maintain correctness, actuality and completeness of all data and information.
• Interpreter: A specialist who translates the system into Amharic or other local languages.

User Want

Definition

A desire regarding the design of an interactive system that is stated by a user.

Notes:

1. User wants can be collected in the context of use analysis. It is important for the acceptance of solutions that user wants are taken into account in the form of solution proposals, together with the user requirements for which the user wants are possible solutions. Nevertheless, user wants must not be the starting point when developing a solution.
2. User wants are often formulated as requests (e.g. “I want a steak”). In contrast, user needs describe what a user needs (e.g. “a regulated protein balance”).
3. The (subjective) user want is defined in contrast to the (objective) user need from the context of use.
4. User wants are often stated by users in contextual interviews, whereas user needs are typically implicit and only found by the user requirements engineer through analysis of the context of use information and problem descriptions.

SAMS Work Philosophy

Innovation

Ethiopia

Some of the innovative approaches (e.g to identify why some of the model beekeepers perform better than others) which identified in our in-depth interviews. Yet, the process of capturing innovation management not yet in place.

Indonesia

Innovation refers to a new idea, an approach of problem-solving that offers novelty in method and device. Beekeepers in West Java have been conducting this act of innovation, such as applying queen filter and pollen trap in their beehives, different beekeepers also develop their beekeeping methods.

Usability Evaluation

Ethiopia

The user interaction test happened with our target groups with observation of our UCD team. The usability evaluation conducted with the SAMS evaluation metrics. In addition, we also look at the time frame (e.g how long the user spends in a certain window), and general impressions with the prototype provided. Open questions about their experience are also evaluated based on their own use of words.

Indonesia

After an interface for the DSS was prototyped, a testing activity was planned. The primary outcome for this activity is to know how understandable or complicated the user interface designed. Five beekeepers from a various location across West Java tested the prototype, and a lot of feedback received for improvements. An application called Lookback is used to conduct online Usability Testing due to the pandemic situation in Indonesia.

Hardware Adaption

Ethiopia

We support the SAMS technology on locally material sourcing that will accelerate hardware availability and adaptation. And the initial phase of hardware deployment managed to push data to our central server, yet it hasn’t been tasted even with potential early adaptors.

Indonesia

One of the consequences we are dealing in fostering UCD approach on this project was when it came to product development. It will need to follow the User Requirements in the local context. Users from Indonesia might have a different specific requirement from Ethiopia or Europe. These differences resulted in the "different details" of feature or parts of the SAMS HIVE monitoring system in each county. During the project time, Indonesian team make adaptations in the SAMS HIVE monitoring systems' hardware. Some transformation included using different sensors following the locally available materials, and processing minicomputer that offers a lower price.