Lecture 6 Flashcards
Four basic activities in Interaction Design
Establishing requirements
Designing alternatives
Prototyping
Evaluating
– primary: frequent hands-on
– secondary: occasional or via someone else
– tertiary: affected by its introduction, or will influence its
purchase
Stakeholders and Users
those who interact directly with the product
those who manage direct users
those who receive output from the product
those who make the purchasing decision
those who use competitor’s products
Needs
Users rarely know what is possible
Users can’t tell you what they ‘need’ to help them achieve their goals
Instead, look at existing tasks: – their context – what information do they require? – who collaborates to achieve the task? – why is the task achieved the way it is? – SUGGEST BETTER ALTERNATIVES!
How can we generate alternatives?
—‘Flair and creativity’: research and synthesis
—Seek inspiration: look at similar products or look at very different products (e.g. ‘mouse’ concept)
user-centred Design
User-centered design rests on three principles
- Early focus on users and tasks
- Empirical measurement using quantifiable & measurable usability criteria
- Iterative design
Requirements
Functional:
What the system should do
Historically the main focus of requirements activities
(Non-functional: memory size, response
time…)
Data:
- What kinds of data need to be stored?
- Live vs. historical data, data currency..
- How will they be stored (e.g. database)?
Environment or context of use:
— physical: dusty? noisy? vibration? light? Heat? humidity? …. (e.g. ATM, open workspace vs.
Personas
- Capture user characteristics
- Not real people, but synthesised from real user characteristics
- Should not be idealised
- Bring them to life with a name, characteristics, goals, personal background
- Develop multiple personas
Data gathering for requirements
Interviews:
- Good for exploring issues
- But are time consuming and may be infeasible to visit everyone
Focus groups:
- Good at gaining a consensus view and/or highlighting areas of conflict - But can be dominated by individuals
Questionnaires:
- Can give quantitative or qualitative data
- Good for answering specific questions from a large, dispersed group of people
Researching similar products:
Good for prompting requirements
Direct observation:
- Good for understanding the nature and context of the tasks
- But, it requires time and commitment from a member of the design team, and it can result in a huge amount of data
Indirect observation:
Good for logging current tasks
Studying documentation:
-Good source of data about the steps involved in an activity, and any
regulations governing a task
-Not to be used in isolation
Contextual Inquiry
Basically a long very detailed interview
A form of interview, but
— at users’ workplace (workstation)
— 2 to 3 hours long
Four main principles:
— Context: see workplace & what happens
— Partnership: user and developer collaborate – equal
footing (vs. interview)
— Interpretation: observations interpreted by user and
developer together
— Focus: project focus to understand what to look for
Caveats - data gathering
- Political problems within the organisation
- Dominance of certain stakeholders
- Economic and business environment changes
- Balancing functional and usability demands
Task analysis
- Task descriptions are often used to envision new systems or devices
- Task analysis is used mainly to investigate an existing situation
Hierarchical Task Analysis
Involves breaking a task down into subtasks, then sub-sub-tasks and so on. These are
grouped as plans which specify how the tasks might be performed in practice
- In order to buy a DVD
- locate DVD
- add DVD to shopping basket
- enter payment details
- complete address
- confirm order
Task descriptions
Scenarios
-an informal narrative story, simple, ‘natural’,
personal, not generalisable
• Use cases
- assume interaction with a system
-assume detailed understanding of the
Interaction
• Essential use cases
— abstract away from the details
— does not have the same assumptions as use cases
use case diagram
Basically a basic sketch of interaction between user and product
