Transcript Document

Review
•
•
•
•
•
•
Intro- HCI / Interaction Design
History of HCI
Design Life Cycle – Bin-IT case study
Design Principals – Don Norman
User Centered Design
Evaluation - Assignment
Designing from Scratch
What is Design?
Simply put, its
Achieving Goals within Constraints
It is your job to figure out what the goals
are, and what the constraints are….
Imagine you want to build a wireless
personal DVD player…
Goals
Who is it for?
Why do they want it?
What is it for?
Where will they use it?
When will they use it?
Imagine you want to build a wireless
personal DVD player…
Constraints
How does user interact with it?
What materials are used?
What standards must be adopted?
Do we need to build in copyright
protection?
Trade-offs
Choosing which goals and
constraints can be relaxed so that
others are meet.
eg
Sharing the view of the DVD on
the monitor is a goal……
Eye mounted display is the most
stable while walking,
stability is a constraint……
You might decide that sharing is a
priority, while walking around
busy streets watching video might
be too distracting to be safe..
How to establish the Goals and
Constraints.
Observe, talk to, interview,
collaborate with, involve, ASK,
THE END USER.
Who are the USERS / STAKEHOLDERS
•
Not as obvious as you think:
—
—
—
—
—
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
• Three categories of user
— primary:
— secondary:
— tertiary:
frequent hands-on
occasional or via someone
else
affected by its introduction,
or will influence its purchase
Rem tutorial question, who are the
‘Stakeholders’ at a club???
Humans vary in many dimensions:
— size of hands may affect the size and
positioning of input buttons
— motor abilities may affect the
suitability of certain input and output
devices
— height if designing a physical kiosk
— strength - a child’s toy requires little
strength to operate, but greater
strength to change batteries
— disabilities (e.g. sight, hearing,
dexterity)
How to establish the Goals and
Constraints.
Observe, talk to, interview,
collaborate with, involve, ASK,
THE END USER.
This can be difficult..
• Users rarely know what is possible
• Users can’t tell you what they ‘need’ to
help them achieve their goals
Instead, study/observe existing tasks:
– their context
– what information do they require?
– who collaborates to achieve the
task?
– why is the task achieved the way it
is?
Rem – observation
interviews
questionaires
focus groups
Also….
Use tools to help get the information
RCA Cultural Probs
ref. William Gaver
A research team matches the
appropriate methods for gathering
user information with,
• the people they are designing for
• the environment/context they are
designing for
• and the product they are
designing.
Identify needs/
establish
requirements
Evaluate
(Re)Design
Prototype
Final product
Data Gathering
Identify needs/
establish
requirements
Facing Problems
• Identifying and involving stakeholders:
users, managers, developers,
customer reps?, union reps?,
shareholders?
• Involving stakeholders: workshops,
interviews, workplace studies, co-op
stakeholders onto the development
team
• ‘Real’ users, not managers:
traditionally a problem in software
engineering, but better now
Identify needs/
establish
requirements
Facing Problems
• Requirements management: version
control, ownership
• Communication between parties:
—within development team
—with customer/user
—between users… different parts of an
organisation use different
terminology
• Domain knowledge distributed and implicit:
—difficult to dig up and understand
—knowledge articulation: how do you
walk?
• Availability of key people
Facing Problems
• Political problems within the
organisation
• Dominance of certain stakeholders
• Economic and business environment
changes
Identify needs/
establish
requirements
• Balancing functional and usability
demands
Some basic guidelines
• Focus on identifying the stakeholders’
needs
• Involve all the stakeholder groups
• Involve more than one representative from
each stakeholder group
• Use a combination of data gathering
Identify needs/
establish
requirements
techniques
Some Basic Guidelines
• Support the process with props such as
prototypes and task descriptions
• Run a pilot session
• You will need to compromise on the data
you collect and the analysis to be done,
but before you can make sensible
compromises, you need to know what
you’d really like
Identify needs/
establish
requirements
• Consider carefully how to record the data
Data Interpretation and Analysis
• Start soon after data gathering session
• Initial interpretation before deeper analysis
Identify needs/
establish
requirements
Task descriptions
• Scenarios
an informal narrative story, simple,
‘natural’, personal, not
generalisable
• Use cases
—assumes interaction with a system
—assumes detailed understanding of
the interaction
Identify needs/
establish
requirements
• Essential use cases
—abstract away from the details
—does not have the same
assumptions as use cases
Scenario for Shared Calender
Identify needs/
establish
requirements
“The user types in all the names of the meeting
participants together with some constraints such as
the length of the meeting, roughly when the meeting
needs to take place, and possibly where it needs to
take place. The system then checks against the
individuals’ calendars and the central departmental
calendar and presents the user with a series of dates
on which everyone is free all at the same time. Then
the meeting could be confirmed and written into
people’s calendars. Some people, though, will want to
be asked before the calendar entry is made. Perhaps
the system could email them automatically and ask
that it be confirmed before it is written in.”
Use case for a Shared Calendar
Identify needs/
establish
requirements
1. The user chooses the option to arrange a meeting.
2. The system prompts user for the names of
attendees.
3. The user types in a list of names.
4. The system checks that the list is valid.
5. The system prompts the user for meeting
constraints.
6. The user types in meeting constraints.
7. The system searches the calendars for a date that
satisfies the constraints.
8. The system displays a list of potential dates.
9. The user chooses one of the dates.
10. The system writes the meeting into the calendar.
11. The system emails all the meeting participants
informing them of them appointment
Some alternative courses:
5. If the list of people is invalid,
5.1 The system displays an error
message.
5.2 The system returns to step 2.
8. If no potential dates are found,
8.1 The system displays a
suitable message.
8.2 The system returns to step 5.
Identify needs/
establish
requirements
Example use case diagram for shared
calendar
Arrange a
meeting
Retrieve
contact details
Administrator
Update calendar
entry
Identify needs/
establish
requirements
Departmental
member
arrangeMeeting
USER INTENTION
arrange a meeting
SYSTEM
RESPONSIBILITY
request meeting
attendees &
constraints
identify meeting
attendees
& constraints
suitable dates
choose preferred date
search calendars for
suggest potential
dates
book meeting
Task Analysis
Identify needs/
establish
requirements
• Task descriptions are often used to
envision new systems or devices
• Task analysis is used mainly to
investigate an existing situation
• It is important not to focus on superficial
activities
What are people trying to achieve?
Why are they trying to achieve it?
How are they going about it?
• Many techniques, the most popular is
Hierarchical Task Analysis (HTA)
HTA
• 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
• HTA focuses on physical and observable
actions, and includes looking at actions not
related to software or an interaction device
Identify needs/
establish
requirements
• Start with a user goal which is examined
and the main tasks for achieving it are
identified
• Tasks are sub-divided into sub-tasks
HTA example
Identify needs/
establish
requirements
0. In order to borrow a book from the
library
1. go to the library
2. find the required book
2.1 access library catalogue
2.2 access the search screen
2.3 enter search criteria
2.4 identify required book
2.5 note location
3. go to correct shelf and retrieve
book
4. take book to checkout counter
Borrow a
book from the
library
0
plan 0:
do 1-3-4.
If book isn’t on the shelf expected, do 2-3-4.
go to the
library
1
find required
book
2
retrieve book
from shelf
3
take book to
counter
4
plan 2:
do 2.1-2.4-2.5.
If book not identified from information available, do 2.2-2.3-2.4-2.5
access
catalog
2.1
access
search
screen 2.2
enter
search
criteria 2.3
identify
required
2.4
book
note
location
Graphical HTA
2.5
SUMMARY
• Getting requirements right is crucial
• There are different kinds of requirement,
each is significant for interaction design
• The most commonly-used techniques
for data gathering are: questionnaires,
interviews, focus groups and
workshops, naturalistic observation,
studying documentation
• Scenarios, use cases and essential use
cases can be used to articulate existing
and envisioned work practices.
Identify needs/
establish
requirements
• Task analysis techniques such as HTA
help to investigate existing systems and
practices
Identify needs/
establish
requirements
Evaluate
(Re)Design
Prototype
(Re)Design
Prototype
Final product
Prototyping
(Re)Design
Prototype
Write a Design Brief using the
requirements established…
(Re)Design
Prototype
Who?
Why?
What?
Where?
When?
How?
A design breif will state the goals, the
constraints and the trade-offs…
(Re)Design
Prototype
(Re)Design
Prototype
Why Prototype
(Re)Design
Prototype
– we did not have to consider the actual
iron or, fork to see the design flaws,
we only considered pictures of them
– prototyping is concerned with the
design process leading up to
production of the final system
– our prototypes are not the final system,
but representations of it
– we talk about the fidelity of user
interface prototypes
The low fidelity - high fidelity
continuum…
(Re)Design
Prototype
LOW FIDELITY PROTOTYPES
Purpose
(Re)Design
Prototype
• depict concepts
• present design alternatives
• suggest screen layouts/interface
affordances
• enable rapid development and revision
of designs
• demonstrate general look and feel of
UI/object
• iron out usability issues as early as
possible
LOW FIDELITY PROTOTYPES
Form
• simple, normally pencil and paper
• non-functional
(Re)Design
Prototype
LOW FIDELITY PROTOTYPES
Use
• design team can reason about the
design
• can be presented to sample users,
although require a facilitator
(Re)Design
Prototype
LOW FIDELITY PROTOTYPES
– storyboards present sequences of
activity in the interface
– they indicate the flow from one state
or screen to the next
– to begin with they may not include
much detail of the interface
(Re)Design
Prototype
– this example gives an overview of the
layout
without any detail - a good starting
point
– numerous alternatives can be quickly
created without worrying about
details
– should be produced in pencil (easily
changed)
– should be hand-drawn (rulers take
too much effort)
(Re)Design
Prototype
– it might be tempting to draw more
'tidy' pictures like this example
– but it's difficult to change, even if in a
drawing package
– and there is no benefit over the handdrawn sketches
– it is highly unlikely that the first (or
2nd, 3rd or 4th) designs will be
completely correct
– but if they are hard to amend, they
won't be amended
(Re)Design
Prototype
– once you are happy with your overview
of the layout
– (for multiple windows/dialogues) if
necessary
– you can start to focus on details of the
design
– such as example data values, menu
content, buttons, labels etc
– and more specific arrangement of
interface objects
(Re)Design
Prototype
– now you could choose to return to the
storyboard and provide some detail
(Re)Design
Prototype
(Re)Design
Prototype
– once you are happy with
those details you can create
your interface 'toolkit'
– by cutting out each of the
components into its own
'window'
– e.g. windows, dialogues,
menus etc
– these can be used to
dynamically simulate the
interface
– following the storyboard
– perhaps with users in an
evaluation
Advantages
• low development cost
• can evaluate multiple design concepts
quickly
• useful communication device
• good for considering screen layout issues
• and user navigation through the interface
(Re)Design
Prototype
Disadvantages
• not detailed enough to implement from
• need to be facilitated when presented to
users
• do not address issues that arise from
implementation
Low fidelity prototypes….more
Low fidelity prototyes can be simply
stories that explain how a user
interacts with an imaginary
interface…in narrative form.
Called ‘Scenario-Based Design’
(Re)Design
Prototype
Low fidelity prototypes
Low fidelity prototypes can be used
in co-design sessions with end
users to extract requirements…..
(Re)Design
Prototype
Medium fidelity prototypes
– provide a development path from the 'rough' lowfidelity prototypes
– can provide more sophisticated simulations for
users to try out
– normally only for some of the system's features
that need particular attention
(Re)Design
Prototype
Disadvantages
• users need to realise that they aren't the final
versions
• …to get correct level of critique
• can set focus on small details rather than larger
flaws
Medium fidelity prototypes
– Wizard of Oz prototyping is a useful
prototyping technique
(Re)Design
Prototype
Medium fidelity prototypes
Video Prototyping…
(Re)Design
Prototype
Medium fidelity prototypes
(Re)Design
Prototype
IDEO TECH BOX
•Library, database, website
- all-in-one
•Contains physical gizmos
for inspiration
(Re)Design
Prototype
IDEO TECH BOX
(Re)Design
Prototype
(Re)Design
Prototype
High fidelity prototypes
(Re)Design
Prototype
– have functionality and are interactive
– may be programmed (e.g. Visual Basic) or
created in a tool such as Macromedia
Director
Advantages
• user-driven
• provide look and feel
• can be used as a specification for final
implementation
Disadvantages
• expensive and time-consuming to develop
• not good for gathering requirements
• or for proof-of-concept designs
So at what point do you build prototypes?
(Re)Design
Prototype
How to choose which Prototype
• Evaluation with users or with peers, e.g.
prototypes
• Technical feasibility: some not possible
• Quality thresholds: Usability goals lead to
usability criteria set early on and check
regularly
—safety: how safe?
—utility: which functions are
superfluous?
(Re)Design
Prototype
—effectiveness: appropriate support?
task coverage, information available
—efficiency: performance
measurements
Identify needs/
establish
requirements
Evaluate
(Re)Design
Prototype
Final product
(Re)Design
Prototype
(Re)Design
Prototype
(Re)Design
Prototype
(Re)Design
Prototype
(Re)Design
Prototype
(Re)Design
Prototype
(Re)Design
Prototype