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
Requirements
Functional:
What the system should do
Historically the main focus of requirements activities
(Non-functional: memory size, response
time…)
Data:
Environment or context of use:
— physical: dusty? noisy? vibration? light? Heat? humidity? …. (e.g. ATM, open workspace vs.
Personas
Data gathering for requirements
Interviews:
Focus groups:
- Good at gaining a consensus view and/or highlighting areas of conflict - But can be dominated by individuals
Questionnaires:
Researching similar products:
Good for prompting requirements
Direct observation:
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
Task analysis
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
Task descriptions
Scenarios
-an informal narrative story, simple, ‘natural’,
personal, not generalisable
• Use cases
• 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