Design Flashcards
tasks involved in scenario engineering
- requirements work
- prototyping
- envisionment
- evaluation
- conceptual design
- physical design
design rationale
- making the reasons for design decisions explicit
- reasons for a specific decision
- criteria for evaluating a decision
- methods for capturing and representing design rationale
user stories reveal
- ideas
- anecdotes
- knowledge of people
- real-world experiences
- activities
- Context
User stories are used to identify the problem, the stakeholders and their constraints
conceptual scenarios
more abstract than user stories
derived by combining several user stories
do not include technology
do not specify how functions are provided
concrete scenarios
derived and generated by conceptual scenarios
suggest a particular user interface design
allocation of functions between devices and people
good start for prototyping and evaluation
the more specific a scenario is, the more concrete it is
Use cases
describes the interaction between devices and people
may result from many concrete scenarios
abstracts from concrete scenarios
covers many slight variations
needed allocation of tasks and functions
informs and is informed by the allocation process
the sum of all use cases specifies the system design
scenarios documentation
necessary information:
- authorship
- description
- history
- cross references
- rationale
- data
Scenario-based design : requirements and problems
By analysis and abstractions, difficulties become visible
- Derive requirements (desirable qualities of the system
- Prioritization - not all properties will be realizable
Scenario-Based Design: Scenario Corpus
Goal: Representative set of scenarios
- should cover a wide range of user stories
- some may be more specific, some may be more general
- high-level abstract view of the most activities
- uncover the dimensions of the systems and the involved domains
Scenario-Based Design: Conceptual Model/Design
Object or data model
- includes scenario and analysis of scenarios
- main objects, attributes and relationships among them
- ensures an accurate mental model of the interactive system
Scenario-Based Design: Design Language
Standard set of patterns for interaction
- general design language concepts may be in place before concrete design application
- interaction patterns include:
- physical attributes
- adds conceptual actions and objects
- key elements of design
- principles and rules
- common language reduces the number of elements for the involved designers
Requirement analysis
Requirement analysis means understanding
- what people do
- what people might want to do
- problems with existing systems
- how people do what they do
goal: “better” interactive systems for people
types of requirements
functional requirements
- specify what the system must do
non-functional requirements
- specify what qualities the system must have
MoSoCoW rules for prioritising requirements
must have
should have
could have
want to have
Techniques for requirements elicitation / gathering
- interviews
- observations
- documentation
- focus groups
- workshops
requirements is a user-centered activity!
Artifacts
Interviews, quesionnaires and observation will identify artifacts used during the task
- most tasks require artifacts to complete
- artifacts provide additional insight in the task
- e.g. documents, forms, printouts, tools
Envisionment
Envisionment is concerned with making ideas visible by externalizing thoughts; the goal is to represent deign work to the designers and stakeholders
fundamental to user-centered design; enables designers to see things from other people’s perspective and to communicate ideas to people
Scenarios in Envisionment
Scenarios in their most concrete form can be used to envision or evaluate specific interactions
- complement scenarios with some of the more visual envisioning techniques
- include real data and materials to allow direct involvement
- think hard about underlying assumptions
- include good characterizations and develop a good number of personas. This allows “talking” about the characters
- provide rich contextual background
not all variations can be covered …
- interactions which are typical for a number of similar use situations
- important design issues
- areas where requirements are unclear
- any aspects which are safety-critical
Prototyping
effective way for communicating ideas and design
important: selecting the appropriate techniques
allows for participatory designs
distinguishing factor: interactiveness
high-fidelity prototypes
similar in look and feel to the anticipated final system
+ useful for detailed evaluation of main design elements
+ used in crucial stages of the project
+ used when ideas, requirements and features of the system become stable
- people might believe that the final system will be exactly like the hi-fi prototype
- suggests that the system can be implemented/made to work
- expensive
low-fidelity prototypes
more focused on the underlying ideas (content, form, structure…)
designed to be produced quickly and thrown away after use
capture very early design thinking and should aid, not hinder, the process of generating and evaluating many possible solutions
often: paper prototypes / screenshots
