View source for 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|Lean UX]], [[#Market Requirement|Market Requirement]], [[#Organizational Requirement|Organizational Requirement]], [[#Persona|Persona]], Product Backlog, 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):

# 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.
# 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.
# 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.
# 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|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:'''
# 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.
# 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.”
# In practice, the term “business [[#requirement|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):'''
# Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.
# 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.
# 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.
# 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.
# Personas based on assumptions are called proto-personas. [[#Lean UX|Lean UX]] uses proto-personas. They can be used as a starting point for a model-based context of use analysis.
# 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:'''

# A persona is created by those people who performed the context of use analysis.
# The persona description does not represent a real person but is equivalent to the description of a real person.
# The persona combines characteristics of real users.
# The persona description contains all important characteristics and the most important goals.
# The basis for a persona must be empirical data, it must not be purely imaginary.
# Proto-personas must be clearly labelled as such.
# The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.
# Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.
# 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. Rather, 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.