Discovering Requirements in Interaction Design

Discovering Requirements in Interaction Design

• The requirements activity is focused on exploring the problem space and defining what will be developed in interaction design.

• Requirements, design, and evaluation activities are closely related and intertwined in an iterative development cycle.

• The main purpose of the requirements activity is to explore the problem space and establish a description of what will be developed.

• Requirements may be discovered through targeted activities or tangentially during product evaluation, prototyping, design, and construction.

• Requirements may be captured in several different forms, such as prototypes, stories, diagrams, and photographs.

• The goal of an iterative user-centered approach is to involve different perspectives and make sure that there is agreement, avoiding miscommunication.

• A requirement is a statement about an intended product that specifies what it is expected to do or how it will perform.

• Requirements come in different forms and at different levels of abstraction, such as atomic requirements shell and user stories.

• There are different kinds of requirements, including functional, non-functional, data, environment, user, usability, and user experience.

• Functional requirements capture what the product will do, while data requirements capture the type, volatility, size/amount, persistence, accuracy, and value of the required data.

• Environmental requirements refer to the circumstances in which the interactive product will operate, including physical and social aspects.

• The iterative process of discovering requirements allows requirements and their understanding to evolve, and it involves specifying criteria that can be used to show when the requirements have been fulfilled.Discovering Requirements Activity

• Requirements for an interactive product include functional, data, environmental, user characteristics, usability goals, and user experience goals.

• User characteristics include abilities, skills, educational background, preferences, and physical or mental disabilities.

• Usability engineering is an approach to track progress of usability goals during development.

• Different interactive products have different requirements based on their purpose and intended users.

• Data gathering techniques for requirements include interviews, observation, questionnaires, and studying documentation.

• Documentation, such as manuals and activity logs, can be a good source of data for requirements.

• Usable security is a requirement that must balance security measures and user experience.

• Combining data gathering techniques such as observation, interviews, diaries, and surveys can provide different perspectives for requirements activities.

• Requirements for an interactive product for navigating around a shopping center include locating places, access to GPS location data and maps, and efficient and safe use.

• Requirements for a wearable interactive product to measure glucose levels include measuring glucose readings, being suitable for wearing, and exhibiting all usability goals.

• Direct observation, indirect observation through log files, interviews, diaries, and surveys can be combined to inform the design of reflective systems that promote emotional well-being.

• Requirements for a memory aid application for traumatic brain injury sufferers include being simple, customizable, and discreet. Studying documentation, evaluating other systems, user observations, and group interviews can be used to discover requirements for a ship's maneuvering system.Data Gathering Techniques for Requirements Discovery

• Orit Shaer et al. (2012) conducted an ethnographic study, interviews, usability tests, and user participation to design a multitouch tabletop user interface for collaborative exploration of genomic data.

• In-depth interviews were conducted with 38 molecular and computational biologists to understand the current work practices, needs, and workflow of small research groups.

• A small team of nine researchers investigating gene interaction in tuberculosis was studied for eight weeks using an ethnographic approach, and other labs were also observed.

• Biologists were integrated into the development team, and other members of the design team regularly visited biology research group partners, attended courses to teach them relevant domain concepts, and conducted frequent usability tests with users.

• Probes come in many forms and are an imaginative approach to data gathering designed to prompt participants into action.

• Cultural probes were developed during the Presence Project (Gaver et al., 1999) to investigate novel interaction techniques to increase the presence of elderly people in their local community.

• Different forms of probes have been adapted and adopted for a range of purposes, including design probes, technology probes, and provocative probes.

• Contextual inquiry is the core field research process for Contextual Design that explicitly defines how to gather, interpret, and model data about how people live to drive design ideation.

• Contextual inquiry is used on its own to discover requirements, and it involves one-on-one field interviews called contextual interviews, undertaken by every member of the design team, each lasting about one-and-a-half to two hours.

• Four principles guide the contextual interview: context, partnership, interpretation, and focus.

• Cool concepts are identified as the user does their activity, although often they only emerge retrospectively when reflecting on the session.

• Brainstorming is a generic technique used to generate, refine, and develop ideas and is widely used in interaction design specifically for generating alternative designs or for suggesting new and better ideas to support users.

• Various rules have been suggested for making a brainstorming session successful, including including participants from a wide range of disciplines with a broad range of experience, not banning silly stuff, using catalysts for further inspiration, and keeping records.Bringing Requirements to Life: Personas and Scenarios

• Using a well-honed problem to start a brainstorming session can keep the focus on track.

• Warm-up exercises can be used to engage the group and make the session fun.

• Personas and scenarios complement each other to bring realistic detail to the product.

• Personas are rich descriptions of typical users synthesized from a set of user profiles.

• Each persona is characterized by a unique set of goals relating to the particular product under development.

• Personas include a description of the user’s behavior, attitudes, activities, and environment.

• A product will usually require a small set of personas rather than just one.

• Personas help the designer understand whether a particular design decision will help or hinder their users.

• Scenarios are informal narrative descriptions that describe human activities or tasks in a story.

• Scenarios do not necessarily describe the use of software or other technological support used to achieve a goal.

• Scenarios use the vocabulary and phrasing of users to allow stakeholders to participate fully in development.

• Personas and scenarios can guide development throughout the product lifecycle.

Discovering Requirements in Interaction Design

• The requirements activity is focused on exploring the problem space and defining what will be developed in interaction design.

• Requirements, design, and evaluation activities are closely related and intertwined in an iterative development cycle.

• The main purpose of the requirements activity is to explore the problem space and establish a description of what will be developed.

• Requirements may be discovered through targeted activities or tangentially during product evaluation, prototyping, design, and construction.

• Requirements may be captured in several different forms, such as prototypes, stories, diagrams, and photographs.

• The goal of an iterative user-centered approach is to involve different perspectives and make sure that there is agreement, avoiding miscommunication.

• A requirement is a statement about an intended product that specifies what it is expected to do or how it will perform.

• Requirements come in different forms and at different levels of abstraction, such as atomic requirements shell and user stories.

• There are different kinds of requirements, including functional, non-functional, data, environment, user, usability, and user experience.

• Functional requirements capture what the product will do, while data requirements capture the type, volatility, size/amount, persistence, accuracy, and value of the required data.

• Environmental requirements refer to the circumstances in which the interactive product will operate, including physical and social aspects.

• The iterative process of discovering requirements allows requirements and their understanding to evolve, and it involves specifying criteria that can be used to show when the requirements have been fulfilled.Discovering Requirements Activity

• Requirements for an interactive product include functional, data, environmental, user characteristics, usability goals, and user experience goals.

• User characteristics include abilities, skills, educational background, preferences, and physical or mental disabilities.

• Usability engineering is an approach to track progress of usability goals during development.

• Different interactive products have different requirements based on their purpose and intended users.

• Data gathering techniques for requirements include interviews, observation, questionnaires, and studying documentation.

• Documentation, such as manuals and activity logs, can be a good source of data for requirements.

• Usable security is a requirement that must balance security measures and user experience.

• Combining data gathering techniques such as observation, interviews, diaries, and surveys can provide different perspectives for requirements activities.

• Requirements for an interactive product for navigating around a shopping center include locating places, access to GPS location data and maps, and efficient and safe use.

• Requirements for a wearable interactive product to measure glucose levels include measuring glucose readings, being suitable for wearing, and exhibiting all usability goals.

• Direct observation, indirect observation through log files, interviews, diaries, and surveys can be combined to inform the design of reflective systems that promote emotional well-being.

• Requirements for a memory aid application for traumatic brain injury sufferers include being simple, customizable, and discreet. Studying documentation, evaluating other systems, user observations, and group interviews can be used to discover requirements for a ship's maneuvering system.Data Gathering Techniques for Requirements Discovery

• Orit Shaer et al. (2012) conducted an ethnographic study, interviews, usability tests, and user participation to design a multitouch tabletop user interface for collaborative exploration of genomic data.

• In-depth interviews were conducted with 38 molecular and computational biologists to understand the current work practices, needs, and workflow of small research groups.

• A small team of nine researchers investigating gene interaction in tuberculosis was studied for eight weeks using an ethnographic approach, and other labs were also observed.

• Biologists were integrated into the development team, and other members of the design team regularly visited biology research group partners, attended courses to teach them relevant domain concepts, and conducted frequent usability tests with users.

• Probes come in many forms and are an imaginative approach to data gathering designed to prompt participants into action.

• Cultural probes were developed during the Presence Project (Gaver et al., 1999) to investigate novel interaction techniques to increase the presence of elderly people in their local community.

• Different forms of probes have been adapted and adopted for a range of purposes, including design probes, technology probes, and provocative probes.

• Contextual inquiry is the core field research process for Contextual Design that explicitly defines how to gather, interpret, and model data about how people live to drive design ideation.

• Contextual inquiry is used on its own to discover requirements, and it involves one-on-one field interviews called contextual interviews, undertaken by every member of the design team, each lasting about one-and-a-half to two hours.

• Four principles guide the contextual interview: context, partnership, interpretation, and focus.

• Cool concepts are identified as the user does their activity, although often they only emerge retrospectively when reflecting on the session.

• Brainstorming is a generic technique used to generate, refine, and develop ideas and is widely used in interaction design specifically for generating alternative designs or for suggesting new and better ideas to support users.

• Various rules have been suggested for making a brainstorming session successful, including including participants from a wide range of disciplines with a broad range of experience, not banning silly stuff, using catalysts for further inspiration, and keeping records.Bringing Requirements to Life: Personas and Scenarios

• Using a well-honed problem to start a brainstorming session can keep the focus on track.

• Warm-up exercises can be used to engage the group and make the session fun.

• Personas and scenarios complement each other to bring realistic detail to the product.

• Personas are rich descriptions of typical users synthesized from a set of user profiles.

• Each persona is characterized by a unique set of goals relating to the particular product under development.

• Personas include a description of the user’s behavior, attitudes, activities, and environment.

• A product will usually require a small set of personas rather than just one.

• Personas help the designer understand whether a particular design decision will help or hinder their users.

• Scenarios are informal narrative descriptions that describe human activities or tasks in a story.

• Scenarios do not necessarily describe the use of software or other technological support used to achieve a goal.

• Scenarios use the vocabulary and phrasing of users to allow stakeholders to participate fully in development.

• Personas and scenarios can guide development throughout the product lifecycle.