user-centered design for better human interfaces collaboratively designing and testing great ui jeff...

User-Centered Design for Better Human InterfacesCollaboratively designing and testing great UI

Jeff [email protected]

2

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

3

People achieve goals through interaction


problem or goal

How I’d like to feel, or what I’d like to achieve

Take some

action action evaluation Did that action deliver the results

I expected?

goal evaluation Is my goal met or problem

resolved?

the worldInformation and tools


4

problem or goal

How I’d like to feel, or what I’d like to achieve

Think of three levels: goal, task, and tool

the worldInformation and tools

Take some

action action evaluation Did that action deliver the results

I expected?

goal evaluation Is my goal met or problem

resolved?

goal

task

tool(c) Jeff Patton, AgileProductDesign.com

5

Goals, tasks, and tools apply at both a personal and organizational level

businessprocesses

employees, vendors, & systems

businessobjectives

tasks

tools

goals


6

Barney’sGetting started with a UIdesign problemRead 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)Your team(c) Jeff Patton, AgileProductDesign.com

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?

7(c) Jeff Patton, AgileProductDesign.com

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


activity

User tasks are decompose to smaller tasks and organize into activitiesTasks 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

9

task task task task

task


activitymanage email

User tasks are decompose to smaller tasks and organize into activitiesTasks 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.

10

task

task

task

task

task

taskreadmessage

sendmessage

createfolder delete

message

prioritizemessage

placemessagein folder


tasktasktasktask

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..

11

activity


Be sensitive to user task “altitude”

12

* from Cockburn’s Writing Effective Use Cases

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

Activity or “Kite level”Longer term goals often with no precise ending. I’ll perform several functional tasks in the context of an activity

Too abstract

Too detailed

Think about user interface design at

about this level


(c) Jeff Patton, AgileProductDesign.com 13

Describe the user experience of the product

14

The essential use case is a simple way to describe experience abstractlyFocusing 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

Write an Essential Use Case

As a team, using supplies on the table, write an essential use case for:

15

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

© Jeff Patton, all rights reserved, AgileProductDesign.com 19

Begin to think about

the UI design

Garrett describes the dependent layers that build up UI

Jesse James Garrett’s Elements of User Experience

20© Jeff Patton, all rights reserved, AgileProductDesign.com

The surface layer describes finished visual design aspects

21

Surface

Skeleton

Structure

Scope

Strategy

© Jeff Patton, all rights reserved, AgileProductDesign.com

The skeleton describes a screen’s layout and the functional compartments in the screen

22

Surface

Skeleton

Structure

Scope

Strategy

starch vegetable

entreedessert

!


Structure defines navigation from place to place in the user interface

23

task panes

modal dialogs

modal wizards

Surface

Skeleton

Structure

Scope

Strategy


The places in the user interface are built to support what people do – the user’s tasks

24

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 …..

Surface

Skeleton

Structure

Scope

Strategy


Business goals drive user constituency selection and contexts supported to form strategy

25

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• …

Surface

Skeleton

Structure

Scope

Strategy


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.


Let’s look at a strategy for a product we all use: the place we live

27

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• …

Surface

Skeleton

Structure

Scope

Strategy


What tasks might I and my family do to reach our goals?

28

user tasks:• store food• prepare food• eat food• sleep• bathe• store changes of clothing• stay out of rain• entertain guests• entertain self• …

Surface

Skeleton

Structure

Scope

Strategy


I’ll arranging tasks by affinity to help identify structure

29

Surface

Skeleton

Structure

Scope

Strategy


I’ll optimize layout and tool choices to support tasks

30

Surface

Skeleton

Structure

Scope

Strategy


I’m going to spend a lot of time here, I want my experience to be as pleasant as possible…

31

Surface

Skeleton

Structure

Scope

Strategy


The goal-task-tool model maps to Garrett’s elements model

32

Surface

Skeleton

Structure

Scope

Strategy


Surface

Skeleton

Structure

Scope

Strategy


33

goals

tasks

tools


Surface

Skeleton

Structure

Scope

Strategy


34

User Interface Prototyping


Identify “tools” as abstract UI componentsFor 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

35

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.

Larry Constantine© Jeff Patton, all rights reserved, AgileProductDesign.com

Exercise: Identify the abstract components in your user scenarioUsing 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.


37

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

38

Build prototypes from moveable and removable paper components

You may also choose to print and cut apart existing user interfaces or data from an existing system

Build a prototype from bits of paper and cardstockTools 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)


39

In small teams, build up paper prototypes a component at a timeUse a team approach to build up a componentized paper prototype:

1. Someone direct traffic2. Various people build

components3. Someone assemble the

user interface from the components

4. Someone continuously review what’s being assembled against your use case – will it work?


We build the prototype from components so we can play the role of a computer during testing


41

Joe’s suggests we also use a recording of the prototype as documentation


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:

42

• User: impatient Buyer Task: find a specific foreign

film where I know the title Goal: : find it and buy it

without wasting time


Preparing to Testing Your Paper PrototypeIdentify test subjects

Should match the characteristics and skills of our your target user constituencies

Actual end users or stand-ins

Identify tasks to testAssemble 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 subjectsSetup your testing facility


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.44© Jeff Patton, all rights reserved, AgileProductDesign.com

45

Watch as each participant plays their role during light weight usability testingNote 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 safeSports caster making sure participants keep talking going so we know what they’re thinkingScientists working hard not to bias the results by giving users hints© Jeff Patton, all rights reserved, AgileProductDesign.com

Exercise: Test Your Paper Prototype

1. Facilitator introduces the team.2. Facilitator introduces tasks to perform and

goals, then invites test participants to “think out loud” and begin.

3. Facilitator plays sports-caster; keeps subject talking, narrating when necessary.

4. Observers record data – use post-it notes to make downstream analysis move faster.

5. When the test is complete observers may ask test participants questions.

6. Thank test participants.7. Consolidate data.

How many issues did you detect? Consider issues as items you’d change.

46

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


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

47

See “Getting Software RITE”: http://www.agileproductdesign.com/writing/ieee/patton_getting_software_rite.pdf


Unraveling Usability Concerns From Visual Design ConcernsUsability 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.


Layer in user interface concerns – like a layer cakeStart by making useful software

Choose appropriate utility first

Usability second

Defer design esthetics until after the software is useful

49

utility(does the software offer functionality to

support my goals?)

usability(can that functionality easily learned,

and effectively used?)

design esthetics

(is the software fun, pleasant, exciting – what is my

emotional response?)

usef

ulne

ss


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 low-fidelity prototyping is faster than working code.

Iterate to learn in the fastest medium available

50

See the StickyMinds.com article: “Test Software Before You Code”:http://www.stickyminds.com/s.asp?F=S11104_COL_2


William’s 4 Basic Design Principles

Visual Design Basics

Robin Williams’ The Non-Designer’s Design Book

Visual design that communicates effectivelyfour simple principles

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.

53

C

R

A

P

Contrast

Repetition

Alignment

Proximity


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.

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?


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?


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?


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?


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.”

63

Don Norman’s The Design of Everyday Things


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

64

Jakob Nielsen’s Usability Engineering© Jeff Patton, all rights reserved, AgileProductDesign.com

* Kent Beck coined the term user stories in Extreme Programming Explained 1st Edition, 1999

An Agile User Story Might Model Use... It’s Easier to Design User Interface if it Does

As a [type of user]

I want to [perform some task]

so that I can [achieve some goal]

66

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 harried shopper

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

user story

In practice user stories may be written to describe user tasks or the tools that support them

68

software

tasks

features

goalsAs a weekend gardener

I want to dig a hole

so that I can plant a tree

More task-centric:

As a weekend gardener

I want a shovel

so that I can [dig a hole to] plant a tree

More tool-centric:(or feature-centric)


Ideally we’ll write task-centric user stories to defer user interface design decisions – the tool decisions

69

hole (to put the flower in)

dig hole

hold options open


Understand what users are trying to accomplish, defer specific UI decisions till the last responsible moment

70

hole (to put the flower in)

dig hole


Designing user interface specifically for a single iteration-level story often doesn’t workWhy 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


Favor user task-centric stories to base UI design onEspecially 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


Usage to User InterfaceCollaboratively designing and testing great UI


user-centered design for better human interfaces collaboratively designing and testing great ui jeff...

Documents

user goals

tools user tasks

smaller tasks tasks

activity user tasks

types of user tasks

activities tasks

functional tasks

task c jeff patton