User-Centered Design for
Better Human Interfaces
Collaboratively designing and testing great UI
Jeff Patton
jpatton@acm.org
www.agileproductdesign.com
Our goals and agenda today
Goal: feel comfortable design and testing functional,
usable, user interface
Part 1: Understanding the user’s experience
 Understanding user’s goals and tasks
 Telling stories about the user experience
 Converting stories to UI components
Part 2: Prototyping and testing the user interface
 Building a componentized paper prototype
 Iteratively testing and refining your prototype
 Improving your visual design (as time permits)
(c) Jeff Patton, AgileProductDesign.com
2
People achieve goals through interaction
problem or
goal
How I’d like to feel, or
what I’d like to achieve
goal evaluation
Is my goal met or problem
resolved?
Take some
action
action evaluation
Did that action deliver the results I
expected?
the world
Information and tools
(c) Jeff Patton, AgileProductDesign.com
3
Think of three levels: goal, task, and tool
problem or
goal
goal
How I’d like to feel, or
what I’d like to achieve
Take some
task
action
goal evaluation
Is my goal met or problem
resolved?
action evaluation
tool
Did that action deliver the results I
expected?
the world
Information and tools
(c) Jeff Patton, AgileProductDesign.com
4
Goals, tasks, and tools apply at both a
personal and organizational level
goals
business
objectives
tasks
business
processes
tools
employees,
vendors, & systems
(c) Jeff Patton, AgileProductDesign.com
5
Getting started with a UI
design problem
Barney’s
Read the Barney’s Information Kiosk
problem
Watch for:



Business goals
Users and their goals
The types of user tasks users would likely choose to
reach their goals
(5 minutes)
In small workgroups (4-5 people)
discuss:



What are Barney’s goals or pains?
What types of users might use the kiosk and
why?
Try to talk about tasks without talking about the
kiosk (tool) – this can be difficult
(5 minutes)
(c) Jeff Patton, AgileProductDesign.com
Your team
6
What are the user’s goals and
businesses goals?
Business goals or pain
points?
Types of users using
this system?
User’s goals or pains?
(c) Jeff Patton, AgileProductDesign.com
7
What will users do with the system to
reach their goals?
User tasks describe
the actions people
take
Try to name them
without prescribe the
“tool” solution
(c) Jeff Patton, AgileProductDesign.com
8
User tasks are decompose to smaller
tasks and organize into activities
Tasks require intentional action on behalf of a tool’s user
Tasks have an objective that can be completed
Tasks decompose into smaller tasks
Tasks often cluster together in activities
activity
task
task
(c) Jeff Patton, AgileProductDesign.com
task
task
task
9
User tasks are decompose to smaller
tasks and organize into activities
Tasks require intentional action on behalf of a tool’s user
Tasks have an objective that can be completed
Tasks decompose into smaller tasks
Tasks often cluster together in activities
“Read an email message” is a task, “Managing email” is an activity.
manageactivity
email
read
task
message
create
task
folder
(c) Jeff Patton, AgileProductDesign.com
send
task
message
delete
task
message
prioritize
task
message
place
message
task
in folder
10
Activities have characteristics relevant to
the software we’ll choose to build






some number of common tasks
a general goal or purpose
a primary human participant
usually other human participants
a physical place or location
some number of tools including computers, software, electronic files,
telephones, information, paper, etc..
activity
task
task
task
task
(c) Jeff Patton, AgileProductDesign.com
11
Be sensitive to user task “altitude”
Too abstract
Activity or “Kite level”
Longer term goals often with no precise ending. I’ll
perform several functional tasks in the context of an
activity
Think about user
interface design at
about this level
Functional or “Sea level”
I’d reasonably expect to complete this in a single sitting
Sub-Functional or “Fish level”
Small tasks that by themselves don’t mean much. I’ll do
several of these before I reach a functional level goal
Too detailed
(c) Jeff Patton, AgileProductDesign.com
* from Cockburn’s Writing
Effective Use Cases
12
Describe the user
experience of the product
(c) Jeff Patton, AgileProductDesign.com
13
The essential use case is a simple way to
describe experience abstractly
Focusing on the interaction between user and system
Avoid describing what the user specifically does by focusing on the
user’s intention
Determine the system responsibilities based on user goals and
expectations
User Intention
System Responsibility
Step one
System response
Step two
System response
(c) Jeff Patton, AgileProductDesign.com
14
Write an Essential Use Case
As a team, using supplies on the table, write an essential
use case for:
Uuse this task:
 User: impatient Buyer
 Task: find a specific foreign
film where I know the title
 Goal: : find it and buy it
without wasting time
15
Begin to think about
the UI design
© Jeff Patton, all rights reserved, AgileProductDesign.com
19
Garrett describes the dependent layers
that build up UI
Jesse James Garrett’s Elements of User Experience
© Jeff Patton, all rights reserved, AgileProductDesign.com
20
The surface layer describes finished
visual design aspects
Surface
Skeleton
Structure
Scope
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
21
The skeleton describes a screen’s layout and
the functional compartments in the screen
Surface
starch
Skeleton
entree
vegetable
dessert
!
Structure
Scope
Strategy
(c) Jeff Patton, AgileProductDesign.com
22
Structure defines navigation from place
to place in the user interface
Surface
task panes
Skeleton
Structure
modal dialogs
Scope
modal wizards
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
23
The places in the user interface are built to
support what people do – the user’s tasks
Surface
Skeleton
Structure
Scope
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
user tasks (what do people need to
accomplish):
 enter numbers
 enter text
 enter formulas
 format cells
 sort information
 filter information
 aggregate information
 graph data
 save data
 import data
 export data
 print
 …..
24
Business goals drive user constituency selection
and contexts supported to form strategy
Surface
Skeleton
Structure
Scope
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
business goals:
• displace competitive products
• motivate sale of other integrated
products
• establish file format as default
information sharing format
• …
user constituencies:
• accountant
• business planner
• housewife
• …
usage contexts:
• office desktop
• laptop on airplane
• pda in car
• …
25
Garret’s Elements of UX Stack Applies to the
User Experience of Other Complex Products
These layers of concerns apply
not only to software but a
variety of products.
In particular, products that
support a wide variety of user
tasks benefit from this kind of
thinking.
(c) Jeff Patton, AgileProductDesign.com
26
Let’s look at a strategy for a product we
all use: the place we live
Surface
Skeleton
Structure
Scope
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
goals:
• live comfortably
• eat well
• stay clean
• be healthy
• keep up with Jones’s
• …
user constituencies:
• me
• spouse
• child
• …
usage contexts:
• near work
• near good schools
• near shopping
• …
27
What tasks might I and my family do to
reach our goals?
Surface
Skeleton
Structure
user tasks:
• store food
• prepare food
• eat food
• sleep
• bathe
• store changes of clothing
• stay out of rain
• entertain guests
• entertain self
• …
Scope
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
28
I’ll arranging tasks by affinity to help
identify structure
Surface
Skeleton
Structure
Scope
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
29
I’ll optimize layout and tool choices to
support tasks
Surface
Skeleton
Structure
Scope
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
30
I’m going to spend a lot of time here, I want
my experience to be as pleasant as possible…
Surface
Skeleton
Structure
Scope
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
31
The goal-task-tool model maps to
Garrett’s elements model
Surface
Skeleton
Structure
Scope
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
32
The goal-task-tool model maps to
Garrett’s elements model
Surface
tools
Skeleton
Structure
tasks
Scope
goals
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
33
The goal-task-tool model maps to
Garrett’s elements model
Surface
Skeleton
User
Interface
Prototyping
Structure
Scope
Strategy
© Jeff Patton, all rights reserved, AgileProductDesign.com
34
Identify “tools” as abstract UI
components
For each system responsibility, what sort of tool will the system
need to offer to meet that responsibility to the user?
Preliminarily decide on tools as abstract components.
 An abstract component (describe by Larry Constantine) refers to a general
type of component with a certain responsibility
Information or Material: contains and presents
information.
Action or Tool: allows execution of an action.
Actionable Material: contains and presents
information and allows the information to be acted on
through selection or manipulation.
© Jeff Patton, all rights reserved, AgileProductDesign.com
Larry Constantine
35
Exercise: Identify the abstract
components in your user scenario
Using post-it notes, identify abstract components the user
experience you’ve described
 Give each component a descriptive name that suggests its responsibility
Look for:
 Information: information that displayed on the screen such as “author,”
“document title,” “status.” People using the system will need information
to orient themselves, and make decisions.
 actions: allow those using your system to tell the system to do something,
or navigate somewhere. Typical actions include: “save,” “send, ” or
“home.”
 actionable information: includes form fields that allow entry and editing
of information and items like lists of information that when clicked can be
edited.
© Jeff Patton, all rights reserved, AgileProductDesign.com
36
Part 2: Prototyping and testing the user
interface
Building a
componentized
paper prototype
Iteratively testing
and refining your
prototype
Improving your
visual design (as
time permits)
© Jeff Patton, all rights reserved, AgileProductDesign.com
37
Build prototypes from moveable and
removable paper components
Build a prototype from bits
of paper and cardstock
Tools you’ll need:
• Card Stock (use for screen
backgrounds and cut up for
components)
• Index Cards (lined cards make
great lists)
• Scissors or Xacto knife
• Cello tape
• Repositionable tape
• Pencils
• Sharp felt tip pens
• Transparency film (great to
write on)
© Jeff Patton, all rights reserved, AgileProductDesign.com
You may also choose to print and cut apart
existing user interfaces or data from an
existing system
38
In small teams, build up paper
prototypes a component at a time
Use a team approach to
build up a
componentized paper
prototype:
1. Someone direct traffic
2. Various people build
components
3. Someone assemble the
user interface from the
components
4. Someone continuously
review what’s being
assembled against your use
case – will it work?
© Jeff Patton, all rights reserved, AgileProductDesign.com
39
We build the prototype from components so we
can play the role of a computer during testing
© Jeff Patton, all rights reserved, AgileProductDesign.com
40
Joe’s suggests we also use a recording of
the prototype as documentation
© Jeff Patton, all rights reserved, AgileProductDesign.com
41
Exercise: Build Your Prototype
As a team within the short time-box, build your prototype to
support these two user tasks:
Work as a team:
 One or more people build components
 One or more assemble the prototype using the components
 Someone use the task cases or scenarios to validate the UI supports these
user stories
Your UI design must support both this task:
• User: impatient Buyer
 Task: find a specific foreign
film where I know the title
 Goal: : find it and buy it
without wasting time
© Jeff Patton, all rights reserved, AgileProductDesign.com
42
Preparing to Testing Your Paper
Prototype
Identify test subjects
 Should match the characteristics and skills of our
your target user constituencies
 Actual end users or stand-ins
Identify tasks to test
Assemble your test team
 facilitator
 computer
 observers
Coach the test team on the testing personalities:
 flight attendant
 sports caster
 scientist
Decide on test approach – single or paired subjects
Setup your testing facility
© Jeff Patton, all rights reserved, AgileProductDesign.com
43
Run Your Usability Test
Facilitator introduces the team.
Facilitator introduces tasks to perform and
goals, then invites test participants to
“think out loud” and begin.
Facilitator plays sports-caster; keeps
subject talking, narrating when necessary.
Observers record data – use post-it notes to
make downstream analysis move faster.
When the test is complete observers may
ask test participants questions.
Thank test participants.
Consolidate data.
 How many issues did you detect?
Consider issues as items you’d change.
© Jeff Patton, all rights reserved, AgileProductDesign.com
44
Watch as each participant plays their
role during light weight usability testing
Note each role:
 Facilitator
 Paired test subjects
 Observer
Notice participants paying
attention to the testing
personalities:
Flight attendant letting
participants know the rules and
making sure they’re safe
Sports caster making sure
participants keep talking going so
we know what they’re thinking
Scientists working hard not to
bias the results by giving users
hints
© Jeff Patton, all rights reserved, AgileProductDesign.com
45
Exercise: Test Your Paper Prototype
1.
2.
3.
4.
5.
6.
7.
Facilitator introduces the team.
Facilitator introduces tasks to perform and
goals, then invites test participants to
“think out loud” and begin.
Facilitator plays sports-caster; keeps
subject talking, narrating when necessary.
Observers record data – use post-it notes
to make downstream analysis move faster.
When the test is complete observers may
ask test participants questions.
Thank test participants.
Consolidate data.
 How many issues did you detect? Consider
issues as items you’d change.
© Jeff Patton, all rights reserved, AgileProductDesign.com
Support these tasks:
• User: casual browser
 Task: find the most
current release for a
particular artist
• User: impatient Buyer
 Task: find a specific
foreign film where I know
the title
46
This isn’t just the right way to test, it’s RITE
Traditional usability testing focuses on:
 Identifying repeatable user missteps
 UI concerns that may make the software difficult to learn,
or learned behavior hard to maintain
 Then reporting those errors with suggestions for
correcting problems
The RITE method: Rapid Iterative Testing and Evaluation
 Rather than focusing on number of errors, emphasize
number of errors fixed
 Required the capability to correct errors between
iterative tests
 For higher-fidelity prototypes or working code, this
requires developer participation
See “Getting Software RITE”:
http://www.agileproductdesign.com/writing/ieee/patton_getting_software_rite.pdf
© Jeff Patton, all rights reserved, AgileProductDesign.com
47
Unraveling Usability Concerns From
Visual Design Concerns
Usability is a measured characteristic of your software.
Typical usability tests measure:
 Task completion frequency
 Task completion time
 Errors or missteps
Professionals [and novices] can give their subjective evaluation on usability, but
you can’t really be sure until you test [or ship].
Paper Prototype usability testing helps identify usability issues before the
software is built.
Visual design adds look and feel that may affect usability.
Don’t assume those skilled at visual design are also skilled at usability.
© Jeff Patton, all rights reserved, AgileProductDesign.com
48
Layer in user interface concerns – like a
layer cake
Start by making useful
software
design
esthetics
 Choose appropriate
utility first
 Usability second
usefulness
Defer design esthetics
until after the
software is useful
(is the software fun, pleasant,
exciting – what is my
emotional response?)
usability
(can that functionality easily learned,
and effectively used?)
utility
(does the software offer functionality to
support my goals?)
© Jeff Patton, all rights reserved, AgileProductDesign.com
49
Test First – Building Confidence into
Software Development
Agile development’s test-first technique doesn’t
just apply to code.
Use paper prototyping and usability testing to
validate that your user interface requirements
are accurate and the software you intend to
build can be effectively used.
Iteration and testing of user interface using lowfidelity prototyping is faster than working code.
Iterate to learn in the fastest medium available
See the StickyMinds.com article: “Test Software Before You Code”:
http://www.stickyminds.com/s.asp?F=S11104_COL_2
© Jeff Patton, all rights reserved, AgileProductDesign.com
50
User-Centered Design for
Better Human Interfaces
Collaboratively designing and testing great UI
Jeff Patton
jpatton@acm.org
www.agileproductdesign.com
William’s 4 Basic Design Principles
Visual Design Basics
Robin Williams’ The Non-Designer’s Design Book
Visual design that communicates effectively
four simple principles
C
Contrast
R
Repetition
A
Alignment
P
Proximity
Learn the principles and use
them intentionally to improve
your design.
Analyze existing user
interface design to see how
these principles were
leveraged or neglected.
© Jeff Patton, all rights reserved, AgileProductDesign.com
53
Proximity communicates affinity
Proximity communicates
similarity – distance
communicates lack of similarity.
Group related items together.
“Clumps” of items can feel like
one item visually.
Minimize the number of
“clumps” to help make a screen
look simple.
© Jeff Patton, all rights reserved, AgileProductDesign.com
Q: Does your page have a
minimal number of small
clumps where each clump
contains items that are of the
same type or for the same
purpose?
54
55
Alignment communicates association
Nothing should be placed on the screen
arbitrarily. Every item should have a
connection with something else on the
screen – after all if it’s on the same
screen it’s associated.
3 Horizontal Alignments: Left Center
Right
 Center alignments are visually the
weakest
The fewer alignment axis the better
Q: Are there a minimal number of
strong alignment axis?
© Jeff Patton, all rights reserved, AgileProductDesign.com
56
57
Repetition helps calm and unify a design
Repeated elements blend in.
Repeat some aspects of the design throughout
the entire application.
Repetition can be thought of as consistency.
Appropriate repetition makes the application
appear cohesive.
Elements that repeat each page become static –
or “visually persistent.” As users move from place
to place in your software, they need only observe
what’s changed.
Q: does repetition help calm and unify the design?
© Jeff Patton, all rights reserved, AgileProductDesign.com
58
59
60
Contrast communicates importance
Use contrast to focus the users attention,
to guide him/her through the application.
Contrast, or don’t. If two items are not
exactly the same, make them different –
really different. Subtle difference isn’t
contrast, it’s perceived by users as tension
in the screen and often looks like a
mistake.
Q: are the highest contrast items in the UI
the items I want people to see?
© Jeff Patton, all rights reserved, AgileProductDesign.com
61
62
Usability Refers To The Ability of a User
To Effectively Execute A Task Using a Tool
“While Visual Design certainly
can affect usability, it’s quite
possible for a product to have
pleasing visual design, but
intolerable usability.”
Don Norman’s The Design of Everyday Things
© Jeff Patton, all rights reserved, AgileProductDesign.com
63
Nielsen’s 10 Usability Heuristics
1.
Visibility of system status (keep the user informed)
 Be forthcoming - don’t hide information
2.
Match between system and real world (user language and real world conventions)
 Watch your language
3.
User control and freedom (easy exits, undo and redo)
 padded corners, hand rails, and safety nets
4.
Consistency and standards
 same thing the same way
5.
Error prevention
6.
Recognition rather than recall (reduce remembering with visible options, actions,
and instructions)
7.
Flexibility and efficiency of use (customization and support for advanced users)
8.
Aesthetic and minimalist design (reduce irrelevant or rarely needed information)
9.
Help in recognizing, diagnosing, and recovering from errors
10. Good help and documentation
Jakob Nielsen’s Usability Engineering
© Jeff Patton, all rights reserved, AgileProductDesign.com
64
User-Centered Design for
Better Human Interfaces
Collaboratively designing and testing great UI
Jeff Patton
jpatton@acm.org
www.agileproductdesign.com
An Agile User Story Might Model Use... It’s Easier to Design User
Interface if it Does
Originally eXtreme Programming described a user story as a small
amount of text written on an index card to function as a reminder
for a conversation between developer and customer.
From Wikipedia:
“A user story is a software system requirement formulated as one or two sentences in the
everyday language of the user.”
The user story form credited to Rachel Davies in Cohn’s User Stories
Applied combines user, task, and goal:
As a
I want to
so that I can
[type of user]
[perform some task]
[achieve some goal]
As a harried shopper
* Kent Beck coined the
term user stories in
Extreme Programming
Explained 1st Edition, 1999
I want to locate a specific CD in the store
so that I can purchase it quickly, leave, and continue with my day.
© Jeff Patton, all rights reserved, AgileProductDesign.com
66
In practice user stories may be written to describe
user tasks or the tools that support them
goals
More task-centric:
As a weekend gardener
user story
I want to dig a hole
tasks
so that I can plant a tree
More tool-centric:
(or feature-centric)
software
features
© Jeff Patton, all rights reserved, AgileProductDesign.com
As a weekend gardener
I want a shovel
so that I can [dig a hole to]
plant a tree
68
Ideally we’ll write task-centric user stories to defer user
interface design decisions – the tool decisions
hole
(to put the flower in)
dig hole
hold options open
© Jeff Patton, all rights reserved, AgileProductDesign.com
69
Understand what users are trying to accomplish, defer
specific UI decisions till the last responsible moment
hole
(to put the flower in)
dig hole
© Jeff Patton, all rights reserved, AgileProductDesign.com
70
Designing user interface specifically for a
single iteration-level story often doesn’t
work
Why doe you suppose that is?
(Jeff pause here for participants to answer)
Because
 Users think in terms of activities and functional tasks
 User stories are often written to build much smaller pieces of
functionality
Therefore
 Design user interface based on use
 Use that UI design as a blueprint. Each story implements a piece of that
blueprint.
 The higher the goal-level of the user interaction, the lower the fidelity of
UI design
© Jeff Patton, all rights reserved, AgileProductDesign.com
71
Favor user task-centric stories to base UI
design on
Especially during early scoping and release planning project stages
Especially before prototyping and testing proposed user interfaces
Be prepared to split task-centric user stories as necessary to:
 defer expensive-to-implement user interactions for future release.
 to break up large user interface construction into more manageable
pieces.
Stories may become more tool-centric over time, and closer to
development time
Defer tool-centricity to the latest responsible moment
© Jeff Patton, all rights reserved, AgileProductDesign.com
72
Usage to User Interface
Collaboratively designing and testing great UI
Jeff Patton
jpatton@acm.org
www.AgileProductDesign.com