https://wiki.sams-project.eu/api.php?action=feedcontributions&feedformat=atom&user=Perempuangimbal 2026-11-04T08:30:47Z User contributions MediaWiki 1.31.7 https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2978 2021-01-10T12:49:40Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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]].<br /> <br /> Other than providing definitions and example in SAMS context, this glossary also including more terms to show the [[#SAMS Work Philosophy|SAMS team's work philosophy]]. Those terms incorporated here are [[#Innovation|Innovation]], [[#Usability Evaluation|Usability Evaluation]], and [[#Hardware Adaption|Hardware Adaption]].<br /> <br /> == Lean UX ==<br /> ==== Why lean UX for SAMS ====<br /> 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.<br /> <br /> === Definition ===<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> === Definition ===<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ==== Example in SAMS context ====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> === Definition ===<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ==== Example in SAMS context ====<br /> The [[Decision Support System]] must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> <br /> 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.<br /> <br /> === Definition ===<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (uxqb.org)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> (uxqb.org)<br /> <br /> ==== Example in SAMS context ====<br /> <br /> ===== Ethiopia =====<br /> 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.<br /> <br /> ===== Indonesia =====<br /> 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 &quot;typical&quot; of a user that can help us understand more about a solution we should offer to fulfil his/her needs.<br /> <br /> == Qualitative User Requirement ==<br /> === Definition ===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes'''<br /> # 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.<br /> # Qualitative user requirements are not features. They provide the basis for features.<br /> # 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”).<br /> # Qualitative user requirements are specified with the aid of the following elements:<br /> #:*[[#User Group|User group]]<br /> #:*Type of usage (recognise, select, input)<br /> #:*Special condition(s) of the context of use for which the [[#user requirement|User Requirement]] is relevant<br /> # Sources of qualitative user requirements<br /> #:*The direct source is always one or more user needs.<br /> #:*Indirect sources:<br /> #:**Human-centred quality objectives<br /> #:**Legal/regulatory requirements<br /> #:**Market requirements<br /> #:**Organisational requirements<br /> #:**Requests<br /> #:**Identified or anticipated problems with usage<br /> #:**Dialogue principles and heuristics that are used for the specification of user requirements<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ==== Example in SAMS Context ====<br /> (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)<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! 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)<br /> |-<br /> | 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)<br /> |}<br /> <br /> == Quantitative User Requirement ==<br /> ===Definition===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes:'''<br /> #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.<br /> #The elements of a quantitative user requirement<br /> #:*The stakeholder who issued the requirement (e.g. employer or legislator)<br /> #:*User group(s) concerned who have to fulfil the requirement during use<br /> #:*The number or percentage of users who have to fulfil the requirement<br /> #:*Object of use (task object (in the user interface), tool)<br /> #:*Quantities (e.g. maximum available time, error rate, precision)<br /> #:*Special condition(s) of the context of use under which the use takes place<br /> #Sources of quantitative user requirements<br /> #:*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.”)<br /> #:*Stakeholders who define acceptance criteria for the usability of an interactive system (e.g. for a usability test)<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ====Example in SAMS context====<br /> 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.<br /> <br /> ==Requirement==<br /> ===Definition===<br /> &quot;Requirement&quot; is a widely used technical term, in context with product and process development, Wikipedia delivers the following definition:&lt;br&gt;<br /> ''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.''&lt;ref&gt;https://en.wikipedia.org/wiki/Requirement&lt;/ref&gt;<br /> <br /> The International Usability and UX Qualification Board (UXQB) uses a definition that is focused on interactive systems:<br /> ''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.''<br /> <br /> '''Notes:'''<br /> # A requirement should have a determinable condition that makes it possible to validate it.<br /> # This glossary defines the following other types of requirements:<br /> #:*[[#Stakeholder Requirement|Stakeholder requirement]]<br /> #:*[[#Market Requirement|Market requirement]]<br /> #:*[[#Organisational Requirement|Organisational requirement]]<br /> #:*[[#User Requirement|User requirement]]<br /> # This glossary further distinguishes between<br /> #:*[[#Qualitative User Requirement|Qualitative user requirement]], and<br /> #:*[[#Quantitative User Requirement|Quantitative user requirement]]<br /> <br /> ==Stakeholder Requirement==<br /> ===Definition===<br /> ''What the interactive system should be capable of from the point of view of the stakeholders.''<br /> <br /> '''Notes:'''<br /> # Stakeholder requirements can be classified as follows:<br /> #:*Legal / regulatory requirements (stakeholder is “Legislator”)<br /> #:*Market requirements (stakeholder is “Purchaser / Purchase decision maker”)<br /> #:*Organisational requirements (stakeholder is “Management of the organisation”)<br /> #:*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)<br /> #:*User requirements<br /> #:**qualitative: (stakeholder is “direct user”)<br /> #:**quantitative: (stakeholder is from one or more of the stakeholder groups mentioned above)<br /> # Stakeholder requirements from one category can lead to further stakeholder requirements in other categories.<br /> # Requirements for the interactive system are formulated so as to implement the stakeholder requirements. (see system requirements)<br /> # The degree to which stakeholder requirements are implemented determines the human-centered quality of the interactive system.<br /> <br /> ==User Group==<br /> ===Definition for User Centered Design (UCD)===<br /> ''A collection of users with the same or similar personal characteristics and context of use related to the interactive system.&lt;ref&gt;uxqb.org&lt;/ref&gt;''<br /> <br /> ===Divergent Definition===<br /> ''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.&lt;ref&gt;https://en.wikipedia.org/wiki/Users%27_group&lt;/ref&gt;''<br /> <br /> '''Important: Be careful not to confuse “user Group” with [[#User Role|user role]] or [[#Persona|persona]]'''<br /> <br /> ====Example in SAMS context====<br /> =====Ethiopia=====<br /> As it mentioned at the [[#Persona|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.<br /> <br /> =====Indonesia=====<br /> 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. <br /> <br /> ==User Need==<br /> ===Definition===<br /> ''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.''<br /> <br /> '''Notes:'''<br /> # '''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”.<br /> # User needs are identified based on various approaches including interviews with users, observations, user surveys, usability evaluations, expert analysis, etc.<br /> # User needs often represent gaps (or discrepancies) between what should be and what is.<br /> # '''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.<br /> # User needs are different from user wants. User needs can be transformed into user requirements, whereas user wants are transformed into market requirements.<br /> # User needs can be divided into resource needs, informational needs and competency needs.<br /> # Every component of the context of use (user, task, resources, physical environment, social environment) can be a source for user needs.<br /> <br /> ====Example in SAMS context====<br /> =====Ethiopia=====<br /> 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.<br /> <br /> =====Indonesia=====<br /> After the &quot;User Research&quot; phase (in-depth interview and shadowing methods), lately, we use to summarize the research findings into several &quot;user needs&quot;. 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 &quot;User Needs&quot;. One of the reasons we made it is that the product (the SAMS monitoring system), as in &quot;The Solution&quot; was already made. We found it hard to focus on the real &quot;User Need&quot; while putting aside the solution already generated temporarily. <br /> <br /> ==User Requirement==<br /> The International Usability and UX Qualification Board (UXQB) distinguishes between:<br /> *[[#Qualitative User Requirement|qualitative user requirement]], and<br /> *[[#Quantitative User Requirement|quantitative user requirement]]<br /> <br /> ===Definition of Qualitative User Requirements===<br /> ''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.''<br /> <br /> ===Definition of Quantitative User Requirements===<br /> ''Required level of usability to meet identified user needs expressed in terms of effectiveness, efficiency and user satisfaction in a specified context of use.''<br /> <br /> ==User Role==<br /> 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.<br /> <br /> 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.<br /> <br /> ===Definition===<br /> # ''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<br /> 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.''&lt;ref&gt;[Constantine, Larry L.. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design (Kindle-Positionen1928-1929). Pearson Education. Kindle-Version.]&lt;/ref&gt;<br /> # ''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.'''''&lt;ref&gt;[Cohn, Mike. User Stories Applied: For Agile Software Development (Adobe Reader) (Addison-Wesley Signature Series (Beck)) (Kindle-Position892). Pearson Education. Kindle-Version.]&lt;/ref&gt;<br /> <br /> ===Form of Documentation===<br /> '''User Role Map'''<br /> [[File:User role model2.png|thumb|Example of User Map Role]]<br /> Example: Training app for Ethiopian runners&lt;ref&gt;(Bastian Walthierer, Bachelor Thesis 2014, Conception and prototypic implementation of a user optimised application to support Ethiopian runners)&lt;/ref&gt;<br /> * '''Data Collector:''' An athlete or coach collecting data during work out.<br /> * '''Data Analyst:''' An athlete or coach who analyses collected data.<br /> * '''Information Seeker:''' An athlete or coach who seeks and retrieves information (eg. about training methods or nutrition) from the system.<br /> * '''Information Provider:''' An athlete, coach or expert who provides data for the system.<br /> * '''Community Member:''' An athlete or coach who is member of a social running community.<br /> * '''Data Maintainer:''' An expert, responsible to verify and maintain correctness, actuality and completeness of all data and information.<br /> * '''Interpreter:''' A specialist who translates the system into Amharic or other local languages.<br /> <br /> ==User Want==<br /> ===Definition===<br /> ''A desire regarding the design of an interactive system that is stated by a user.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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”).<br /> # The (subjective) user want is defined in contrast to the (objective) [[#User Need|user need]] from the context of use.<br /> # 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.<br /> <br /> ==SAMS Work Philosophy==<br /> ===Innovation===<br /> ====Ethiopia====<br /> 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.<br /> <br /> ====Indonesia====<br /> Innovation refers to a new idea, an approach of problem-solving that offers novelty in method and device. <br /> 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.<br /> <br /> ===Usability Evaluation===<br /> ====Ethiopia====<br /> 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.<br /> <br /> ====Indonesia====<br /> 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.<br /> <br /> ===Hardware Adaption===<br /> ====Ethiopia====<br /> 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.<br /> <br /> ====Indonesia====<br /> 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 &quot;different details&quot; 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.<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2977 2021-01-10T11:51:48Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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]].<br /> <br /> == Lean UX ==<br /> ==== Why lean UX for SAMS ====<br /> 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.<br /> <br /> === Definition ===<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> === Definition ===<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ==== Example in SAMS context ====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> === Definition ===<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ==== Example in SAMS context ====<br /> The [[Decision Support System]] must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> <br /> 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.<br /> <br /> === Definition ===<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (uxqb.org)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> (uxqb.org)<br /> <br /> ==== Example in SAMS context ====<br /> <br /> ===== Ethiopia =====<br /> 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.<br /> <br /> ===== Indonesia =====<br /> 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.<br /> <br /> == Qualitative User Requirement ==<br /> === Definition ===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes'''<br /> # 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.<br /> # Qualitative user requirements are not features. They provide the basis for features.<br /> # 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”).<br /> # Qualitative user requirements are specified with the aid of the following elements:<br /> #:*[[#User Group|User group]]<br /> #:*Type of usage (recognise, select, input)<br /> #:*Special condition(s) of the context of use for which the [[#user requirement|User Requirement]] is relevant<br /> # Sources of qualitative user requirements<br /> #:*The direct source is always one or more user needs.<br /> #:*Indirect sources:<br /> #:**Human-centred quality objectives<br /> #:**Legal/regulatory requirements<br /> #:**Market requirements<br /> #:**Organisational requirements<br /> #:**Requests<br /> #:**Identified or anticipated problems with usage<br /> #:**Dialogue principles and heuristics that are used for the specification of user requirements<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ==== Example in SAMS Context ====<br /> (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)<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! 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)<br /> |-<br /> | 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)<br /> |}<br /> <br /> == Quantitative User Requirement ==<br /> ===Definition===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes:'''<br /> #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.<br /> #The elements of a quantitative user requirement<br /> #:*The stakeholder who issued the requirement (e.g. employer or legislator)<br /> #:*User group(s) concerned who have to fulfil the requirement during use<br /> #:*The number or percentage of users who have to fulfil the requirement<br /> #:*Object of use (task object (in the user interface), tool)<br /> #:*Quantities (e.g. maximum available time, error rate, precision)<br /> #:*Special condition(s) of the context of use under which the use takes place<br /> #Sources of quantitative user requirements<br /> #:*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.”)<br /> #:*Stakeholders who define acceptance criteria for the usability of an interactive system (e.g. for a usability test)<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ====Example in SAMS context====<br /> 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.<br /> <br /> ==Requirement==<br /> ===Definition===<br /> &quot;Requirement&quot; is a widely used technical term, in context with product and process development, Wikipedia delivers the following definition:&lt;br&gt;<br /> ''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.''&lt;ref&gt;https://en.wikipedia.org/wiki/Requirement&lt;/ref&gt;<br /> <br /> The International Usability and UX Qualification Board (UXQB) uses a definition that is focused on interactive systems:<br /> ''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.''<br /> <br /> '''Notes:'''<br /> # A requirement should have a determinable condition that makes it possible to validate it.<br /> # This glossary defines the following other types of requirements:<br /> #:*[[#Stakeholder Requirement|Stakeholder requirement]]<br /> #:*[[#Market Requirement|Market requirement]]<br /> #:*[[#Organisational Requirement|Organisational requirement]]<br /> #:*[[#User Requirement|User requirement]]<br /> # This glossary further distinguishes between<br /> #:*[[#Qualitative User Requirement|Qualitative user requirement]], and<br /> #:*[[#Quantitative User Requirement|Quantitative user requirement]]<br /> &lt;ref&gt;https://uxqb.org/wp-content/uploads/documents/CPUX-UR_EN_Curriculum.pdf&lt;/ref&gt;<br /> <br /> ==Stakeholder Requirement==<br /> ===Definition===<br /> ''What the interactive system should be capable of from the point of view of the stakeholders.''<br /> <br /> '''Notes:'''<br /> # Stakeholder requirements can be classified as follows:<br /> #:*Legal / regulatory requirements (stakeholder is “Legislator”)<br /> #:*Market requirements (stakeholder is “Purchaser / Purchase decision maker”)<br /> #:*Organisational requirements (stakeholder is “Management of the organisation”)<br /> #:*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)<br /> #:*User requirements<br /> #:**qualitative: (stakeholder is “direct user”)<br /> #:**quantitative: (stakeholder is from one or more of the stakeholder groups mentioned above)<br /> # Stakeholder requirements from one category can lead to further stakeholder requirements in other categories.<br /> # Requirements for the interactive system are formulated so as to implement the stakeholder requirements. (see system requirements)<br /> # The degree to which stakeholder requirements are implemented determines the human-centered quality of the interactive system.<br /> <br /> ==User Group==<br /> ===Definition for User Centered Design (UCD)===<br /> ''A collection of users with the same or similar personal characteristics and context of use related to the interactive system.&lt;ref&gt;uxqb.org&lt;/ref&gt;''<br /> <br /> ===Divergent Definition===<br /> ''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.&lt;ref&gt;https://en.wikipedia.org/wiki/Users%27_group&lt;/ref&gt;''<br /> <br /> '''Important: Be careful not to confuse “user Group” with [[#User Role|user role]] or [[#Persona|persona]]'''<br /> <br /> ====Example in SAMS context====<br /> =====Ethiopia=====<br /> As it mentioned at the [[#Persona|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.<br /> <br /> =====Indonesia=====<br /> 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. <br /> <br /> ==User Need==<br /> ===Definition===<br /> ''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.''<br /> <br /> '''Notes:'''<br /> # '''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”.<br /> # User needs are identified based on various approaches including interviews with users, observations, user surveys, usability evaluations, expert analysis, etc.<br /> # User needs often represent gaps (or discrepancies) between what should be and what is.<br /> # '''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.<br /> # User needs are different from user wants. User needs can be transformed into user requirements, whereas user wants are transformed into market requirements.<br /> # User needs can be divided into resource needs, informational needs and competency needs.<br /> # Every component of the context of use (user, task, resources, physical environment, social environment) can be a source for user needs.<br /> <br /> ====Example in SAMS context====<br /> =====Ethiopia=====<br /> 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.<br /> <br /> =====Indonesia=====<br /> 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.<br /> <br /> ==User Requirement==<br /> The International Usability and UX Qualification Board (UXQB) distinguishes between:<br /> *[[#Qualitative User Requirement|qualitative user requirement]], and<br /> *[[#Quantitative User Requirement|quantitative user requirement]]<br /> <br /> ===Definition of Qualitative User Requirements===<br /> ''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.''<br /> <br /> ===Definition of Quantitative User Requirements===<br /> ''Required level of usability to meet identified user needs expressed in terms of effectiveness, efficiency and user satisfaction in a specified context of use.''<br /> <br /> ==User Role==<br /> 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.<br /> <br /> 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.<br /> <br /> ===Definition===<br /> # ''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<br /> 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.''&lt;ref&gt;[Constantine, Larry L.. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design (Kindle-Positionen1928-1929). Pearson Education. Kindle-Version.]&lt;/ref&gt;<br /> # ''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.'''''&lt;ref&gt;[Cohn, Mike. User Stories Applied: For Agile Software Development (Adobe Reader) (Addison-Wesley Signature Series (Beck)) (Kindle-Position892). Pearson Education. Kindle-Version.]&lt;/ref&gt;<br /> <br /> ===Form of Documentation===<br /> '''User Role Map'''<br /> Example: Training app for Ethiopian runners&lt;ref&gt;(Bastian Walthierer, Bachelor Thesis 2014, Conception and prototypic implementation of a user optimised application to support Ethiopian runners)&lt;/ref&gt;<br /> [[File:User role model2.png|thumb|Example of User Map Role]]<br /> * '''Data Collector:''' An athlete or coach collecting data during work out.<br /> * '''Data Analyst:''' An athlete or coach who analyses collected data.<br /> * '''Information Seeker:''' An athlete or coach who seeks and retrieves information (eg. about training methods or nutrition) from the system.<br /> * '''Information Provider:''' An athlete, coach or expert who provides data for the system.<br /> * '''Community Member:''' An athlete or coach who is member of a social running community.<br /> * '''Data Maintainer:''' An expert, responsible to verify and maintain correctness, actuality and completeness of all data and information.<br /> * '''Interpreter:''' A specialist who translates the system into Amharic or other local languages.<br /> <br /> ==User Want==<br /> ===Definition===<br /> ''A desire regarding the design of an interactive system that is stated by a user.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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”).<br /> # The (subjective) user want is defined in contrast to the (objective) [[#User Need|user need]] from the context of use.<br /> # 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.<br /> <br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=File:User_role_model2.png&diff=2976 2021-01-10T11:44:54Z

<p>Perempuangimbal: </p> <hr /> <div>Example of User Role Map</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2975 2020-12-27T14:10:40Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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]].<br /> <br /> == Lean UX ==<br /> ==== Why lean UX for SAMS ====<br /> 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.<br /> <br /> === Definition ===<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> === Definition ===<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ==== Example in SAMS context ====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> === Definition ===<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ==== Example in SAMS context ====<br /> The [[Decision Support System]] must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> <br /> 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.<br /> <br /> === Definition ===<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (uxqb.org)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> (uxqb.org)<br /> <br /> ==== Example in SAMS context ====<br /> <br /> ===== Ethiopia =====<br /> 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.<br /> <br /> ===== Indonesia =====<br /> 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.<br /> <br /> == Qualitative User Requirement ==<br /> === Definition ===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes'''<br /> # 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.<br /> # Qualitative user requirements are not features. They provide the basis for features.<br /> # 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”).<br /> # Qualitative user requirements are specified with the aid of the following elements:<br /> #:*[[#User Group|User group]]<br /> #:*Type of usage (recognise, select, input)<br /> #:*Special condition(s) of the context of use for which the [[#user requirement|User Requirement]] is relevant<br /> # Sources of qualitative user requirements<br /> #:*The direct source is always one or more user needs.<br /> #:*Indirect sources:<br /> #:**Human-centred quality objectives<br /> #:**Legal/regulatory requirements<br /> #:**Market requirements<br /> #:**Organisational requirements<br /> #:**Requests<br /> #:**Identified or anticipated problems with usage<br /> #:**Dialogue principles and heuristics that are used for the specification of user requirements<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ==== Example in SAMS Context ====<br /> (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)<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! 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)<br /> |-<br /> | 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)<br /> |}<br /> <br /> == Quantitative User Requirement ==<br /> ===Definition===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes:'''<br /> #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.<br /> #The elements of a quantitative user requirement<br /> #:*The stakeholder who issued the requirement (e.g. employer or legislator)<br /> #:*User group(s) concerned who have to fulfil the requirement during use<br /> #:*The number or percentage of users who have to fulfil the requirement<br /> #:*Object of use (task object (in the user interface), tool)<br /> #:*Quantities (e.g. maximum available time, error rate, precision)<br /> #:*Special condition(s) of the context of use under which the use takes place<br /> #Sources of quantitative user requirements<br /> #:*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.”)<br /> #:*Stakeholders who define acceptance criteria for the usability of an interactive system (e.g. for a usability test)<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ====Example in SAMS context====<br /> 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.<br /> <br /> ==Requirement==<br /> ===Definition===<br /> &quot;Requirement&quot; is a widely used technical term, in context with product and process development, Wikipedia delivers the following definition:&lt;br&gt;<br /> ''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.''&lt;ref&gt;https://en.wikipedia.org/wiki/Requirement&lt;/ref&gt;<br /> <br /> The International Usability and UX Qualification Board (UXQB) uses a definition that is focused on interactive systems:<br /> ''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.''<br /> <br /> '''Notes:'''<br /> # A requirement should have a determinable condition that makes it possible to validate it.<br /> # This glossary defines the following other types of requirements:<br /> #:*[[#Stakeholder Requirement|Stakeholder requirement]]<br /> #:*[[#Market Requirement|Market requirement]]<br /> #:*[[#Organisational Requirement|Organisational requirement]]<br /> #:*[[#User Requirement|User requirement]]<br /> # This glossary further distinguishes between<br /> #:*[[#Qualitative User Requirement|Qualitative user requirement]], and<br /> #:*[[#Quantitative User Requirement|Quantitative user requirement]]<br /> <br /> <br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Decision_Support_System&diff=2946 2020-12-21T01:11:50Z

<p>Perempuangimbal: </p> <hr /> <div>The SAMS Decision Support System (DSS) is one of the main results of the SAMS project. In general, DSS can be defined as any system that assists in any kind of decision making&lt;ref&gt;Bruen, M. (2006). Introduction to decision support systems. In River basin modelling for flood risk mitigation (pp. 235–248). London: Taylor &amp; Francis.&lt;/ref&gt;&lt;ref&gt;Marakas, G. M. (2003). Decision support systems in the 21st century (Vol. 134). Prentice Hall Upper Saddle River, NJ.&lt;/ref&gt;&lt;ref&gt;Power, D. J., Sharda, R. (2009). Decision Support Systems. In Springer Handbook of Automation (pp. 1539–1548). Springer.&lt;/ref&gt;. DSS is used to support the decision-makers mainly, but not to replace them. In this case to assist the beekeepers in their daily apiary management. In other words, DSS is a system, which is used for automatic data analysis with the main aim to recognize the status of the monitored object. DSS can help to automatically identify different bee colony states and inform the beekeeper if some activities are necessary.<br /> <br /> To assess the status of a honeybee colony, the beekeeper must inspect the colonies physically on site. This procedure is time-consuming and raises stress to the colony which then leads to an interruption of their daily work (and at the end of the productivity). Application of modern information and communications technology (ICT) can help to solve this issue. Precision beekeeping (PB) is a scientific direction that combines ICT and beekeeping. PB is defined as an apiary management strategy that focuses on individual bee colony monitoring in order to minimize resource consumption and maximize the productivity of bees&lt;ref&gt;Zacepins, A., Stalidzans, E., Meitalovs, J. (2012). Application of information technologies in precision apiculture. In Proceedings of the 13th International Conference on Precision Agriculture (ICPA 2012). Indianapolis, USA.&lt;/ref&gt;. By applying precision beekeeping methodology, the continuous and remote monitoring of the bee colonies may be a useful tool to decrease the number of physical inspections, support the management of honeybee health, colony development and even bee productivity.<br /> <br /> ==Apiary Management Concept==<br /> The complete bee colony (apiary) management concept proposed by SAMS is illustrated in the figure.<br /> <br /> [[File:Screen Shot 2020-12-18 at 1.19.29 PM.png|thumb|Apiary management concept with the usage of SAMS DW with integrated DSS and SAMSwiki]]<br /> <br /> The concept depicted in the figure includes all stages of the precision beekeeping three-phase cycle:<br /> * ''Data collection stage''. In this stage, the bee colonies are being monitored by the SAMS bee colony monitoring systems (SAMS HIVE) remotely collecting temperature, weight and sound data. Collected data is sent to the [[SAMS Data Warehouse]] and stored for further processing and analysis.<br /> * ''Data analysis stage''. The collected data is being analyzed in this stage by using different models and approaches. This is being done within the [[SAMS Data Warehouse]]. As a result of these models, the bee colony state is identified.<br /> * ''Result interpretation and application''. Based on the identified colony states by the DSS, different management actions can be applied by the beekeeper. The beekeeper is informed about the possible actions/recommendations through the [[#The SAMS DSS User Interface|User Interface]], where the descriptions of the recommended actions are available on the SAMSwiki platform serving partly as an advisory support system (a system that provides advice and supports problem-solving). The DSS points to the SAMSwiki, which includes various articles related to the beekeeping sector, bee biology, bee states etc. It acts as a knowledge base for beekeepers; therefore it does not only provide the recommended actions but also educates the reader on beekeeping specifics. The DSS detects/recognizes the colony states and points to the SAMSwiki, where the specific case is described in more detailed. For example, a broodless state is detected, the reader then is &quot;forwarded&quot; to the related SAMSwiki page, where the broodless state is described and recommendations are given. Then the beekeeper needs to decide what to do next by analyzing the alternatives. After the recommendations have been provided, the beekeeper can choose the appropriate alternative to perform some action or do nothing. This can be done by using an evaluation tool, like the swarm economics calculator&lt;ref&gt;https://sams.science.itf.llu.lv/swarm-economy&lt;/ref&gt; which is developed in the [[SAMS Data Warehouse|Data Warehouse]].<br /> <br /> ==The SAMS DSS User Interface==<br /> [[File:Interface DSS old.png|thumb|First Design of the DSS User Interface]]<br /> [[File:Interface DSS new.png|thumb|Second Version of the User Interface Design]]<br /> The DSS SAMS user interface for beekeepers is based on the user research. It was scribbled and prioritized during the UCD SAMS prototyping workshop in Bandung, July 2019. The user interface (UI) prototype of the DSS SAMS data display for beekeepers (for mobile devices) was then developed in Figma software. The iterative development process was discussed during regular virtual meetings dedicated to this topic with the SAMS partner and consortium members. According to the usability tests with four Ethiopian and five Indonesian beekeepers (end-users), the interface prototype (in English, Amharic and Bahasa Indonesia) was refined. <br /> <br /> All eight iteration of the interface designed is available for open-source in the '''[https://www.figma.com/file/fQlFa7rndkbcdMiM6gDO6K/SAMS-Design-Jan-May-2020?node-id=1618%3A3 SAMS Project FIGMA account]'''&lt;ref&gt;https://www.figma.com/file/fQlFa7rndkbcdMiM6gDO6K/SAMS-Design-Jan-May-2020?node-id=1618%3A3&lt;/ref&gt;. <br /> <br /> The prototype is available in English, Amharic, and Bahasa Indonesia. There is two design version which the latest version is the newest and simplified process version where beekeeper's feedbacks in the Usability Test are taken into account.<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Decision_Support_System&diff=2907 2020-12-18T06:42:33Z

<p>Perempuangimbal: </p> <hr /> <div>The SAMS Decision Support System (DSS) is one of the main results of the SAMS project. In general, DSS can be defined as any system that assists in any kind of decision making&lt;ref&gt;Bruen, M. (2006). Introduction to decision support systems. In River basin modelling for flood risk mitigation (pp. 235–248). London: Taylor &amp; Francis.&lt;/ref&gt;&lt;ref&gt;Marakas, G. M. (2003). Decision support systems in the 21st century (Vol. 134). Prentice Hall Upper Saddle River, NJ.&lt;/ref&gt;&lt;ref&gt;Power, D. J., Sharda, R. (2009). Decision Support Systems. In Springer Handbook of Automation (pp. 1539–1548). Springer.&lt;/ref&gt;. DSS is used to support the decision-makers mainly, but not to replace them. In this case to assist the beekeepers in their daily apiary management. In other words, DSS is a system, which is used for automatic data analysis with the main aim to recognize the status of the monitored object. DSS can help to automatically identify different bee colony states and inform the beekeeper if some activities are necessary.<br /> <br /> To assess the status of a honeybee colony, the beekeeper must inspect the colonies physically on site. This procedure is time-consuming and raises stress to the colony which then leads to an interruption of their daily work (and at the end of the productivity). Application of modern information and communications technology (ICT) can help to solve this issue. Precision beekeeping (PB) is a scientific direction that combines ICT and beekeeping. PB is defined as an apiary management strategy that focuses on individual bee colony monitoring in order to minimize resource consumption and maximize the productivity of bees&lt;ref&gt;Zacepins, A., Stalidzans, E., Meitalovs, J. (2012). Application of information technologies in precision apiculture. In Proceedings of the 13th International Conference on Precision Agriculture (ICPA 2012). Indianapolis, USA.&lt;/ref&gt;. By applying precision beekeeping methodology, the continuous and remote monitoring of the bee colonies may be a useful tool to decrease the number of physical inspections, support the management of honeybee health, colony development and even bee productivity.<br /> <br /> ==Apiary Management Concept==<br /> The complete bee colony (apiary) management concept proposed by SAMS is illustrated below,<br /> <br /> [[File:Screen Shot 2020-12-18 at 1.19.29 PM.png|thumb|Apiary management concept with the usage of SAMS DW with integrated DSS and SAMSwiki]]<br /> <br /> The concept depicted above includes all stages of the precision beekeeping three-phase cycle:<br /> * ''Data collection stage''. In this stage, the bee colonies are being monitored by the SAMS bee colony monitoring systems (SAMS HIVE) remotely collecting temperature, weight and sound data. Collected data is sent to the [[SAMS Data Warehouse]] and stored for further processing and analysis.<br /> * ''Data analysis stage''. The collected data is being analyzed in this stage by using different models and approaches. This is being done within the [[SAMS Data Warehouse]]. As a result of these models, the bee colony state is identified.<br /> * ''Result interpretation and application''. Based on the identified colony states by the DSS, different management actions can be applied by the beekeeper. The beekeeper is informed about the possible actions/recommendations through the [[#The SAMS DSS User Interface|User Interface]], where the descriptions of the recommended actions are available on the SAMSwiki platform serving partly as an advisory support system (a system that provides advice and supports problem-solving). The DSS points to the SAMSwiki, which includes various articles related to the beekeeping sector, bee biology, bee states etc. It acts as a knowledge base for beekeepers; therefore it does not only provide the recommended actions but also educates the reader on beekeeping specifics. The DSS detects/recognizes the colony states and points to the SAMSwiki, where the specific case is described in more detailed. For example, a broodless state is detected, the reader then is &quot;forwarded&quot; to the related SAMSwiki page, where the broodless state is described and recommendations are given. Then the beekeeper needs to decide what to do next by analyzing the alternatives. After the recommendations have been provided, the beekeeper can choose the appropriate alternative to perform some action or do nothing. This can be done by using an evaluation tool, like the swarm economics calculator&lt;ref&gt;https://sams.science.itf.llu.lv/swarm-economy&lt;/ref&gt; which is developed in the [[SAMS Data Warehouse|Data Warehouse]].<br /> <br /> ==The SAMS DSS User Interface==<br /> [[File:Interface DSS old.png|thumb|First Design of the DSS User Interface]]<br /> [[File:Interface DSS new.png|thumb|Second Version of the User Interface Design]]<br /> The DSS SAMS user interface for beekeepers is based on the user research. It was scribbled and prioritized during the UCD SAMS prototyping workshop in Bandung, July 2019. The user interface (UI) prototype of the DSS SAMS data display for beekeepers (for mobile devices) was then developed in Figma software. The iterative development process was discussed during regular virtual meetings dedicated to this topic with the SAMS partner and consortium members. According to the usability tests with four Ethiopian and five Indonesian beekeepers (end-users), the interface prototype (in English, Amharic and Bahasa Indonesia) was refined. All eight iteration of the interface designed is available for open-source here in the SAMS Project FIGMA account&lt;ref&gt;https://www.figma.com/file/fQlFa7rndkbcdMiM6gDO6K/SAMS-Design-Jan-May-2020?node-id=1618%3A3&lt;/ref&gt;. The prototype is available in English, Amharic, and Bahasa Indonesia. There is two design version which the latest version is the newest and simplified process version where beekeeper's feedbacks in the Usability Test are taken into account.<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=File:Screen_Shot_2020-12-18_at_1.19.29_PM.png&diff=2906 2020-12-18T06:21:08Z

<p>Perempuangimbal: </p> <hr /> <div>Apiary management concept with the usage of SAMS DW with integrated DSS and SAMSwiki</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Decision_Support_System&diff=2905 2020-12-18T06:18:43Z

<p>Perempuangimbal: </p> <hr /> <div>The SAMS Decision Support System (DSS) is one of the main results of the SAMS project. In general, DSS can be defined as any system that assists in any kind of decision making&lt;ref&gt;Bruen, M. (2006). Introduction to decision support systems. In River basin modelling for flood risk mitigation (pp. 235–248). London: Taylor &amp; Francis.&lt;/ref&gt;&lt;ref&gt;Marakas, G. M. (2003). Decision support systems in the 21st century (Vol. 134). Prentice Hall Upper Saddle River, NJ.&lt;/ref&gt;&lt;ref&gt;Power, D. J., Sharda, R. (2009). Decision Support Systems. In Springer Handbook of Automation (pp. 1539–1548). Springer.&lt;/ref&gt;. DSS is used to support the decision-makers mainly, but not to replace them. In this case to assist the beekeepers in their daily apiary management. In other words, DSS is a system, which is used for automatic data analysis with the main aim to recognize the status of the monitored object. DSS can help to automatically identify different bee colony states and inform the beekeeper if some activities are necessary.<br /> <br /> To assess the status of a honeybee colony, the beekeeper must inspect the colonies physically on site. This procedure is time-consuming and raises stress to the colony which then leads to an interruption of their daily work (and at the end of the productivity). Application of modern information and communications technology (ICT) can help to solve this issue. Precision beekeeping (PB) is a scientific direction that combines ICT and beekeeping. PB is defined as an apiary management strategy that focuses on individual bee colony monitoring in order to minimize resource consumption and maximize the productivity of bees&lt;ref&gt;Zacepins, A., Stalidzans, E., Meitalovs, J. (2012). Application of information technologies in precision apiculture. In Proceedings of the 13th International Conference on Precision Agriculture (ICPA 2012). Indianapolis, USA.&lt;/ref&gt;. By applying precision beekeeping methodology, the continuous and remote monitoring of the bee colonies may be a useful tool to decrease the number of physical inspections, support the management of honeybee health, colony development and even bee productivity.<br /> <br /> ==Apiary Management Concept==<br /> The complete bee colony (apiary) management concept proposed by SAMS is illustrated below,<br /> <br /> The concept depicted above includes all stages of the precision beekeeping three-phase cycle:<br /> * ''Data collection stage''. In this stage, the bee colonies are being monitored by the SAMS bee colony monitoring systems (SAMS HIVE) remotely collecting temperature, weight and sound data. Collected data is sent to the [[SAMS Data Warehouse]] and stored for further processing and analysis.<br /> * ''Data analysis stage''. The collected data is being analyzed in this stage by using different models and approaches. This is being done within the [[SAMS Data Warehouse]]. As a result of these models, the bee colony state is identified.<br /> * ''Result interpretation and application''. Based on the identified colony states by the DSS, different management actions can be applied by the beekeeper. The beekeeper is informed about the possible actions/recommendations through the [[#The SAMS DSS User Interface|User Interface]], where the descriptions of the recommended actions are available on the SAMSwiki platform serving partly as an advisory support system (a system that provides advice and supports problem-solving). The DSS points to the SAMSwiki, which includes various articles related to the beekeeping sector, bee biology, bee states etc. It acts as a knowledge base for beekeepers; therefore it does not only provide the recommended actions but also educates the reader on beekeeping specifics. The DSS detects/recognizes the colony states and points to the SAMSwiki, where the specific case is described in more detailed. For example, a broodless state is detected, the reader then is &quot;forwarded&quot; to the related SAMSwiki page, where the broodless state is described and recommendations are given. Then the beekeeper needs to decide what to do next by analyzing the alternatives. After the recommendations have been provided, the beekeeper can choose the appropriate alternative to perform some action or do nothing. This can be done by using an evaluation tool, like the swarm economics calculator&lt;ref&gt;https://sams.science.itf.llu.lv/swarm-economy&lt;/ref&gt; which is developed in the [[SAMS Data Warehouse|Data Warehouse]].<br /> <br /> ==The SAMS DSS User Interface==<br /> The DSS SAMS user interface for beekeepers is based on the user research. It was scribbled and prioritized during the UCD SAMS prototyping workshop in Bandung, July 2019. The user interface (UI) prototype of the DSS SAMS data display for beekeepers (for mobile devices) was then developed in Figma software. The iterative development process was discussed during regular virtual meetings dedicated to this topic with the SAMS partner and consortium members. According to the usability tests with four Ethiopian and five Indonesian beekeepers (end-users), the interface prototype (in English, Amharic and Bahasa Indonesia) was refined. All eight iteration of the interface designed is available for open-source here in the SAMS Project FIGMA account&lt;ref&gt;https://www.figma.com/file/fQlFa7rndkbcdMiM6gDO6K/SAMS-Design-Jan-May-2020?node-id=1618%3A3&lt;/ref&gt;. The prototype is available in English, Amharic, and Bahasa Indonesia. There is two design version which the latest version is the newest and simplified process version where beekeeper's feedbacks in the Usability Test are taken into account.<br /> <br /> [[File:Interface DSS old.png|frameless|center|First Design of the DSS User Interface]]<br /> <br /> <br /> [[File:Interface DSS new.png|frameless|center|Second version of the User Interface Design]]<br /> <br /> &lt;/gallery&gt;<br /> File:Interface DSS old.png|First Design of the DSS User Interface<br /> File:Interface DSS new.png|Second version of the User Interface Design<br /> &lt;/gallery&gt;<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=File:Interface_DSS_old.png&diff=2904 2020-12-18T06:12:45Z

<p>Perempuangimbal: </p> <hr /> <div>interface DSS old</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=File:Interface_DSS_new.png&diff=2903 2020-12-18T06:09:28Z

<p>Perempuangimbal: </p> <hr /> <div>Interface DSS new</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Decision_Support_System&diff=2902 2020-12-18T05:19:06Z

<p>Perempuangimbal: </p> <hr /> <div>The SAMS Decision Support System (DSS) is one of the main results of the SAMS project. In general, DSS can be defined as any system that assists in any kind of decision making&lt;ref&gt;Bruen, M. (2006). Introduction to decision support systems. In River basin modelling for flood risk mitigation (pp. 235–248). London: Taylor &amp; Francis.&lt;/ref&gt;&lt;ref&gt;Marakas, G. M. (2003). Decision support systems in the 21st century (Vol. 134). Prentice Hall Upper Saddle River, NJ.&lt;/ref&gt;&lt;ref&gt;Power, D. J., Sharda, R. (2009). Decision Support Systems. In Springer Handbook of Automation (pp. 1539–1548). Springer.&lt;/ref&gt;. DSS is used to support the decision-makers mainly, but not to replace them. In this case to assist the beekeepers in their daily apiary management. In other words, DSS is a system, which is used for automatic data analysis with the main aim to recognize the status of the monitored object. DSS can help to automatically identify different bee colony states and inform the beekeeper if some activities are necessary.<br /> <br /> To assess the status of a honeybee colony, the beekeeper must inspect the colonies physically on site. This procedure is time-consuming and raises stress to the colony which then leads to an interruption of their daily work (and at the end of the productivity). Application of modern information and communications technology (ICT) can help to solve this issue. Precision beekeeping (PB) is a scientific direction that combines ICT and beekeeping. PB is defined as an apiary management strategy that focuses on individual bee colony monitoring in order to minimize resource consumption and maximize the productivity of bees&lt;ref&gt;Zacepins, A., Stalidzans, E., Meitalovs, J. (2012). Application of information technologies in precision apiculture. In Proceedings of the 13th International Conference on Precision Agriculture (ICPA 2012). Indianapolis, USA.&lt;/ref&gt;. By applying precision beekeeping methodology, the continuous and remote monitoring of the bee colonies may be a useful tool to decrease the number of physical inspections, support the management of honeybee health, colony development and even bee productivity.<br /> <br /> ==Apiary Management Concept==<br /> The complete bee colony (apiary) management concept proposed by SAMS is illustrated below,<br /> <br /> The concept depicted above includes all stages of the precision beekeeping three-phase cycle:<br /> * ''Data collection stage''. In this stage, the bee colonies are being monitored by the SAMS bee colony monitoring systems (SAMS HIVE) remotely collecting temperature, weight and sound data. Collected data is sent to the [[SAMS Data Warehouse]] and stored for further processing and analysis.<br /> * ''Data analysis stage''. The collected data is being analyzed in this stage by using different models and approaches. This is being done within the [[SAMS Data Warehouse]]. As a result of these models, the bee colony state is identified.<br /> * ''Result interpretation and application''. Based on the identified colony states by the DSS, different management actions can be applied by the beekeeper. The beekeeper is informed about the possible actions/recommendations through the [[#The SAMS DSS User Interface|User Interface]], where the descriptions of the recommended actions are available on the SAMSwiki platform serving partly as an advisory support system (a system that provides advice and supports problem-solving). The DSS points to the SAMSwiki, which includes various articles related to the beekeeping sector, bee biology, bee states etc. It acts as a knowledge base for beekeepers; therefore it does not only provide the recommended actions but also educates the reader on beekeeping specifics. The DSS detects/recognizes the colony states and points to the SAMSwiki, where the specific case is described in more detailed. For example, a broodless state is detected, the reader then is &quot;forwarded&quot; to the related SAMSwiki page, where the broodless state is described and recommendations are given. Then the beekeeper needs to decide what to do next by analyzing the alternatives. After the recommendations have been provided, the beekeeper can choose the appropriate alternative to perform some action or do nothing. This can be done by using an evaluation tool, like the swarm economics calculator&lt;ref&gt;https://sams.science.itf.llu.lv/swarm-economy&lt;/ref&gt; which is developed in the [[SAMS Data Warehouse|Data Warehouse]].<br /> <br /> ==The SAMS DSS User Interface==<br /> The DSS SAMS user interface for beekeepers is based on the user research. It was scribbled and prioritized during the UCD SAMS prototyping workshop in Bandung, July 2019. The user interface (UI) prototype of the DSS SAMS data display for beekeepers (for mobile devices) was then developed in Figma software. The iterative development process was discussed during regular virtual meetings dedicated to this topic with the SAMS partner and consortium members. According to the usability tests with four Ethiopian and five Indonesian beekeepers (end-users), the interface prototype (in English, Amharic and Bahasa Indonesia) was refined. All eight iteration of the interface designed is available for open-source here in the SAMS Project FIGMA account&lt;ref&gt;https://www.figma.com/file/fQlFa7rndkbcdMiM6gDO6K/SAMS-Design-Jan-May-2020?node-id=1618%3A3&lt;/ref&gt;. The prototype is available in English, Amharic, and Bahasa Indonesia. There is two design version which the latest version is the newest and simplified process version where beekeeper's feedbacks in the Usability Test are taken into account.<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Decision_Support_System&diff=2901 2020-12-18T05:00:27Z

<p>Perempuangimbal: </p> <hr /> <div>The SAMS Decision Support System (DSS) is one of the main results of the SAMS project. In general, DSS can be defined as any system that assists in any kind of decision making&lt;ref&gt;Bruen, M. (2006). Introduction to decision support systems. In River basin modelling for flood risk mitigation (pp. 235–248). London: Taylor &amp; Francis.&lt;/ref&gt;&lt;ref&gt;Marakas, G. M. (2003). Decision support systems in the 21st century (Vol. 134). Prentice Hall Upper Saddle River, NJ.&lt;/ref&gt;&lt;ref&gt;Power, D. J., Sharda, R. (2009). Decision Support Systems. In Springer Handbook of Automation (pp. 1539–1548). Springer.&lt;/ref&gt;. DSS is used to support the decision-makers mainly, but not to replace them. In this case to assist the beekeepers in their daily apiary management. In other words, DSS is a system, which is used for automatic data analysis with the main aim to recognize the status of the monitored object. DSS can help to automatically identify different bee colony states and inform the beekeeper if some activities are necessary.<br /> <br /> To assess the status of a honeybee colony, the beekeeper must inspect the colonies physically on site. This procedure is time-consuming and raises stress to the colony which then leads to an interruption of their daily work (and at the end of the productivity). Application of modern information and communications technology (ICT) can help to solve this issue. Precision beekeeping (PB) is a scientific direction that combines ICT and beekeeping. PB is defined as an apiary management strategy that focuses on individual bee colony monitoring in order to minimize resource consumption and maximize the productivity of bees&lt;ref&gt;Zacepins, A., Stalidzans, E., Meitalovs, J. (2012). Application of information technologies in precision apiculture. In Proceedings of the 13th International Conference on Precision Agriculture (ICPA 2012). Indianapolis, USA.&lt;/ref&gt;. By applying precision beekeeping methodology, the continuous and remote monitoring of the bee colonies may be a useful tool to decrease the number of physical inspections, support the management of honeybee health, colony development and even bee productivity.<br /> <br /> ==Apiary Management Concept==<br /> The complete bee colony (apiary) management concept proposed by SAMS is illustrated below,<br /> <br /> The concept depicted above includes all stages of the precision beekeeping three-phase cycle:<br /> * ''Data collection stage''. In this stage, the bee colonies are being monitored by the SAMS bee colony monitoring systems (SAMS HIVE) remotely collecting temperature, weight and sound data. Collected data is sent to the [[SAMS Data Warehouse]] and stored for further processing and analysis.<br /> * ''Data analysis stage''. The collected data is being analyzed in this stage by using different models and approaches. This is being done within the [[SAMS Data Warehouse]]. As a result of these models, the bee colony state is identified.<br /> * ''Result interpretation and application''. Based on the identified colony states by the DSS, different management actions can be applied by the beekeeper. The beekeeper is informed about the possible actions/recommendations through the [[#The SAMS DSS User Interface|User Interface]], where the descriptions of the recommended actions are available on the SAMSwiki platform serving partly as an advisory support system (a system that provides advice and supports problem-solving). The DSS points to the SAMSwiki, which includes various articles related to the beekeeping sector, bee biology, bee states etc. It acts as a knowledge base for beekeepers; therefore it does not only provide the recommended actions but also educates the reader on beekeeping specifics. The DSS detects/recognizes the colony states and points to the SAMSwiki, where the specific case is described in more detailed. For example, a broodless state is detected, the reader then is &quot;forwarded&quot; to the related SAMSwiki page, where the broodless state is described and recommendations are given. Then the beekeeper needs to decide what to do next by analyzing the alternatives. After the recommendations have been provided, the beekeeper can choose the appropriate alternative to perform some action or do nothing. This can be done by using an evaluation tool, like the swarm economics calculator&lt;ref&gt;https://sams.science.itf.llu.lv/swarm-economy&lt;/ref&gt; which is developed in the [[SAMS Data Warehouse|Data Warehouse]].<br /> <br /> ==The SAMS DSS User Interface==<br /> The DSS SAMS user interface for beekeepers is based on the user research. It was scribbled and prioritized during the UCD SAMS prototyping workshop in Bandung, July 2019. The user interface (UI) prototype of the DSS SAMS data display for beekeepers (for mobile devices) was then developed in Figma software by CV.PI. The iterative development process was discussed during regular virtual meetings dedicated to this topic with the SAMS partner and consortium members; UNILV, GIZ and ICEADDIS. According to the usability tests with four Ethiopian and five Indonesian beekeepers (end-users), the interface prototype (in English, Amharic and Bahasa Indonesia) was refined. The user interface prototype in English, Amharic and Bahasa Indonesia in 8 iterations with 2 design versions of the SAMS data display for beekeepers is available open-source for further elaboration and for developing an app to facilitate a business.<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Decision_Support_System&diff=2900 2020-12-18T04:59:08Z

<p>Perempuangimbal: </p> <hr /> <div>==Decision Support System (DSS)==<br /> The Decision Support System (DSS) is one of the main results of the SAMS project. In general, DSS can be defined as any system that assists in any kind of decision making&lt;ref&gt;Bruen, M. (2006). Introduction to decision support systems. In River basin modelling for flood risk mitigation (pp. 235–248). London: Taylor &amp; Francis.&lt;/ref&gt;&lt;ref&gt;Marakas, G. M. (2003). Decision support systems in the 21st century (Vol. 134). Prentice Hall Upper Saddle River, NJ.&lt;/ref&gt;&lt;ref&gt;Power, D. J., Sharda, R. (2009). Decision Support Systems. In Springer Handbook of Automation (pp. 1539–1548). Springer.&lt;/ref&gt;. DSS is used to support the decision-makers mainly, but not to replace them. In this case to assist the beekeepers in their daily apiary management. In other words, DSS is a system, which is used for automatic data analysis with the main aim to recognize the status of the monitored object. DSS can help to automatically identify different bee colony states and inform the beekeeper if some activities are necessary.<br /> <br /> To assess the status of a honeybee colony, the beekeeper must inspect the colonies physically on site. This procedure is time-consuming and raises stress to the colony which then leads to an interruption of their daily work (and at the end of the productivity). Application of modern information and communications technology (ICT) can help to solve this issue. Precision beekeeping (PB) is a scientific direction that combines ICT and beekeeping. PB is defined as an apiary management strategy that focuses on individual bee colony monitoring in order to minimize resource consumption and maximize the productivity of bees&lt;ref&gt;Zacepins, A., Stalidzans, E., Meitalovs, J. (2012). Application of information technologies in precision apiculture. In Proceedings of the 13th International Conference on Precision Agriculture (ICPA 2012). Indianapolis, USA.&lt;/ref&gt;. By applying precision beekeeping methodology, the continuous and remote monitoring of the bee colonies may be a useful tool to decrease the number of physical inspections, support the management of honeybee health, colony development and even bee productivity.<br /> <br /> ==Apiary Management Concept==<br /> The complete bee colony (apiary) management concept proposed by SAMS is illustrated below,<br /> <br /> The concept depicted above includes all stages of the precision beekeeping three-phase cycle:<br /> * ''Data collection stage''. In this stage, the bee colonies are being monitored by the SAMS bee colony monitoring systems (SAMS HIVE) remotely collecting temperature, weight and sound data. Collected data is sent to the [[SAMS Data Warehouse]] and stored for further processing and analysis.<br /> * ''Data analysis stage''. The collected data is being analyzed in this stage by using different models and approaches. This is being done within the [[SAMS Data Warehouse]]. As a result of these models, the bee colony state is identified.<br /> * ''Result interpretation and application''. Based on the identified colony states by the DSS, different management actions can be applied by the beekeeper. The beekeeper is informed about the possible actions/recommendations through the [[#The SAMS DSS User Interface|User Interface]], where the descriptions of the recommended actions are available on the SAMSwiki platform serving partly as an advisory support system (a system that provides advice and supports problem-solving). The DSS points to the SAMSwiki, which includes various articles related to the beekeeping sector, bee biology, bee states etc. It acts as a knowledge base for beekeepers; therefore it does not only provide the recommended actions but also educates the reader on beekeeping specifics. The DSS detects/recognizes the colony states and points to the SAMSwiki, where the specific case is described in more detailed. For example, a broodless state is detected, the reader then is &quot;forwarded&quot; to the related SAMSwiki page, where the broodless state is described and recommendations are given. Then the beekeeper needs to decide what to do next by analyzing the alternatives. After the recommendations have been provided, the beekeeper can choose the appropriate alternative to perform some action or do nothing. This can be done by using an evaluation tool, like the swarm economics calculator&lt;ref&gt;https://sams.science.itf.llu.lv/swarm-economy&lt;/ref&gt; which is developed in the [[SAMS Data Warehouse|Data Warehouse]].<br /> <br /> ==The SAMS DSS User Interface==<br /> The DSS SAMS user interface for beekeepers is based on the user research. It was scribbled and prioritized during the UCD SAMS prototyping workshop in Bandung, July 2019. The user interface (UI) prototype of the DSS SAMS data display for beekeepers (for mobile devices) was then developed in Figma software by CV.PI. The iterative development process was discussed during regular virtual meetings dedicated to this topic with the SAMS partner and consortium members; UNILV, GIZ and ICEADDIS. According to the usability tests with four Ethiopian and five Indonesian beekeepers (end-users), the interface prototype (in English, Amharic and Bahasa Indonesia) was refined. The user interface prototype in English, Amharic and Bahasa Indonesia in 8 iterations with 2 design versions of the SAMS data display for beekeepers is available open-source for further elaboration and for developing an app to facilitate a business.<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Decision_Support_System&diff=2899 2020-12-18T04:53:26Z

<p>Perempuangimbal: </p> <hr /> <div>==Decision Support System (DSS)==<br /> The Decision Support System (DSS) is one of the main results of the SAMS project. In general, DSS can be defined as any system that assists in any kind of decision making&lt;ref&gt;Bruen, M. (2006). Introduction to decision support systems. In River basin modelling for flood risk mitigation (pp. 235–248). London: Taylor &amp; Francis.&lt;/ref&gt;&lt;ref&gt;Marakas, G. M. (2003). Decision support systems in the 21st century (Vol. 134). Prentice Hall Upper Saddle River, NJ.&lt;/ref&gt;&lt;ref&gt;Power, D. J., Sharda, R. (2009). Decision Support Systems. In Springer Handbook of Automation (pp. 1539–1548). Springer.&lt;/ref&gt;. DSS is used to support the decision-makers mainly, but not to replace them. In this case to assist the beekeepers in their daily apiary management. In other words, DSS is a system, which is used for automatic data analysis with the main aim to recognize the status of the monitored object. DSS can help to automatically identify different bee colony states and inform the beekeeper if some activities are necessary.<br /> <br /> To assess the status of a honeybee colony, the beekeeper must inspect the colonies physically on site. This procedure is time-consuming and raises stress to the colony which then leads to an interruption of their daily work (and at the end of the productivity). Application of modern information and communications technology (ICT) can help to solve this issue. Precision beekeeping (PB) is a scientific direction that combines ICT and beekeeping. PB is defined as an apiary management strategy that focuses on individual bee colony monitoring in order to minimize resource consumption and maximize the productivity of bees&lt;ref&gt;Zacepins, A., Stalidzans, E., Meitalovs, J. (2012). Application of information technologies in precision apiculture. In Proceedings of the 13th International Conference on Precision Agriculture (ICPA 2012). Indianapolis, USA.&lt;/ref&gt;. By applying precision beekeeping methodology, the continuous and remote monitoring of the bee colonies may be a useful tool to decrease the number of physical inspections, support the management of honeybee health, colony development and even bee productivity.<br /> <br /> ==Apiary Management Concept==<br /> The complete bee colony (apiary) management concept proposed by SAMS is illustrated below,<br /> <br /> The concept depicted above includes all stages of the precision beekeeping three-phase cycle:<br /> * ''Data collection stage''. In this stage, the bee colonies are being monitored by the SAMS bee colony monitoring systems (SAMS HIVE) remotely collecting temperature, weight and sound data. Collected data is sent to the [[SAMS Data Warehouse]] and stored for further processing and analysis.<br /> * ''Data analysis stage''. The collected data is being analyzed in this stage by using different models and approaches. This is being done within the [[SAMS Data Warehouse]]. As a result of these models, the bee colony state is identified.<br /> * ''Result interpretation and application''. Based on the identified colony states by the DSS, different management actions can be applied by the beekeeper. The beekeeper is informed about the possible actions/recommendations through the [[#The SAMS DSS User Interface|User Interface]], where the descriptions of the recommended actions are available on the SAMSwiki platform serving partly as an advisory support system (a system that provides advice and supports problem-solving). The DSS points to the SAMSwiki, which includes various articles related to the beekeeping sector, bee biology, bee states etc. It acts as a knowledge base for beekeepers; therefore it does not only provide the recommended actions but also educates the reader on beekeeping specifics. The DSS detects/recognizes the colony states and points to the SAMSwiki, where the specific case is described in more detailed. For example, a broodless state is detected, the reader then is &quot;forwarded&quot; to the related SAMSwiki page, where the broodless state is described and recommendations are given. Then the beekeeper needs to decide what to do next by analyzing the alternatives. After the recommendations have been provided, the beekeeper can choose the appropriate alternative to perform some action or do nothing. This can be done by using an evaluation tool, like the swarm economics calculator&lt;ref&gt;https://sams.science.itf.llu.lv/swarm-economy&lt;/ref&gt; which is developed in the [[SAMS Data Warehouse|Data Warehouse]].<br /> <br /> ==The SAMS DSS User Interface==<br /> The DSS SAMS user interface for beekeepers is based on the user research. It was scribbled and prioritized during the UCD SAMS prototyping workshop in Bandung, July 2019. The user interface (UI) prototype of the DSS SAMS data display for beekeepers (for mobile devices) was then developed in Figma software by CV.PI. The iterative development process was discussed during regular virtual meetings dedicated to this topic with the SAMS partner and consortium members; UNILV, GIZ and ICEADDIS. According to the usability tests with four Ethiopian and five Indonesian beekeepers (end-users), the interface prototype (in English, Amharic and Bahasa Indonesia) was refined. The user interface prototype in English, Amharic and Bahasa Indonesia in 8 iterations with 2 design versions of the SAMS data display for beekeepers is available open-source for further elaboration and for developing an app to facilitate a business.</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_Data_Warehouse&diff=2897 2020-12-18T04:44:30Z

<p>Perempuangimbal: Perempuangimbal moved page The SAMS Data Warehouse to SAMS Data Warehouse</p> <hr /> <div>The Latvia University of Life Sciences and Technologies team developed a basic instruction on how to connect general bee colony monitoring hardware to SAMS Data Warehouse (DW). This instruction will ease the process of sending data from any general bee colony monitoring system to the SAMS Data Warehouse for storage and analysis. The Data Warehouse is an online platform which functions like a virtual workspace, where beekeepers can store, access and assess their bee data.<br /> The SAMS DW is a universal system, which can operate with different data inputs and have flexible data processing algorithms. Users can sign up into the DW using their own email/password or google account. Each user is associated with one or more workspaces, which should be configured based on apiary configuration.<br /> Then following steps have to be performed on the device (hardware) to send data to the warehouse:<br /> &lt;br /&gt;<br /> <br /> <br /> * Acquire access token. This token is used by the DW to authenticate and authorize the request.<br /> * Post the data to DW. There is a single endpoint for posting data to the DW – https://sams.science.itf.llu.lv/api/data. The access token should be provided in the Authorization header and the request body can contain multiple data packages.<br /> Reports about posted measurements are immediately available in the UI under the Reports section. Additional debugging information is available in the Dashboard (last 10 received measurements) and Devices (last events and errors).<br /> <br /> * For any questions related to the Data Warehouse and connection of the hardware to it please contact the team from Latvia University of Life Sciences and Technologies, Faculty of Information Technologies.<br /> <br /> Full instruction on how to connect general bee colony monitoring hardware to SAMS Data Warehouse is available here:<br /> <br /> '''https://sams-project.eu/wp-content/uploads/2020/02/DW-data-sending-guide.pdf'''</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=The_SAMS_Data_Warehouse&diff=2898 2020-12-18T04:44:30Z

<p>Perempuangimbal: Perempuangimbal moved page The SAMS Data Warehouse to SAMS Data Warehouse</p> <hr /> <div>#REDIRECT [[SAMS Data Warehouse]]</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Decision_Support_System&diff=2896 2020-12-18T04:31:23Z

<p>Perempuangimbal: </p> <hr /> <div>==Decision Support System (DSS)==<br /> The Decision Support System (DSS) is one of the main results of the SAMS project. In general, DSS can be defined as any system that assists in any kind of decision making&lt;ref&gt;Bruen, M. (2006). Introduction to decision support systems. In River basin modelling for flood risk mitigation (pp. 235–248). London: Taylor &amp; Francis.&lt;/ref&gt;&lt;ref&gt;Marakas, G. M. (2003). Decision support systems in the 21st century (Vol. 134). Prentice Hall Upper Saddle River, NJ.&lt;/ref&gt;&lt;ref&gt;Power, D. J., Sharda, R. (2009). Decision Support Systems. In Springer Handbook of Automation (pp. 1539–1548). Springer.&lt;/ref&gt;. DSS is used to mainly support the decision-makers, but not to replace them. In this case to assist the beekeepers in their daily apiary management. In other words, DSS is a system, which is used for automatic data analysis with the main aim to recognize the status of the monitored object. DSS can help to automatically identify different bee colony states and inform the beekeeper if some activities are necessary.<br /> To assess the status of a honeybee colony, the beekeeper must inspect the colonies physically on site. This procedure is time-consuming and raises stress to the colony which then leads to an interruption of their daily work (and at the end of the productivity). Application of modern information and communications technology (ICT) can help to solve this issue. Precision beekeeping (PB) is a scientific direction that combines ICT and beekeeping. PB is defined as an apiary management strategy that focuses on individual bee colony monitoring in order to minimize resource consumption and maximize the productivity of bees. By applying precision beekeeping methodology, the continuous and remote monitoring of the bee colonies may be a useful tool to decrease the number of physical inspections, support the management of honeybee health, colony development and even bee productivity.<br /> <br /> ==The DSS User Interface==<br /> The DSS SAMS user interface for beekeepers is based on the user research. It was scribbled and prioritized during the UCD SAMS prototyping workshop in Bandung, July 2019. The user interface (UI) prototype of the DSS SAMS data display for beekeepers (for mobile devices) was then developed in Figma software by CV.PI. The iterative development process was discussed during regular virtual meetings dedicated to this topic with the SAMS partner and consortium members; UNILV, GIZ and ICEADDIS. According to the usability tests with four Ethiopian and five Indonesian beekeepers (end-users), the interface prototype (in English, Amharic and Bahasa Indonesia) was refined. The user interface prototype in English, Amharic and Bahasa Indonesia in 8 iterations with 2 design versions of the SAMS data display for beekeepers is available open-source for further elaboration and for developing an app to facilitate a business.</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Decision_Support_System&diff=2894 2020-12-18T04:27:06Z

<p>Perempuangimbal: Perempuangimbal moved page Decision Support System to SAMS Decision Support System: forgot to mention about the SAMS in the title</p> <hr /> <div>==SAMS Decision Support System (DSS)==<br /> The Decision Support System (DSS) is one of the main results of the SAMS project. DSS is …<br /> (How it suppose to help beekeepers as end-users)<br /> <br /> ==The DSS User Interface==<br /> The DSS SAMS user interface for beekeepers is based on the user research. It was scribbled and prioritized during the UCD SAMS prototyping workshop in Bandung, July 2019. The user interface (UI) prototype of the DSS SAMS data display for beekeepers (for mobile devices) was then developed in Figma software by CV.PI. The iterative development process was discussed during regular virtual meetings dedicated to this topic with the SAMS partner and consortium members; UNILV, GIZ and ICEADDIS. According to the usability tests with four Ethiopian and five Indonesian beekeepers (end-users), the interface prototype (in English, Amharic and Bahasa Indonesia) was refined. The user interface prototype in English, Amharic and Bahasa Indonesia in 8 iterations with 2 design versions of the SAMS data display for beekeepers is available open-source for further elaboration and for developing an app to facilitate a business.</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=Decision_Support_System&diff=2895 2020-12-18T04:27:06Z

<p>Perempuangimbal: Perempuangimbal moved page Decision Support System to SAMS Decision Support System: forgot to mention about the SAMS in the title</p> <hr /> <div>#REDIRECT [[SAMS Decision Support System]]</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Personas&diff=2890 2020-12-16T18:47:06Z

<p>Perempuangimbal: /* Types of Modern Beehives */</p> <hr /> <div>The created [[UCD Glossary|personas]] helped the UCD team as well as the complete SAMS project team to understand and analyse beekeeper needs better to develop SAMS products further.<br /> “Persona is a description of a user and what he or she intends to do when using an interactive system. Personas are not real; they are examples invented to stand for 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.” &lt;ref&gt;uxqb.org&lt;/ref&gt;<br /> &lt;br&gt;<br /> The SAMS monitoring system development depends on the beekeepers’ background and context factors, for example, [[#Types of Modern Beehives|types of modern beehives]] they use, bee types they breed, electricity availability in their beekeeping site, and how deep they are personally influenced by beekeeping traditions and by their cultural environment and family traditions.<br /> Based on the results of the context of use analysis in the Field Research (Stage 1), following personas, collectively represent the major behaviours of beekeepers in Ethiopia and Indonesia.<br /> <br /> == Ethiopia ==<br /> === Tadesse, Aberash and Degen ===<br /> &lt;br&gt;<br /> [[File:EthiopianPersonas.JPG|frame|center|Ethiopian beekeeper personas.]]<br /> &lt;br&gt;<br /> * Tadese represents beekeepers in the countryside which usually rely on their instincts and the traditional way of beekeeping;<br /> * Aberash represents small-scale modern beekeepers, living in small towns or suburbs of the cites;<br /> * Degen represents a modern beekeeper who is interested in large scale beekeeping and high financial incentive.<br /> &lt;br&gt;<br /> The Ethiopian personas are keeping ''Apis mellifera'', which is the only bee species in the country. Tadese uses a homemade traditional beehive, the traditional beehive requires very low cost and a minimum management effort to operate but it is very low in productivity. The volumes per harvest is very low comparing to modern beehives. Most of the honey harvested is consumed within Tadese's family, a little portion of the honey goes to the local market. Aberash is a modern beekeeper, she has 15 to 20 modern beehives and works as a professional beekeeper. She is skilled using modern beekeeping equipment with combining the traditional ways of beekeeping. She offers her services to other fellow beekeepers and gains moderate financial benefit from her profession. Degen is a commercial beekeeper with a major interest in large scale honey production. He has good knowledge about the market value of honey and honey product distribution. He hires beekeeping professionals like Aberash to manage his apiaries and mostly focuses on the market dynamics of the honey products.<br /> <br /> == Indonesia ==<br /> <br /> === Kurt, Giuseppe, Dicky and Elsa ===<br /> &lt;br&gt;<br /> [[File:IndonesiaPersonas.JPG|frame|center|Indonesian beekeeper personas.]]<br /> &lt;br&gt;<br /> Kurt and Giuseppe are beekeepers who live in remote and rural areas of West Java. Though both are grassroots beekeepers,<br /> * Kurt represents the majority of the grassroot beekeepers who have limited access to stakeholders’ support; he often does his beekeeping activities with fellow grassroot beekeepers in his neighbourhood; he usually builds his beehives with recycled material (the “DIY” beehive type), each hives’ dimension may vary;<br /> * Giuseppe, though he lives close to Kurt, is privileged with his status as a member of the government’s office staff; this position benefits him with more access to the beekeeping sector’s stakeholders.<br /> Dicky and Elsa represent the young generations of beekeepers,<br /> * Dicky grows up in a beekeeper family with generations of experience; his grandfather and father are beekeepers, so it is only natural for him to continue this tradition, despite his young age; born as a digital native, Dicky uses his social media presence to promote his activities and his family business;<br /> * Elsa, unlike the previously described personas, has no beekeeping tradition in her family; she is a curious millennial who wants to contribute in all possible ways to protect the environment, including keeping bees.<br /> <br /> ==== Types of Modern Beehives ====<br /> <br /> The beekeepers work with different types of bees and modern beehives. Kurt mostly keeps ''Apis cerana'', Giuseppe and Dicky have several colonies of ''Apis mellifera'', ''Apis cerana'', and ''Trigona'' spp. (stingless bee). While for Elsa, who lives in the city, it makes more sense to keep ''Trigona'', the stingless bee – not only because it is stingless, but also its small size helps Elsa maintaining the colony easily. Kurt, Giuseppe, and Dicky have a professional interest in harvesting honey as it is one of their sources of income, Elsa harvests honey for her consumption only.<br /> &lt;br&gt;<br /> [[File:Screen Shot 2020-10-07 at 2.20.45 AM.png|600px|frameless|center|Types of modern beehives in Indonesia.]]<br /> &lt;br&gt;<br /> After further user research, the Indonesian personas were refined. Elsa, Dicky, Giuseppe and Kurt were removed mainly because of the SAMS product development’s focus, which is more suiting to other types of beekeepers.<br /> <br /> === Usep and Sopian ===<br /> <br /> [[File:IndonesiaPersonasrefined.JPG|frame|center|Refined personas in Indonesia.]]<br /> <br /> Meet Usep, a 53 years old grassroots beekeeper living in a remote village, a two-hour drive from Ciamis Regency in West Java. Ciamis itself is a regency area 117 kilometres away from Bandung, the capital city of West Java. His mother tongue is Sundanese and he does not speak or understand English. He does bee hunting in the forest with his fellow beekeepers. He owns not more than 20 various types of modern beehives and bee types. His beekeeping methods are passed down from his mentors. He increased his beekeeping skills through shared beekeeping practices of the beekeeping community’s Facebook group. He is a smartphone user, like any other beekeeper in his circle. He uses his smartphone mostly for socializing via WhatsApp or Facebook. Not only promoting his products, he often shares his thoughts, perspectives, or complaints regarding political or social issues through WhatsApp and uses Facebook posts to promote his beekeeping activities.<br /> Meet Sopian, a 40 years old beekeeper who lives in the peri-urban area near Bandung, the capital city of West Java. He started beekeeping when he was 17 years old. He got his beekeeping knowledge from his brother and perfecting it along the way. Aside from being a beekeeper, Sopian also works as a government officer in the Regency Office. He is doing beekeeping whenever he is off duty from his office work and during weekends. Like Usep, Sopian also uses a smartphone to socialize and sell his harvested honey. Sopian creates a network of beekeepers in several rural areas near his place and considers them as his partners. Sopian will teach them his way of beekeeping, support them with logistics like modern beehives, and when the harvesting time is coming, he will help them sell their harvested honey as well with fair profit sharing. Though he is confident with his beekeeping method, Sopian eagerly learns new ways and new things related to beekeeping practices, including integrating technology in beekeeping. For selling his honey, he built a small counter in front of his house. Visitors are also welcome to discuss bee-related knowledge.<br /> &lt;br&gt;<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=File:Screen_Shot_2020-10-07_at_2.20.45_AM.png&diff=2889 2020-12-16T18:43:24Z

<p>Perempuangimbal: </p> <hr /> <div>Types of modern beehives in Indonesia</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2888 2020-12-16T18:10:24Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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]].<br /> <br /> == Lean UX ==<br /> ==== Why lean UX for SAMS ====<br /> 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.<br /> <br /> === Definition ===<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> === Definition ===<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ==== Example in SAMS context ====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> === Definition ===<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ==== Example in SAMS context ====<br /> The [[Decision Support System]] must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> <br /> 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.<br /> <br /> === Definition ===<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (uxqb.org)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> (uxqb.org)<br /> <br /> ==== Example in SAMS context ====<br /> <br /> ===== Ethiopia =====<br /> 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.<br /> <br /> ===== Indonesia =====<br /> 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.<br /> <br /> == Product Backlog ==<br /> === Definition ===<br /> ''In the simplest definition, the Scrum Product Backlog is simply a list of all things that need to be done within the project. It replaces the traditional requirements specification artefacts. These items can have a technical nature or can be user-centric e.g. in the form of user stories.''<br /> (scrum-Institute.org)<br /> <br /> == Qualitative User Requirement ==<br /> === Definition ===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes'''<br /> # 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.<br /> # Qualitative user requirements are not features. They provide the basis for features.<br /> # 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”).<br /> # Qualitative user requirements are specified with the aid of the following elements:<br /> #:*[[#User Group|User group]]<br /> #:*Type of usage (recognise, select, input)<br /> #:*Special condition(s) of the context of use for which the [[#user requirement|User Requirement]] is relevant<br /> # Sources of qualitative user requirements<br /> #:*The direct source is always one or more user needs.<br /> #:*Indirect sources:<br /> #:**Human-centred quality objectives<br /> #:**Legal/regulatory requirements<br /> #:**Market requirements<br /> #:**Organisational requirements<br /> #:**Requests<br /> #:**Identified or anticipated problems with usage<br /> #:**Dialogue principles and heuristics that are used for the specification of user requirements<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ==== Example in SAMS Context ====<br /> (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)<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! 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)<br /> |-<br /> | 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)<br /> |}<br /> <br /> == Quantitative User Requirement ==<br /> ===Definition===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes:'''<br /> #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.<br /> #The elements of a quantitative user requirement<br /> #:*The stakeholder who issued the requirement (e.g. employer or legislator)<br /> #:*User group(s) concerned who have to fulfil the requirement during use<br /> #:*The number or percentage of users who have to fulfil the requirement<br /> #:*Object of use (task object (in the user interface), tool)<br /> #:*Quantities (e.g. maximum available time, error rate, precision)<br /> #:*Special condition(s) of the context of use under which the use takes place<br /> #Sources of quantitative user requirements<br /> #:*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.”)<br /> #:*Stakeholders who define acceptance criteria for the usability of an interactive system (e.g. for a usability test)<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ====Example in SAMS context====<br /> 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.</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Decision_Support_System&diff=2887 2020-12-16T17:55:15Z

<p>Perempuangimbal: Created page with &quot;==SAMS Decision Support System (DSS)== The Decision Support System (DSS) is one of the main results of the SAMS project. DSS is … (How it suppose to help beekeepers as end-u...&quot;</p> <hr /> <div>==SAMS Decision Support System (DSS)==<br /> The Decision Support System (DSS) is one of the main results of the SAMS project. DSS is …<br /> (How it suppose to help beekeepers as end-users)<br /> <br /> ==The DSS User Interface==<br /> The DSS SAMS user interface for beekeepers is based on the user research. It was scribbled and prioritized during the UCD SAMS prototyping workshop in Bandung, July 2019. The user interface (UI) prototype of the DSS SAMS data display for beekeepers (for mobile devices) was then developed in Figma software by CV.PI. The iterative development process was discussed during regular virtual meetings dedicated to this topic with the SAMS partner and consortium members; UNILV, GIZ and ICEADDIS. According to the usability tests with four Ethiopian and five Indonesian beekeepers (end-users), the interface prototype (in English, Amharic and Bahasa Indonesia) was refined. The user interface prototype in English, Amharic and Bahasa Indonesia in 8 iterations with 2 design versions of the SAMS data display for beekeepers is available open-source for further elaboration and for developing an app to facilitate a business.</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Personas&diff=2886 2020-12-16T17:48:41Z

<p>Perempuangimbal: </p> <hr /> <div>The created [[UCD Glossary|personas]] helped the UCD team as well as the complete SAMS project team to understand and analyse beekeeper needs better to develop SAMS products further.<br /> “Persona is a description of a user and what he or she intends to do when using an interactive system. Personas are not real; they are examples invented to stand for 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.” &lt;ref&gt;uxqb.org&lt;/ref&gt;<br /> &lt;br&gt;<br /> The SAMS monitoring system development depends on the beekeepers’ background and context factors, for example, [[#Types of Modern Beehives|types of modern beehives]] they use, bee types they breed, electricity availability in their beekeeping site, and how deep they are personally influenced by beekeeping traditions and by their cultural environment and family traditions.<br /> Based on the results of the context of use analysis in the Field Research (Stage 1), following personas, collectively represent the major behaviours of beekeepers in Ethiopia and Indonesia.<br /> <br /> == Ethiopia ==<br /> === Tadesse, Aberash and Degen ===<br /> &lt;br&gt;<br /> [[File:EthiopianPersonas.JPG|frame|center|Ethiopian beekeeper personas.]]<br /> &lt;br&gt;<br /> * Tadese represents beekeepers in the countryside which usually rely on their instincts and the traditional way of beekeeping;<br /> * Aberash represents small-scale modern beekeepers, living in small towns or suburbs of the cites;<br /> * Degen represents a modern beekeeper who is interested in large scale beekeeping and high financial incentive.<br /> &lt;br&gt;<br /> The Ethiopian personas are keeping ''Apis mellifera'', which is the only bee species in the country. Tadese uses a homemade traditional beehive, the traditional beehive requires very low cost and a minimum management effort to operate but it is very low in productivity. The volumes per harvest is very low comparing to modern beehives. Most of the honey harvested is consumed within Tadese's family, a little portion of the honey goes to the local market. Aberash is a modern beekeeper, she has 15 to 20 modern beehives and works as a professional beekeeper. She is skilled using modern beekeeping equipment with combining the traditional ways of beekeeping. She offers her services to other fellow beekeepers and gains moderate financial benefit from her profession. Degen is a commercial beekeeper with a major interest in large scale honey production. He has good knowledge about the market value of honey and honey product distribution. He hires beekeeping professionals like Aberash to manage his apiaries and mostly focuses on the market dynamics of the honey products.<br /> <br /> == Indonesia ==<br /> <br /> === Kurt, Giuseppe, Dicky and Elsa ===<br /> &lt;br&gt;<br /> [[File:IndonesiaPersonas.JPG|frame|center|Indonesian beekeeper personas.]]<br /> &lt;br&gt;<br /> Kurt and Giuseppe are beekeepers who live in remote and rural areas of West Java. Though both are grassroots beekeepers,<br /> * Kurt represents the majority of the grassroot beekeepers who have limited access to stakeholders’ support; he often does his beekeeping activities with fellow grassroot beekeepers in his neighbourhood; he usually builds his beehives with recycled material (the “DIY” beehive type), each hives’ dimension may vary;<br /> * Giuseppe, though he lives close to Kurt, is privileged with his status as a member of the government’s office staff; this position benefits him with more access to the beekeeping sector’s stakeholders.<br /> Dicky and Elsa represent the young generations of beekeepers,<br /> * Dicky grows up in a beekeeper family with generations of experience; his grandfather and father are beekeepers, so it is only natural for him to continue this tradition, despite his young age; born as a digital native, Dicky uses his social media presence to promote his activities and his family business;<br /> * Elsa, unlike the previously described personas, has no beekeeping tradition in her family; she is a curious millennial who wants to contribute in all possible ways to protect the environment, including keeping bees.<br /> <br /> ==== Types of Modern Beehives ====<br /> <br /> The beekeepers work with different types of bees and modern beehives. Kurt mostly keeps ''Apis cerana'', Giuseppe and Dicky have several colonies of ''Apis mellifera'', ''Apis cerana'', and ''Trigona'' spp. (stingless bee). While for Elsa, who lives in the city, it makes more sense to keep ''Trigona'', the stingless bee – not only because it is stingless, but also its small size helps Elsa maintaining the colony easily. Kurt, Giuseppe, and Dicky have a professional interest in harvesting honey as it is one of their sources of income, Elsa harvests honey for her consumption only.<br /> &lt;br&gt;<br /> [[File:MitaIllustrationsBeehives.png|600px|thumb|center|Types of modern beehives in Indonesia.]]<br /> &lt;br&gt;<br /> After further user research, the Indonesian personas were refined. Elsa, Dicky, Giuseppe and Kurt were removed mainly because of the SAMS product development’s focus, which is more suiting to other types of beekeepers.<br /> <br /> === Usep and Sopian ===<br /> <br /> [[File:IndonesiaPersonasrefined.JPG|frame|center|Refined personas in Indonesia.]]<br /> <br /> Meet Usep, a 53 years old grassroots beekeeper living in a remote village, a two-hour drive from Ciamis Regency in West Java. Ciamis itself is a regency area 117 kilometres away from Bandung, the capital city of West Java. His mother tongue is Sundanese and he does not speak or understand English. He does bee hunting in the forest with his fellow beekeepers. He owns not more than 20 various types of modern beehives and bee types. His beekeeping methods are passed down from his mentors. He increased his beekeeping skills through shared beekeeping practices of the beekeeping community’s Facebook group. He is a smartphone user, like any other beekeeper in his circle. He uses his smartphone mostly for socializing via WhatsApp or Facebook. Not only promoting his products, he often shares his thoughts, perspectives, or complaints regarding political or social issues through WhatsApp and uses Facebook posts to promote his beekeeping activities.<br /> Meet Sopian, a 40 years old beekeeper who lives in the peri-urban area near Bandung, the capital city of West Java. He started beekeeping when he was 17 years old. He got his beekeeping knowledge from his brother and perfecting it along the way. Aside from being a beekeeper, Sopian also works as a government officer in the Regency Office. He is doing beekeeping whenever he is off duty from his office work and during weekends. Like Usep, Sopian also uses a smartphone to socialize and sell his harvested honey. Sopian creates a network of beekeepers in several rural areas near his place and considers them as his partners. Sopian will teach them his way of beekeeping, support them with logistics like modern beehives, and when the harvesting time is coming, he will help them sell their harvested honey as well with fair profit sharing. Though he is confident with his beekeeping method, Sopian eagerly learns new ways and new things related to beekeeping practices, including integrating technology in beekeeping. For selling his honey, he built a small counter in front of his house. Visitors are also welcome to discuss bee-related knowledge.<br /> &lt;br&gt;<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Personas&diff=2885 2020-12-16T17:48:08Z

<p>Perempuangimbal: </p> <hr /> <div>The created [[UCD Glossary|personas]] helped the UCD team as well as the complete SAMS project team to understand and analyse beekeeper needs better to develop SAMS products further.<br /> “Persona is a description of a user and what he or she intends to do when using an interactive system. Personas are not real; they are examples invented to stand for 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.” &lt;ref&gt;uxqb.org&lt;/ref&gt;<br /> &lt;br&gt;<br /> The SAMS monitoring system development depends on the beekeepers’ background and context factors, for example, [[#Types of modern beehives|types of modern beehives]] they use, bee types they breed, electricity availability in their beekeeping site, and how deep they are personally influenced by beekeeping traditions and by their cultural environment and family traditions.<br /> Based on the results of the context of use analysis in the Field Research (Stage 1), following personas, collectively represent the major behaviours of beekeepers in Ethiopia and Indonesia.<br /> <br /> == Ethiopia ==<br /> === Tadesse, Aberash and Degen ===<br /> &lt;br&gt;<br /> [[File:EthiopianPersonas.JPG|frame|center|Ethiopian beekeeper personas.]]<br /> &lt;br&gt;<br /> * Tadese represents beekeepers in the countryside which usually rely on their instincts and the traditional way of beekeeping;<br /> * Aberash represents small-scale modern beekeepers, living in small towns or suburbs of the cites;<br /> * Degen represents a modern beekeeper who is interested in large scale beekeeping and high financial incentive.<br /> &lt;br&gt;<br /> The Ethiopian personas are keeping ''Apis mellifera'', which is the only bee species in the country. Tadese uses a homemade traditional beehive, the traditional beehive requires very low cost and a minimum management effort to operate but it is very low in productivity. The volumes per harvest is very low comparing to modern beehives. Most of the honey harvested is consumed within Tadese's family, a little portion of the honey goes to the local market. Aberash is a modern beekeeper, she has 15 to 20 modern beehives and works as a professional beekeeper. She is skilled using modern beekeeping equipment with combining the traditional ways of beekeeping. She offers her services to other fellow beekeepers and gains moderate financial benefit from her profession. Degen is a commercial beekeeper with a major interest in large scale honey production. He has good knowledge about the market value of honey and honey product distribution. He hires beekeeping professionals like Aberash to manage his apiaries and mostly focuses on the market dynamics of the honey products.<br /> <br /> == Indonesia ==<br /> <br /> === Kurt, Giuseppe, Dicky and Elsa ===<br /> &lt;br&gt;<br /> [[File:IndonesiaPersonas.JPG|frame|center|Indonesian beekeeper personas.]]<br /> &lt;br&gt;<br /> Kurt and Giuseppe are beekeepers who live in remote and rural areas of West Java. Though both are grassroots beekeepers,<br /> * Kurt represents the majority of the grassroot beekeepers who have limited access to stakeholders’ support; he often does his beekeeping activities with fellow grassroot beekeepers in his neighbourhood; he usually builds his beehives with recycled material (the “DIY” beehive type), each hives’ dimension may vary;<br /> * Giuseppe, though he lives close to Kurt, is privileged with his status as a member of the government’s office staff; this position benefits him with more access to the beekeeping sector’s stakeholders.<br /> Dicky and Elsa represent the young generations of beekeepers,<br /> * Dicky grows up in a beekeeper family with generations of experience; his grandfather and father are beekeepers, so it is only natural for him to continue this tradition, despite his young age; born as a digital native, Dicky uses his social media presence to promote his activities and his family business;<br /> * Elsa, unlike the previously described personas, has no beekeeping tradition in her family; she is a curious millennial who wants to contribute in all possible ways to protect the environment, including keeping bees.<br /> <br /> ==== Types of Modern Beehives ====<br /> <br /> The beekeepers work with different types of bees and modern beehives. Kurt mostly keeps ''Apis cerana'', Giuseppe and Dicky have several colonies of ''Apis mellifera'', ''Apis cerana'', and ''Trigona'' spp. (stingless bee). While for Elsa, who lives in the city, it makes more sense to keep ''Trigona'', the stingless bee – not only because it is stingless, but also its small size helps Elsa maintaining the colony easily. Kurt, Giuseppe, and Dicky have a professional interest in harvesting honey as it is one of their sources of income, Elsa harvests honey for her consumption only.<br /> &lt;br&gt;<br /> [[File:MitaIllustrationsBeehives.png|600px|thumb|center|Types of modern beehives in Indonesia.]]<br /> &lt;br&gt;<br /> After further user research, the Indonesian personas were refined. Elsa, Dicky, Giuseppe and Kurt were removed mainly because of the SAMS product development’s focus, which is more suiting to other types of beekeepers.<br /> <br /> === Usep and Sopian ===<br /> <br /> [[File:IndonesiaPersonasrefined.JPG|frame|center|Refined personas in Indonesia.]]<br /> <br /> Meet Usep, a 53 years old grassroots beekeeper living in a remote village, a two-hour drive from Ciamis Regency in West Java. Ciamis itself is a regency area 117 kilometres away from Bandung, the capital city of West Java. His mother tongue is Sundanese and he does not speak or understand English. He does bee hunting in the forest with his fellow beekeepers. He owns not more than 20 various types of modern beehives and bee types. His beekeeping methods are passed down from his mentors. He increased his beekeeping skills through shared beekeeping practices of the beekeeping community’s Facebook group. He is a smartphone user, like any other beekeeper in his circle. He uses his smartphone mostly for socializing via WhatsApp or Facebook. Not only promoting his products, he often shares his thoughts, perspectives, or complaints regarding political or social issues through WhatsApp and uses Facebook posts to promote his beekeeping activities.<br /> Meet Sopian, a 40 years old beekeeper who lives in the peri-urban area near Bandung, the capital city of West Java. He started beekeeping when he was 17 years old. He got his beekeeping knowledge from his brother and perfecting it along the way. Aside from being a beekeeper, Sopian also works as a government officer in the Regency Office. He is doing beekeeping whenever he is off duty from his office work and during weekends. Like Usep, Sopian also uses a smartphone to socialize and sell his harvested honey. Sopian creates a network of beekeepers in several rural areas near his place and considers them as his partners. Sopian will teach them his way of beekeeping, support them with logistics like modern beehives, and when the harvesting time is coming, he will help them sell their harvested honey as well with fair profit sharing. Though he is confident with his beekeeping method, Sopian eagerly learns new ways and new things related to beekeeping practices, including integrating technology in beekeeping. For selling his honey, he built a small counter in front of his house. Visitors are also welcome to discuss bee-related knowledge.<br /> &lt;br&gt;<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Personas&diff=2884 2020-12-16T17:46:44Z

<p>Perempuangimbal: </p> <hr /> <div>The created [[UCD Glossary|personas]] helped the UCD team as well as the complete SAMS project team to understand and analyse beekeeper needs better to develop SAMS products further.<br /> “Persona is a description of a user and what he or she intends to do when using an interactive system. Personas are not real; they are examples invented to stand for 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.” &lt;ref&gt;uxqb.org&lt;/ref&gt;<br /> &lt;br&gt;<br /> The SAMS monitoring system development depends on the beekeepers’ background and context factors, for example, [[#types of modern beehives|types of modern beehives]] they use, bee types they breed, electricity availability in their beekeeping site, and how deep they are personally influenced by beekeeping traditions and by their cultural environment and family traditions.<br /> Based on the results of the context of use analysis in the Field Research (Stage 1), following personas, collectively represent the major behaviours of beekeepers in Ethiopia and Indonesia.<br /> <br /> == Ethiopia ==<br /> === Tadesse, Aberash and Degen ===<br /> &lt;br&gt;<br /> [[File:EthiopianPersonas.JPG|frame|center|Ethiopian beekeeper personas.]]<br /> &lt;br&gt;<br /> * Tadese represents beekeepers in the countryside which usually rely on their instincts and the traditional way of beekeeping;<br /> * Aberash represents small-scale modern beekeepers, living in small towns or suburbs of the cites;<br /> * Degen represents a modern beekeeper who is interested in large scale beekeeping and high financial incentive.<br /> &lt;br&gt;<br /> The Ethiopian personas are keeping ''Apis mellifera'', which is the only bee species in the country. Tadese uses a homemade traditional beehive, the traditional beehive requires very low cost and a minimum management effort to operate but it is very low in productivity. The volumes per harvest is very low comparing to modern beehives. Most of the honey harvested is consumed within Tadese's family, a little portion of the honey goes to the local market. Aberash is a modern beekeeper, she has 15 to 20 modern beehives and works as a professional beekeeper. She is skilled using modern beekeeping equipment with combining the traditional ways of beekeeping. She offers her services to other fellow beekeepers and gains moderate financial benefit from her profession. Degen is a commercial beekeeper with a major interest in large scale honey production. He has good knowledge about the market value of honey and honey product distribution. He hires beekeeping professionals like Aberash to manage his apiaries and mostly focuses on the market dynamics of the honey products.<br /> <br /> == Indonesia ==<br /> <br /> === Kurt, Giuseppe, Dicky and Elsa ===<br /> &lt;br&gt;<br /> [[File:IndonesiaPersonas.JPG|frame|center|Indonesian beekeeper personas.]]<br /> &lt;br&gt;<br /> Kurt and Giuseppe are beekeepers who live in remote and rural areas of West Java. Though both are grassroots beekeepers,<br /> * Kurt represents the majority of the grassroot beekeepers who have limited access to stakeholders’ support; he often does his beekeeping activities with fellow grassroot beekeepers in his neighbourhood; he usually builds his beehives with recycled material (the “DIY” beehive type), each hives’ dimension may vary;<br /> * Giuseppe, though he lives close to Kurt, is privileged with his status as a member of the government’s office staff; this position benefits him with more access to the beekeeping sector’s stakeholders.<br /> Dicky and Elsa represent the young generations of beekeepers,<br /> * Dicky grows up in a beekeeper family with generations of experience; his grandfather and father are beekeepers, so it is only natural for him to continue this tradition, despite his young age; born as a digital native, Dicky uses his social media presence to promote his activities and his family business;<br /> * Elsa, unlike the previously described personas, has no beekeeping tradition in her family; she is a curious millennial who wants to contribute in all possible ways to protect the environment, including keeping bees.<br /> <br /> ==== Types of Modern Beehives ====<br /> <br /> The beekeepers work with different types of bees and modern beehives. Kurt mostly keeps ''Apis cerana'', Giuseppe and Dicky have several colonies of ''Apis mellifera'', ''Apis cerana'', and ''Trigona'' spp. (stingless bee). While for Elsa, who lives in the city, it makes more sense to keep ''Trigona'', the stingless bee – not only because it is stingless, but also its small size helps Elsa maintaining the colony easily. Kurt, Giuseppe, and Dicky have a professional interest in harvesting honey as it is one of their sources of income, Elsa harvests honey for her consumption only.<br /> &lt;br&gt;<br /> [[File:MitaIllustrationsBeehives.png|600px|thumb|center|Types of modern beehives in Indonesia.]]<br /> &lt;br&gt;<br /> After further user research, the Indonesian personas were refined. Elsa, Dicky, Giuseppe and Kurt were removed mainly because of the SAMS product development’s focus, which is more suiting to other types of beekeepers.<br /> <br /> === Usep and Sopian ===<br /> <br /> [[File:IndonesiaPersonasrefined.JPG|frame|center|Refined personas in Indonesia.]]<br /> <br /> Meet Usep, a 53 years old grassroots beekeeper living in a remote village, a two-hour drive from Ciamis Regency in West Java. Ciamis itself is a regency area 117 kilometres away from Bandung, the capital city of West Java. His mother tongue is Sundanese and he does not speak or understand English. He does bee hunting in the forest with his fellow beekeepers. He owns not more than 20 various types of modern beehives and bee types. His beekeeping methods are passed down from his mentors. He increased his beekeeping skills through shared beekeeping practices of the beekeeping community’s Facebook group. He is a smartphone user, like any other beekeeper in his circle. He uses his smartphone mostly for socializing via WhatsApp or Facebook. Not only promoting his products, he often shares his thoughts, perspectives, or complaints regarding political or social issues through WhatsApp and uses Facebook posts to promote his beekeeping activities.<br /> Meet Sopian, a 40 years old beekeeper who lives in the peri-urban area near Bandung, the capital city of West Java. He started beekeeping when he was 17 years old. He got his beekeeping knowledge from his brother and perfecting it along the way. Aside from being a beekeeper, Sopian also works as a government officer in the Regency Office. He is doing beekeeping whenever he is off duty from his office work and during weekends. Like Usep, Sopian also uses a smartphone to socialize and sell his harvested honey. Sopian creates a network of beekeepers in several rural areas near his place and considers them as his partners. Sopian will teach them his way of beekeeping, support them with logistics like modern beehives, and when the harvesting time is coming, he will help them sell their harvested honey as well with fair profit sharing. Though he is confident with his beekeeping method, Sopian eagerly learns new ways and new things related to beekeeping practices, including integrating technology in beekeeping. For selling his honey, he built a small counter in front of his house. Visitors are also welcome to discuss bee-related knowledge.<br /> &lt;br&gt;<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Personas&diff=2883 2020-12-16T17:39:43Z

<p>Perempuangimbal: </p> <hr /> <div>The created [[UCD Glossary|personas]] helped the UCD team as well as the complete SAMS project team to understand and analyse beekeeper needs better to develop SAMS products further.<br /> “Persona is a description of a user and what he or she intends to do when using an interactive system. Personas are not real; they are examples invented to stand for 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.” &lt;ref&gt;uxqb.org&lt;/ref&gt;<br /> &lt;br&gt;<br /> The SAMS monitoring system development depends on the beekeepers’ background and context factors, for example, types of modern beehives they use, bee types they breed, electricity availability in their beekeeping site, and how deep they are personally influenced by beekeeping traditions and by their cultural environment and family traditions.<br /> Based on the results of the context of use analysis in the Field Research (Stage 1), following personas, collectively represent the major behaviours of beekeepers in Ethiopia and Indonesia.<br /> <br /> == Ethiopia ==<br /> === Tadesse, Aberash and Degen ===<br /> &lt;br&gt;<br /> [[File:EthiopianPersonas.JPG|frame|center|Ethiopian beekeeper personas.]]<br /> &lt;br&gt;<br /> * Tadese represents beekeepers in the countryside which usually rely on their instincts and the traditional way of beekeeping;<br /> * Aberash represents small-scale modern beekeepers, living in small towns or suburbs of the cites;<br /> * Degen represents a modern beekeeper who is interested in large scale beekeeping and high financial incentive.<br /> &lt;br&gt;<br /> The Ethiopian personas are keeping ''Apis mellifera'', which is the only bee species in the country. Tadese uses a homemade traditional beehive, the traditional beehive requires very low cost and a minimum management effort to operate but it is very low in productivity. The volumes per harvest is very low comparing to modern beehives. Most of the honey harvested is consumed within Tadese's family, a little portion of the honey goes to the local market. Aberash is a modern beekeeper, she has 15 to 20 modern beehives and works as a professional beekeeper. She is skilled using modern beekeeping equipment with combining the traditional ways of beekeeping. She offers her services to other fellow beekeepers and gains moderate financial benefit from her profession. Degen is a commercial beekeeper with a major interest in large scale honey production. He has good knowledge about the market value of honey and honey product distribution. He hires beekeeping professionals like Aberash to manage his apiaries and mostly focuses on the market dynamics of the honey products.<br /> <br /> == Indonesia ==<br /> <br /> === Kurt, Giuseppe, Dicky and Elsa ===<br /> &lt;br&gt;<br /> [[File:IndonesiaPersonas.JPG|frame|center|Indonesian beekeeper personas.]]<br /> &lt;br&gt;<br /> Kurt and Giuseppe are beekeepers who live in remote and rural areas of West Java. Though both are grassroots beekeepers,<br /> * Kurt represents the majority of the grassroot beekeepers who have limited access to stakeholders’ support; he often does his beekeeping activities with fellow grassroot beekeepers in his neighbourhood; he usually builds his beehives with recycled material (the “DIY” beehive type), each hives’ dimension may vary;<br /> * Giuseppe, though he lives close to Kurt, is privileged with his status as a member of the government’s office staff; this position benefits him with more access to the beekeeping sector’s stakeholders.<br /> Dicky and Elsa represent the young generations of beekeepers,<br /> * Dicky grows up in a beekeeper family with generations of experience; his grandfather and father are beekeepers, so it is only natural for him to continue this tradition, despite his young age; born as a digital native, Dicky uses his social media presence to promote his activities and his family business;<br /> * Elsa, unlike the previously described personas, has no beekeeping tradition in her family; she is a curious millennial who wants to contribute in all possible ways to protect the environment, including keeping bees.<br /> <br /> ==== Types of Modern Beehives ====<br /> <br /> The beekeepers work with different types of bees and modern beehives. Kurt mostly keeps ''Apis cerana'', Giuseppe and Dicky have several colonies of ''Apis mellifera'', ''Apis cerana'', and ''Trigona'' spp. (stingless bee). While for Elsa, who lives in the city, it makes more sense to keep ''Trigona'', the stingless bee – not only because it is stingless, but also its small size helps Elsa maintaining the colony easily. Kurt, Giuseppe, and Dicky have a professional interest in harvesting honey as it is one of their sources of income, Elsa harvests honey for her consumption only.<br /> &lt;br&gt;<br /> [[File:MitaIllustrationsBeehives.png|600px|thumb|center|Types of modern beehives in Indonesia.]]<br /> &lt;br&gt;<br /> After further user research, the Indonesian personas were refined. Elsa, Dicky, Giuseppe and Kurt were removed mainly because of the SAMS product development’s focus, which is more suiting to other types of beekeepers.<br /> <br /> === Usep and Sopian ===<br /> <br /> [[File:IndonesiaPersonasrefined.JPG|frame|center|Refined personas in Indonesia.]]<br /> <br /> Meet Usep, a 53 years old grassroots beekeeper living in a remote village, a two-hour drive from Ciamis Regency in West Java. Ciamis itself is a regency area 117 kilometres away from Bandung, the capital city of West Java. His mother tongue is Sundanese and he does not speak or understand English. He does bee hunting in the forest with his fellow beekeepers. He owns not more than 20 various types of modern beehives and bee types. His beekeeping methods are passed down from his mentors. He increased his beekeeping skills through shared beekeeping practices of the beekeeping community’s Facebook group. He is a smartphone user, like any other beekeeper in his circle. He uses his smartphone mostly for socializing via WhatsApp or Facebook. Not only promoting his products, he often shares his thoughts, perspectives, or complaints regarding political or social issues through WhatsApp and uses Facebook posts to promote his beekeeping activities.<br /> Meet Sopian, a 40 years old beekeeper who lives in the peri-urban area near Bandung, the capital city of West Java. He started beekeeping when he was 17 years old. He got his beekeeping knowledge from his brother and perfecting it along the way. Aside from being a beekeeper, Sopian also works as a government officer in the Regency Office. He is doing beekeeping whenever he is off duty from his office work and during weekends. Like Usep, Sopian also uses a smartphone to socialize and sell his harvested honey. Sopian creates a network of beekeepers in several rural areas near his place and considers them as his partners. Sopian will teach them his way of beekeeping, support them with logistics like modern beehives, and when the harvesting time is coming, he will help them sell their harvested honey as well with fair profit sharing. Though he is confident with his beekeeping method, Sopian eagerly learns new ways and new things related to beekeeping practices, including integrating technology in beekeeping. For selling his honey, he built a small counter in front of his house. Visitors are also welcome to discuss bee-related knowledge.<br /> &lt;br&gt;<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Personas&diff=2882 2020-12-16T17:36:56Z

<p>Perempuangimbal: </p> <hr /> <div>The created personas helped the UCD team as well as the complete SAMS project team to understand and analyse beekeeper needs better to develop SAMS products further.<br /> “Persona is a description of a user and what he or she intends to do when using an interactive system. Personas are not real; they are examples invented to stand for 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.” &lt;ref&gt;uxqb.org&lt;/ref&gt;<br /> &lt;br&gt;<br /> The SAMS monitoring system development depends on the beekeepers’ background and context factors, for example, types of modern beehives they use, bee types they breed, electricity availability in their beekeeping site, and how deep they are personally influenced by beekeeping traditions and by their cultural environment and family traditions.<br /> Based on the results of the context of use analysis in the Field Research (Stage 1), following personas, collectively represent the major behaviours of beekeepers in Ethiopia and Indonesia.<br /> <br /> == Ethiopia ==<br /> === Tadesse, Aberash and Degen ===<br /> &lt;br&gt;<br /> [[File:EthiopianPersonas.JPG|frame|center|Ethiopian beekeeper personas.]]<br /> &lt;br&gt;<br /> * Tadese represents beekeepers in the countryside which usually rely on their instincts and the traditional way of beekeeping;<br /> * Aberash represents small-scale modern beekeepers, living in small towns or suburbs of the cites;<br /> * Degen represents a modern beekeeper who is interested in large scale beekeeping and high financial incentive.<br /> &lt;br&gt;<br /> The Ethiopian personas are keeping ''Apis mellifera'', which is the only bee species in the country. Tadese uses a homemade traditional beehive, the traditional beehive requires very low cost and a minimum management effort to operate but it is very low in productivity. The volumes per harvest is very low comparing to modern beehives. Most of the honey harvested is consumed within Tadese's family, a little portion of the honey goes to the local market. Aberash is a modern beekeeper, she has 15 to 20 modern beehives and works as a professional beekeeper. She is skilled using modern beekeeping equipment with combining the traditional ways of beekeeping. She offers her services to other fellow beekeepers and gains moderate financial benefit from her profession. Degen is a commercial beekeeper with a major interest in large scale honey production. He has good knowledge about the market value of honey and honey product distribution. He hires beekeeping professionals like Aberash to manage his apiaries and mostly focuses on the market dynamics of the honey products.<br /> <br /> == Indonesia ==<br /> <br /> === Kurt, Giuseppe, Dicky and Elsa ===<br /> &lt;br&gt;<br /> [[File:IndonesiaPersonas.JPG|frame|center|Indonesian beekeeper personas.]]<br /> &lt;br&gt;<br /> Kurt and Giuseppe are beekeepers who live in remote and rural areas of West Java. Though both are grassroots beekeepers,<br /> * Kurt represents the majority of the grassroot beekeepers who have limited access to stakeholders’ support; he often does his beekeeping activities with fellow grassroot beekeepers in his neighbourhood; he usually builds his beehives with recycled material (the “DIY” beehive type), each hives’ dimension may vary;<br /> * Giuseppe, though he lives close to Kurt, is privileged with his status as a member of the government’s office staff; this position benefits him with more access to the beekeeping sector’s stakeholders.<br /> Dicky and Elsa represent the young generations of beekeepers,<br /> * Dicky grows up in a beekeeper family with generations of experience; his grandfather and father are beekeepers, so it is only natural for him to continue this tradition, despite his young age; born as a digital native, Dicky uses his social media presence to promote his activities and his family business;<br /> * Elsa, unlike the previously described personas, has no beekeeping tradition in her family; she is a curious millennial who wants to contribute in all possible ways to protect the environment, including keeping bees.<br /> <br /> ==== Types of Modern Beehives ====<br /> <br /> The beekeepers work with different types of bees and modern beehives. Kurt mostly keeps ''Apis cerana'', Giuseppe and Dicky have several colonies of ''Apis mellifera'', ''Apis cerana'', and ''Trigona'' spp. (stingless bee). While for Elsa, who lives in the city, it makes more sense to keep ''Trigona'', the stingless bee – not only because it is stingless, but also its small size helps Elsa maintaining the colony easily. Kurt, Giuseppe, and Dicky have a professional interest in harvesting honey as it is one of their sources of income, Elsa harvests honey for her consumption only.<br /> &lt;br&gt;<br /> [[File:MitaIllustrationsBeehives.png|600px|thumb|center|Types of modern beehives in Indonesia.]]<br /> &lt;br&gt;<br /> After further user research, the Indonesian personas were refined. Elsa, Dicky, Giuseppe and Kurt were removed mainly because of the SAMS product development’s focus, which is more suiting to other types of beekeepers.<br /> <br /> === Usep and Sopian ===<br /> <br /> [[File:IndonesiaPersonasrefined.JPG|frame|center|Refined personas in Indonesia.]]<br /> <br /> Meet Usep, a 53 years old grassroots beekeeper living in a remote village, a two-hour drive from Ciamis Regency in West Java. Ciamis itself is a regency area 117 kilometres away from Bandung, the capital city of West Java. His mother tongue is Sundanese and he does not speak or understand English. He does bee hunting in the forest with his fellow beekeepers. He owns not more than 20 various types of modern beehives and bee types. His beekeeping methods are passed down from his mentors. He increased his beekeeping skills through shared beekeeping practices of the beekeeping community’s Facebook group. He is a smartphone user, like any other beekeeper in his circle. He uses his smartphone mostly for socializing via WhatsApp or Facebook. Not only promoting his products, he often shares his thoughts, perspectives, or complaints regarding political or social issues through WhatsApp and uses Facebook posts to promote his beekeeping activities.<br /> Meet Sopian, a 40 years old beekeeper who lives in the peri-urban area near Bandung, the capital city of West Java. He started beekeeping when he was 17 years old. He got his beekeeping knowledge from his brother and perfecting it along the way. Aside from being a beekeeper, Sopian also works as a government officer in the Regency Office. He is doing beekeeping whenever he is off duty from his office work and during weekends. Like Usep, Sopian also uses a smartphone to socialize and sell his harvested honey. Sopian creates a network of beekeepers in several rural areas near his place and considers them as his partners. Sopian will teach them his way of beekeeping, support them with logistics like modern beehives, and when the harvesting time is coming, he will help them sell their harvested honey as well with fair profit sharing. Though he is confident with his beekeeping method, Sopian eagerly learns new ways and new things related to beekeeping practices, including integrating technology in beekeeping. For selling his honey, he built a small counter in front of his house. Visitors are also welcome to discuss bee-related knowledge.<br /> &lt;br&gt;<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=SAMS_-_Personas&diff=2881 2020-12-16T17:18:31Z

<p>Perempuangimbal: </p> <hr /> <div>The created personas helped the UCD team as well as the complete SAMS project team to understand and analyse beekeeper needs better to develop SAMS products further.<br /> “Persona is a description of a user and what he or she intends to do when using an interactive system. Personas are not real; they are examples invented to stand for 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.” &lt;ref&gt;uxqb.org&lt;/ref&gt;<br /> &lt;br&gt;<br /> The SAMS monitoring system development depends on the beekeepers’ background and context factors, for example, types of modern beehives they use, bee types they breed, electricity availability in their beekeeping site, and how deep they are personally influenced by beekeeping traditions and by their cultural environment and family traditions.<br /> Based on results of the context of use analysis in the Field Research (Stage 1), following personas, collectively represent the major behaviours of beekeepers in Ethiopia and Indonesia.<br /> Meet Tadesse, Aberash and Degen from Ethiopia:<br /> &lt;br&gt;<br /> [[File:EthiopianPersonas.JPG|frame|center|Ethiopian beekeeper personas.]]<br /> &lt;br&gt;<br /> * Tadese represents beekeepers in the countryside which usually rely on their instincts and the traditional way of beekeeping;<br /> * Aberash represents small-scale modern beekeepers, living in small towns or suburbs of the cites;<br /> * Degen represents a modern beekeeper who is interested in large scale beekeeping and high financial incentive.<br /> &lt;br&gt;<br /> The Ethiopian personas are keeping ''Apis mellifera'', which is the only bee species in the country. Tadese uses a homemade traditional beehive, the traditional beehive requires very low cost and a minimum management effort to operate but it is very low in productivity. The volumes per harvest is very low comparing to modern beehives. Most of the honey harvested is consumed within Tadese's family, a little portion of the honey goes to the local market. Aberash is a modern beekeeper, she has 15 to 20 modern beehives and works as a professional beekeeper. She is skilled using modern beekeeping equipment with combining the traditional ways of beekeeping. She offers her services to other fellow beekeepers and gains moderate financial benefit from her profession. Degen is a commercial beekeeper with a major interest in large scale honey production. He has good knowledge about the market value of honey and honey product distribution. He hires beekeeping professionals like Aberash to manage his apiaries and mostly focuses on the market dynamics of the honey products.<br /> &lt;br&gt;<br /> Meet Kurt, Giuseppe, Dicky and Elsa from Indonesia:&lt;br&gt;<br /> [[File:IndonesiaPersonas.JPG|frame|center|Indonesian beekeeper personas.]]<br /> &lt;br&gt;<br /> Kurt and Giuseppe are beekeepers who live in remote and rural areas of West Java. Though both are grassroots beekeepers,<br /> * Kurt represents the majority of the grassroot beekeepers who have limited access to stakeholders’ support; he often does his beekeeping activities with fellow grassroot beekeepers in his neighbourhood; he usually builds his beehives with recycled material (the “DIY” beehive type), each hives’ dimension may vary;<br /> * Giuseppe, though he lives close to Kurt, is privileged with his status as a member of the government’s office staff; this position benefits him with more access to the beekeeping sector’s stakeholders.<br /> Dicky and Elsa represent the young generations of beekeepers,<br /> * Dicky grows up in a beekeeper family with generations of experience; his grandfather and father are beekeepers, so it is only natural for him to continue this tradition, despite his young age; born as a digital native, Dicky uses his social media presence to promote his activities and his family business;<br /> * Elsa, unlike the previously described personas, has no beekeeping tradition in her family; she is a curious millennial who wants to contribute in all possible ways to protect the environment, including keeping bees.<br /> &lt;br&gt;<br /> <br /> The beekeepers work with different types of bees and modern beehives. Kurt mostly keeps ''Apis cerana'', Giuseppe and Dicky have several colonies of ''Apis mellifera'', ''Apis cerana'', and ''Trigona'' spp. (stingless bee). While for Elsa, who lives in the city, it makes more sense to keep ''Trigona'', the stingless bee – not only because it is stingless, but also its small size helps Elsa maintaining the colony easily. Kurt, Giuseppe, and Dicky have a professional interest in harvesting honey as it is one of their sources of income, Elsa harvests honey for her consumption only.<br /> &lt;br&gt;<br /> [[File:MitaIllustrationsBeehives.png|600px|thumb|center|Types of modern beehives in Indonesia.]]<br /> &lt;br&gt;<br /> After further user research, the Indonesian personas were refined. Elsa, Dicky, Giuseppe and Kurt were removed mainly because of the SAMS product development’s focus, which is more suiting to other type of beekeepers like Usep and Sopian:<br /> [[File:IndonesiaPersonasrefined.JPG|frame|center|Refined personas in Indonesia.]]<br /> &lt;br&gt;<br /> Meet Usep, a 53 years old grassroots beekeeper living in a remote village, a two-hour drive from Ciamis Regency in West Java. Ciamis itself is a regency area 117 kilometres away from Bandung, capital city of West Java. His mother tongue is Sundanese and he does not speak or understand English. He does bee hunting in the forest with his fellow beekeepers. He owns not more than 20 various types of modern beehives and bee types. His beekeeping methods are passed down from his mentors. He increased his beekeeping skills through shared beekeeping practices of the beekeeping community’s facebook group. He is a smartphone user, like any other beekeeper in his circle. He uses his smartphone mostly for socializing via WhatsApp or facebook. Not only promoting his products, he often shares his thoughts, perspectives, or complaints regarding political or social issues through WhatsApp and uses facebook posts to promote his beekeeping activities.<br /> Meet Sopian, a 40 years old beekeeper who lives in the peri-urban area near Bandung, capital city of West Java. He started beekeeping when he was 17 years old. He got his beekeeping knowledge from his brother and perfecting it along the way. Aside from being a beekeeper, Sopian also works as a government officer in the Regency Office. He is doing beekeeping whenever he is off duty from his office work and during weekends. Like Usep, Sopian also uses a smartphone to socialize and sell his harvested honey. Sopian creates a network of beekeepers in several rural areas near his place and considers them as his partners. Sopian will teach them his way of beekeeping, support them with logistics like modern beehives, and when the harvesting time is coming, he will help them sell their harvested honey as well with fair profit sharing. Though he is confident with his beekeeping method, Sopian eagerly learns new ways and new things related to beekeeping practices, including integrating technology in beekeeping. For selling his honey, he built a small counter in front of his house. Visitors are also welcome to discuss bee-related knowledge.<br /> &lt;br&gt;<br /> <br /> ==References==<br /> &lt;references/&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2880 2020-12-16T17:15:08Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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]].<br /> <br /> == Lean UX ==<br /> ==== Why lean UX for SAMS ====<br /> 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.<br /> <br /> === Definition ===<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> === Definition ===<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ==== Example in SAMS context ====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> === Definition ===<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ==== Example in SAMS context ====<br /> The [[Decision Support System]] must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> <br /> 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.<br /> <br /> === Definition ===<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (uxqb.org)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> (uxqb.org)<br /> <br /> ==== Example in SAMS context ====<br /> <br /> ===== Ethiopia =====<br /> 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.<br /> <br /> ===== Indonesia =====<br /> 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.<br /> <br /> == Product Backlog ==<br /> === Definition ===<br /> ''In the simplest definition, the Scrum Product Backlog is simply a list of all things that need to be done within the project. It replaces the traditional requirements specification artefacts. These items can have a technical nature or can be user-centric e.g. in the form of user stories.''<br /> (scrum-Institute.org)<br /> <br /> == Qualitative User Requirement ==<br /> === Definition ===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes'''<br /> # 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.<br /> # Qualitative user requirements are not features. They provide the basis for features.<br /> # 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”).<br /> # Qualitative user requirements are specified with the aid of the following elements:<br /> #:*[[#User Group|User group]]<br /> #:*Type of usage (recognise, select, input)<br /> #:*Special condition(s) of the context of use for which the [[#user requirement|User Requirement]] is relevant<br /> # Sources of qualitative user requirements<br /> #:*The direct source is always one or more user needs.<br /> #:*Indirect sources:<br /> #:**Human-centred quality objectives<br /> #:**Legal/regulatory requirements<br /> #:**Market requirements<br /> #:**Organisational requirements<br /> #:**Requests<br /> #:**Identified or anticipated problems with usage<br /> #:**Dialogue principles and heuristics that are used for the specification of user requirements<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ==== Example in SAMS Context ====<br /> (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)<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! 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)<br /> |-<br /> | 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)<br /> |}<br /> <br /> == Quantitative User Requirement ==<br /> ===Definition===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes:'''<br /> #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.<br /> #The elements of a quantitative user requirement<br /> #:*The stakeholder who issued the requirement (e.g. employer or legislator)<br /> #:*User group(s) concerned who have to fulfil the requirement during use<br /> #:*The number or percentage of users who have to fulfil the requirement<br /> #:*Object of use (task object (in the user interface), tool)<br /> #:*Quantities (e.g. maximum available time, error rate, precision)<br /> #:*Special condition(s) of the context of use under which the use takes place<br /> #Sources of quantitative user requirements<br /> #:*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.”)<br /> #:*Stakeholders who define acceptance criteria for the usability of an interactive system (e.g. for a usability test)<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ====Example in SAMS context====<br /> 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.</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2879 2020-12-16T16:50:31Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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]].<br /> <br /> == Lean UX ==<br /> ==== Why lean UX for SAMS ====<br /> 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.<br /> <br /> === Definition ===<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> === Definition ===<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ==== Example in SAMS context ====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> === Definition ===<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ==== Example in SAMS context ====<br /> The [[Decision Support System]] must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> <br /> 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.<br /> <br /> === Definition ===<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (uxqb.org)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> (uxqb.org)<br /> <br /> ==== Example in SAMS context ====<br /> <br /> ===== Ethiopia =====<br /> 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.<br /> <br /> ===== Indonesia =====<br /> 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.<br /> <br /> == Product Backlog ==<br /> === Definition ===<br /> ''In the simplest definition, the Scrum Product Backlog is simply a list of all things that need to be done within the project. It replaces the traditional requirements specification artefacts. These items can have a technical nature or can be user-centric e.g. in the form of user stories.''<br /> (scrum-Institute.org)<br /> <br /> == Qualitative User Requirement ==<br /> === Definition ===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes'''<br /> * 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.<br /> * Qualitative user requirements are not features. They provide the basis for features.<br /> * 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”).<br /> * Qualitative user requirements are specified with the aid of the following elements:<br /> *#[[#User Group|User group]]<br /> *#Type of usage (recognise, select, input)<br /> *#Special condition(s) of the context of use for which the [[#user requirement|User Requirement]] is relevant<br /> * Sources of qualitative user requirements<br /> *#The direct source is always one or more user needs.<br /> *#Indirect sources:<br /> *#*Human-centred quality objectives<br /> *#*Legal/regulatory requirements<br /> *#*Market requirements<br /> *#*Organisational requirements<br /> *#*Requests<br /> *#*Identified or anticipated problems with usage<br /> *#*Dialogue principles and heuristics that are used for the specification of user requirements<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> ==== Example in SAMS Context ====<br /> (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)<br /> <br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! 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)<br /> |-<br /> | 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)<br /> |}</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2878 2020-12-16T16:00:58Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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]].<br /> <br /> == Lean UX ==<br /> ==== Why lean UX for SAMS ====<br /> 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.<br /> <br /> === Definition ===<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> === Definition ===<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ==== Example in SAMS context ====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> === Definition ===<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ==== Example in SAMS context ====<br /> The [[Decision Support System]] must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> <br /> 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.<br /> <br /> === Definition ===<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (uxqb.org)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> (uxqb.org)<br /> <br /> ==== Example in SAMS context ====<br /> <br /> ===== Ethiopia =====<br /> 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.<br /> <br /> ===== Indonesia =====<br /> 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.<br /> <br /> == Product Backlog ==<br /> === Definition ===<br /> ''In the simplest definition, the Scrum Product Backlog is simply a list of all things that need to be done within the project. It replaces the traditional requirements specification artefacts. These items can have a technical nature or can be user-centric e.g. in the form of user stories.''<br /> (scrum-Institute.org)<br /> <br /> == Qualitative User Requirement ==<br /> === Definition ===<br /> ''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.''<br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> '''Notes'''<br /> # 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.<br /> # Qualitative user requirements are not features. They provide the basis for features.<br /> # 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”).<br /> # Qualitative user requirements are specified with the aid of the following elements:<br /> * [[#User Group|User group]]<br /> * Type of usage (recognise, select, input)<br /> * Special condition(s) of the context of use for which the [[#user requirement|User Requirement]] is relevant</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2877 2020-12-16T15:46:58Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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.<br /> <br /> == Lean UX ==<br /> ==== Why lean UX for SAMS ====<br /> 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.<br /> <br /> === Definition ===<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> === Definition ===<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ==== Example in SAMS context ====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> === Definition ===<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ==== Example in SAMS context ====<br /> The decision support system must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> <br /> 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.<br /> <br /> === Definition ===<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (uxqb.org)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> (uxqb.org)<br /> <br /> ==== Example in SAMS context ====<br /> <br /> ===== Ethiopia =====<br /> 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.<br /> <br /> ===== Indonesia =====<br /> 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.</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2876 2020-12-16T15:44:55Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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.<br /> <br /> == Lean UX ==<br /> ==== Why lean UX for SAMS ====<br /> 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.<br /> <br /> === Definition ===<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> === Definition ===<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ==== Example in SAMS context ====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> === Definition ===<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ==== Example in SAMS context ====<br /> The decision support system must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> <br /> 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.<br /> <br /> === Definition ===<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (uxqb.org)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> (uxqb.org)<br /> <br /> ==== Example in SAMS context ====<br /> === Ethiopia ===<br /> 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.<br /> <br /> === Indonesia ===<br /> 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.</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2875 2020-12-16T15:16:44Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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.<br /> <br /> == Lean UX ==<br /> ===== Why lean UX for SAMS =====<br /> 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.<br /> <br /> ==== Definition ====<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> ===== Definition =====<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ===== Example in SAMS context =====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> ===== Definition =====<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ===== Example in SAMS context =====<br /> The decision support system must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> <br /> 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.<br /> <br /> ===== Definition =====<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (https://uxqb.org/en/documents/)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> <br /> (uxqb.org)</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2874 2020-12-16T15:15:23Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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.<br /> <br /> == Lean UX ==<br /> ===== Why lean UX for SAMS =====<br /> 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.<br /> <br /> ==== Definition ====<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> ===== Definition =====<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ===== Example in SAMS context =====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> ===== Definition =====<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ===== Example in SAMS context =====<br /> The decision support system must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> 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.<br /> <br /> ===== Definition =====<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (https://uxqb.org/en/documents/)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> <br /> (uxqb.org)</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2873 2020-12-16T15:12:14Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#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.<br /> <br /> == Lean UX ==<br /> ===== Why lean UX for SAMS =====<br /> 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.<br /> <br /> ===== Definition =====<br /> ''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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> <br /> == Market Requirement ==<br /> ===== Definition =====<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ===== Example in SAMS context =====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Organizational Requirement ==<br /> ===== Definition =====<br /> ''An organisational rule that users have to follow when performing their tasks.''<br /> <br /> '''Notes:'''<br /> # 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.<br /> # 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.”<br /> # 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.<br /> <br /> ===== Example in SAMS context =====<br /> The decision support system must provide all measurement values in metric units in order to meet EU regulations.<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> == Persona ==<br /> '''Remark:''' <br /> 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”.<br /> <br /> 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.<br /> <br /> '''Please Note:''' <br /> 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.<br /> <br /> ===== Definition =====<br /> ''A description of a user and what he or she intends to do when using an '''interactive system'''.''<br /> (https://uxqb.org/en/documents/)<br /> <br /> '''Notes of CPUX-UR Curriculum (uxqb.org):'''<br /> # Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # 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.<br /> # So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.<br /> <br /> '''Quality factors for the development of personas:'''<br /> <br /> # A persona is created by those people who performed the context of use analysis.<br /> # The persona description does not represent a real person but is equivalent to the description of a real person.<br /> # The persona combines characteristics of real users.<br /> # The persona description contains all important characteristics and the most important goals.<br /> # The basis for a persona must be empirical data, it must not be purely imaginary.<br /> # Proto-personas must be clearly labelled as such.<br /> # The number of personas should be 2 to 5 maximum, to be able to efficiently work with them.<br /> # Personas as representations of real users must be checked regularly and modified if necessary, as the context of use can change over time.<br /> # 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.<br /> <br /> (uxqb.org)</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2870 2020-12-16T12:32:45Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#Lean UX]], [[#Market Requirement]], Organizational Requirement, Persona, Product Backlog, Qualitative User Requirement, Quantitative User Requirement, Requirement, Stakeholder Requirement, User Group, User Need, User Requirement, User Role, User Want.<br /> <br /> == Lean UX ==<br /> ===== Why lean UX for SAMS =====<br /> 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.<br /> <br /> ===== Definition =====<br /> ''A keyword used to describe an approach for 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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> 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.<br /> <br /> 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 the further development. See also SCRUM.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Market Requirement ==<br /> ===== Definition =====<br /> ''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.''<br /> <br /> '''Note:'''<br /> Market requirements are often referred to as customer requirements.<br /> <br /> ===== Example in SAMS context =====<br /> 1. “The advisory support system must be at least as usable as those of the two strongest competitors”<br /> <br /> (CPUX-UR – Curriculum (Version 1.3, June 2016))</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2869 2020-12-16T12:27:02Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#Lean UX]], [[#Market Requirement]], Organizational Requirement, Persona, Product Backlog, Qualitative User Requirement, Quantitative User Requirement, Requirement, Stakeholder Requirement, User Group, User Need, User Requirement, User Role, User Want.<br /> <br /> == Lean UX ==<br /> <br /> ===== Why lean UX for SAMS =====<br /> 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.<br /> <br /> ===== Definition =====<br /> ''A keyword used to describe an approach for 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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> 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.<br /> <br /> 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 the further development. See also SCRUM.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Market Requirement ==<br /> ===== Definition =====</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2868 2020-12-16T12:11:36Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#Lean UX]], [[#Market Requirement]], Organizational Requirement, Persona, Product Backlog, Qualitative User Requirement, Quantitative User Requirement, Requirement, Stakeholder Requirement, User Group, User Need, User Requirement, User Role, User Want.<br /> <br /> == Lean UX ==<br /> <br /> ===== Why lean UX for SAMS =====<br /> 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.<br /> <br /> ===== Definition =====<br /> ''A keyword used to describe an approach for 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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> 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.<br /> <br /> 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 the further development. See also SCRUM.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Market Requirement ==</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2867 2020-12-16T12:11:06Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#Lean UX]], [[Market Requirement]], Organizational Requirement, Persona, Product Backlog, Qualitative User Requirement, Quantitative User Requirement, Requirement, Stakeholder Requirement, User Group, User Need, User Requirement, User Role, User Want.<br /> <br /> == Lean UX ==<br /> <br /> ===== Why lean UX for SAMS =====<br /> 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.<br /> <br /> ===== Definition =====<br /> ''A keyword used to describe an approach for 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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> 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.<br /> <br /> 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 the further development. See also SCRUM.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Market Requirement ==</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2866 2020-12-16T12:10:05Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[Lean UX]], [[Market Requirement]], Organizational Requirement, Persona, Product Backlog, Qualitative User Requirement, Quantitative User Requirement, Requirement, Stakeholder Requirement, User Group, User Need, User Requirement, User Role, User Want.<br /> <br /> == Lean UX ==<br /> <br /> ===== Why lean UX for SAMS =====<br /> 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.<br /> <br /> ===== Definition =====<br /> ''A keyword used to describe an approach for 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.''<br /> ( CPUX-UR – Curriculum (Version 1.3, June 2016))<br /> <br /> Notes of CPUX-UR Curriculum (uxqb.org):<br /> <br /> 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.<br /> <br /> 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 the further development. See also SCRUM.<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Market Requirement ==</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2865 2020-12-16T10:35:05Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> [[#Lean UX]], Market Requirement, Organizational Requirement, Persona, Product Backlog, Qualitative User Requirement, Quantitative User Requirement, Requirement, Stakeholder Requirement, User Group, User Need, User Requirement, User Role, User Want.<br /> <br /> ==Lean UX==</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2864 2020-12-16T10:32:30Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> Lean UX, Market Requirement, Organizational Requirement, Persona, Product Backlog, Qualitative User Requirement, Quantitative User Requirement, Requirement, Stakeholder Requirement, User Group, User Need, User Requirement, User Role, User Want.<br /> <br /> ==Lean UX==</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2863 2020-12-16T10:15:58Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> 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.<br /> <br /> These are several terms that are being used during the SAMS project timeline:<br /> Lean UX, Market Requirement, Organizational Requirement, Persona, Product Backlog, Qualitative User Requirement, Quantitative User Requirement, Requirement, Stakeholder Requirement, User Group, User Need, User Requirement, User Role, User Want.<br /> <br /> &lt;big&gt;Lean UX&lt;/big&gt;</div>

Perempuangimbal https://wiki.sams-project.eu/index.php?title=UCD_Glossary&diff=2862 2020-12-16T10:07:31Z

<p>Perempuangimbal: </p> <hr /> <div>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. <br /> <br /> In order to make the UCD collaborative process more understandable, the UCD Glossary was enriched with stories on how the terms and methodologies were used within the SAMS project.</div>

Perempuangimbal