UCD Glossary - Revision history

Perempuangimbal at 12:49, 10 January 2021

2021-01-10T12:49:40Z

Perempuangimbal at 11:51, 10 January 2021

2021-01-10T11:51:48Z

Perempuangimbal at 14:10, 27 December 2020

2020-12-27T14:10:40Z

KristinaG: Protected "UCD Glossary" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

2020-12-22T09:39:05Z

Protected "UCD Glossary" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

Perempuangimbal at 18:10, 16 December 2020

2020-12-16T18:10:24Z

Perempuangimbal at 17:15, 16 December 2020

2020-12-16T17:15:08Z

Perempuangimbal at 16:50, 16 December 2020

2020-12-16T16:50:31Z

Perempuangimbal at 16:00, 16 December 2020

2020-12-16T16:00:58Z

Perempuangimbal at 15:46, 16 December 2020

2020-12-16T15:46:58Z

Perempuangimbal at 15:44, 16 December 2020

2020-12-16T15:44:55Z

@@ Line 1: / Line 1: @@
-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.
+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.
-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.
+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|Lean UX]], [[#Market Requirement|Market Requirement]], [[#Organizational Requirement|Organizational Requirement]], [[#Persona|Persona]], [[#Qualitative User Requirement|Qualitative User Requirement]], [[#Quantitative User Requirement|Quantitative User Requirement]], [[#Requirement|Requirement]], [[#Stakeholder Requirement|Stakeholder Requirement]], [[#User Group|User Group]], [[#User Need|User Need]], [[#User Requirement|User Requirement]], [[#User Role|User Role]], [[#User Want|User Want]].
 == Lean UX ==
@@ Line 89: / Line 91: @@
 ===== 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.
+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 ==
@@ Line 166: / Line 168: @@
 #:*[[#Qualitative User Requirement|Qualitative user requirement]], and
 #:*[[#Quantitative User Requirement|Quantitative user requirement]]
 ==Stakeholder Requirement==
@@ Line 199: / Line 200: @@
 =====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. On our initial process in the User Research phase, we were encounter 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 that have a certain level of curiosity towards data, technology, and have an innovation temper.
+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==
@@ Line 219: / Line 220: @@
 =====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 why we made it is because the product (the SAMS monitoring system), as in “The Solution” was already made. We found it hard for us to focus on the real “User Need” while putting aside the solution already generated temporarily.
+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==
@@ Line 244: / Line 245: @@
 ===Form of Documentation===
 '''User Role Map'''
 Example: Training app for Ethiopian runners<ref>(Bastian Walthierer, Bachelor Thesis 2014, Conception and prototypic implementation of a user optimised application to support Ethiopian runners)</ref>
 * '''Data Collector:''' An athlete or coach collecting data during work out.
 * '''Data Analyst:''' An athlete or coach who analyses collected data.
@@ Line 264: / Line 265: @@
 # 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.
 ==References==
 <references/>

@@ Line 166: / Line 166: @@
 #:*[[#Qualitative User Requirement|Qualitative user requirement]], and
 #:*[[#Quantitative User Requirement|Quantitative user requirement]]
 ==References==
 <references/>

@@ Line 4: / Line 4: @@
 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|Product Backlog]], [[#Qualitative User Requirement|Qualitative User Requirement]], [[#Quantitative User Requirement|Quantitative User Requirement]], [[#Requirement|Requirement]], [[#Stakeholder Requirement|Stakeholder Requirement]], [[#User Group|User Group]], [[#User Need|User Need]], [[#User Requirement|User Requirement]], [[#User Role|User Role]], [[#User Want|User Want]].
+[[#Lean UX|Lean UX]], [[#Market Requirement|Market Requirement]], [[#Organizational Requirement|Organizational Requirement]], [[#Persona|Persona]], [[#Qualitative User Requirement|Qualitative User Requirement]], [[#Quantitative User Requirement|Quantitative User Requirement]], [[#Requirement|Requirement]], [[#Stakeholder Requirement|Stakeholder Requirement]], [[#User Group|User Group]], [[#User Need|User Need]], [[#User Requirement|User Requirement]], [[#User Role|User Role]], [[#User Want|User Want]].
 == Lean UX ==
@@ Line 23: / Line 23: @@
 == 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.''
+''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:'''
@@ Line 90: / Line 90: @@
 ===== 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 ==
@@ Line 137: / Line 132: @@
 '''Notes:'''
-#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.
+#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.
 #The elements of a quantitative user requirement
 #:*The stakeholder who issued the requirement (e.g. employer or legislator)
@@ Line 152: / Line 147: @@
 ====Example in SAMS context====
 % 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.

@@ Line 89: / Line 89: @@
 ===== 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.
+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.
 == Product Backlog ==

@@ Line 102: / Line 102: @@
 '''Notes'''
-* 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.
+# 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.
-* Qualitative user requirements are not features. They provide the basis for features.
+# Qualitative user requirements are not features. They provide the basis for features.
-* For each qualitative [[#user requirement|user requirement]], it must be possible to trace it back to the underlying user needs and corresponding context of use information (“Traceability”).
+# For each qualitative [[#user requirement|user requirement]], it must be possible to trace it back to the underlying user needs and corresponding context of use information (“Traceability”).
-* Qualitative user requirements are specified with the aid of the following elements:
+# Qualitative user requirements are specified with the aid of the following elements:
-*#[[#User Group|User group]]
+#:*[[#User Group|User group]]
-*#Type of usage (recognise, select, input)
+#:*Type of usage (recognise, select, input)
-*#Special condition(s) of the context of use for which the [[#user requirement|User Requirement]] is relevant
+#:*Special condition(s) of the context of use for which the [[#user requirement|User Requirement]] is relevant
-* Sources of qualitative user requirements
+# Sources of qualitative user requirements
-*#The direct source is always one or more user needs.
+#:*The direct source is always one or more user needs.
-*#Indirect sources:
+#:*Indirect sources:
-*#*Human-centred quality objectives
+#:**Human-centred quality objectives
-*#*Legal/regulatory requirements
+#:**Legal/regulatory requirements
-*#*Market requirements
+#:**Market requirements
-*#*Organisational requirements
+#:**Organisational requirements
-*#*Requests
+#:**Requests
-*#*Identified or anticipated problems with usage
+#:**Identified or anticipated problems with usage
-*#*Dialogue principles and heuristics that are used for the specification of user requirements
+#:**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)
 {| class="wikitable"
 |-
-! 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)
+! User Group !! Context of Use !! Task (Describing the present situation without the future system) !! [[#User Need|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)
 |}

← Older revision	Revision as of 09:39, 22 December 2020
(No difference)

@@ Line 84: / Line 84: @@
 ==== 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 ===
+===== 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.

@@ Line 7: / Line 7: @@
 == Lean UX ==
-===== Why lean UX for SAMS =====
+==== 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 ====
+=== 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))
@@ Line 22: / Line 22: @@
 == Market Requirement ==
-===== Definition =====
+=== 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.''
@@ Line 28: / Line 28: @@
 Market requirements are often referred to as customer requirements.
-===== Example in SAMS context =====
+==== Example in SAMS context ====
 . “The advisory support system must be at least as usable as those of the two strongest competitors”
@@ Line 34: / Line 34: @@
 == Organizational Requirement ==
-===== Definition =====
+=== Definition ===
 ''An organisational rule that users have to follow when performing their tasks.''
@@ Line 42: / Line 42: @@
 # 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 =====
+==== Example in SAMS context ====
 The decision support system must provide all measurement values in metric units in order to meet EU regulations.
@@ Line 58: / Line 58: @@
 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 =====
+=== Definition ===
 ''A description of a user and what he or she intends to do when using an '''interactive system'''.''
-(https://uxqb.org/en/documents/)
+(uxqb.org)
 '''Notes of CPUX-UR Curriculum (uxqb.org):'''
@@ Line 81: / Line 81: @@
 # 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)
+=== Indonesia ===