An Introduction to TaskCentered User Interface Design

1
An Introduction to Task-Centered User Interface
Design

• Loren Terveen
• CS 5115, Fall 2008
• September 22

2
Agenda

• General project check
• This weeks project deliverables
• Next weeks project deliverables
• Scheduling initial prototype presentations
• Task-Centered User Interface Design
• But first

3
Pop/Soda/Coke Bottle

• Evan Long (annglove)?
• Jon McLachlan

4
Pop Bottle

•  

5
Fame of the plastic bottle

• can screw the top back on (some level of
  preservation for later use)?
• prevents spills
• "easy" access - visible break (good security, and
  cheap)?
• adopts the common convention "lefty loosey"
• irregardless of brand/contents, easy to use
• testable explosion (and stoppable, unlike the
  aluminum and glass counterparts)?

6
Glass Bottle (Hall of Shame)?

• Glass bottle full of carbonated liquid
• requires a new tool to remove
• using your shirt as a shield to the skin-pealing
  cap, if it explodes, it explodes in your shirt
  (can not prevent partial explosion
• cannot reseal
• glass is breakable

7
Hall of Shame / Fame
Michael Raymond Alan Wyman September 22, 2008
8
Airport Wayfinding
This sign is in Helsinki Finland
9
Airport Wayfinding
This sign is in London England
10
Hall of Shame

• These are both part of the Hall of Shame
• They dont communicate universally
• Airports require accessibility
• Difficulty mapping text to action

11
Airport Wayfinding
This sign is in Cancun Mexico
12
Directional Signs - Warning Signs

• Must be read to understand that it contains
  emergency instructions
• More for public education
• Good mnemonic
• Except that the steady state alarm also pulses

13
A Much Better Sign

• Grabs attention by jutting out from the wall
• Clear wording
• Picture is not bad
• Green color indicates a positive action rather
  than a warning to stay away

14
Better Yet

• Clear picture
• Simple words
• Yellow warning color

15
(No Transcript)
16
Project deliverables

• Please read the Project Guide
• Please review the Project Guide for the upcoming
  week(s)?
• Lets look at this weeks and next weeks
  deliverables

17
Deliverables for this week

• Project Proposal
• User Visit Plans
• (Lets look at Project Guide)?

18
Deliverables for next week Week 5

• User Visit Report
• 5 Tasks
• 2 Scenarios
• Other stuff

19
User Visit Report

• Summary of the process you carried out
• A user description relevant user
  characteristics you are considering in your
  design.
• expected range of computer and internet
  experience
• use environment
• special user concerns or motivations
• what users do today to fulfill the needs that
  your project aims to satisfy in a new way
• You are finding out about their tasks and needs,
  not confirming your initial design ideas!

20
Task Analysis

• Descriptions of at least five (TCUID) tasks that
  users would accomplish with your prototype
• For each task description
• who are the users
• what are they doing
• why are they doing it
• At least three should be general tasks that users
  accomplish today
• Detailed enough for users to understand and
  comment on
• Not tied to a specific interface

21
Current Usage Scenarios

• For two of the tasks, provide a detailed scenario
  explaining how users accomplish that task toda
• These scenarios may involve computer software,
  paper, or other devices, in any combination

22
Other Stuff To Include

• Anything else you learned from the user visit not
  already covered
• How effective was your process
• Lessons learned what youd do different in the
  future
• Any information you could not gather, along with
  either (a) plans for how you will get it or (b)
  how youll continue without it

23
At your TA meeting, be prepared to discuss

• What you learned from the analysis
• Any changes in your conception of the project

24
Looking Ahead deliverables for week 6

• Initial paper prototypes
• Two per project team done independently!
• (Project guide slip personas aren't until wk 7)?
• See the schedule online
• Readings for next week
• Preece, chapter 11
• Preece, chapter 6 (just skim)?
• Prototyping for Tiny Fingers, http//doi.acm.org/1
  0.1145/175276.175288

25
Question Time

• Any project questions?
• Hall of Fame/Shame presentations?
• Check the schedule if you cant present at your
  assigned time, send me email at once

26
Reflections on DOET

• Was written 15 years ago
• Talks about things like doors, slide projectors,
  refrigerators, not GUIs
• How well does it apply to designing GUIs in 2008?
• Consider Normans own writings (jnd.org)
• Affordances, Conventions, and Design
• Emotion and Design

27
TCUID Principles

• The interface should be tailored to the users and
  their tasks
• The development process should use the users
  tasks throughout design and evaluation

28
System-Centered Design

• What I find interesting or cool to work on
• Whats easy to do using html, php, Visual Basic,
  Java Swing, or whatever
• You may think your idea for a new system is so
  wonderful that everyone will want it, though you
  cant think of a really specific example, and
  that it will be useful in some way to people,
  even though you cant say how. But history
  suggests that you will be wrong. (Lewis and
  Rieman, Chapter 2)?

29
Instead User-Centered System Design

• Base design on real people
• Abilities and needs
• Work context
• Tasks they are trying to accomplish
• Golden Rule of UI Design
• Know Thy User

30
User-Centered System Design

• The design process is a collaboration between
  designers and customers
• The design evolves and adapts to their changing
  concerns
• Designer and customer are in constant
  communication throughout the process

31
Key Components of TCUID

• Phase 1 Identification/definition
• Users and tasks figure out whos going to use
  the system for what
• Create specific usage stories
• Phase 2 Design
• Select tasks to support
• Create designs (mockups first, then prototypes)
  to support these tasks
• Phase 3 Evaluation
• Walk through tasks to test the design
• Test with users

iterate as necessary
32
Who are the users?

• You need to identify real people who will (at
  least potentially) use your system
• if you cant find users, youre in trouble!
• everyone is not a user
• the designer is not a good user
• the VP is rarely the user
• purchasing is rarely the user
• And you sure arent the user!

33
Why you dont count as a user

• You almost certainly arent typical
• Youre too technically savvy
• You dont care (just) about the task
• Its cheating
• Remember
• Design model ? System Image ? Users Model
• But you know the Design Model, so you cant test
  whether the System Image leads users to form an
  appropriate model

34
Spend time with users

• Go talk with the users
• Are they too busy?
• Then how will they have time to evaluate/use it?
• Are there good surrogate users?
• Observe the user at work
• Content what theyre trying to accomplish
• Context physical workplace, organizational
  setting, etc.

35
Talking with users

• What do they know?
• systems, skills, etc.
• What do they do?
• tasks
• How do they do it now?
• scenarios
• What do they want to do?
• new tasks

36
One way to work with users

• Contextual inquiry
• Beyer, Hugh, and Holtzblatt, Karen, "Apprenticing
  with the Customer A Collaborative Approach to
  Requirements Definition," Communications of the
  ACM, May 1995 (available through ACM Digital
  Library, www.acm.org/dl)?
• (More to come on this)?

37
Users arent perfect either

• Users arent all-knowing
• They may have a very narrow view
• They may not be able to articulate what they do
  and what they know
• They may not be able to envision possible new
  ways of doing things
• They arent designers
• You must learn about the tasks from the users
• Then use your design skills to create a design
• Finally, get user feedback on the design/prototype

38
Tasks

• A detailed description of a complete job that
  specific users want to accomplish
• Doesnt specify how they would do the job
  separate the What from the How concentrate on
  the What
• Must specify typical details
• Complete job
• Not just feature lists
• Cover transitions between sub-tasks, so you have
  to consider how different components work
  together
• Specify inputs/outputs where does information
  come from, where does it go?

39
Example Task

• Professor Terveen gets email telling him that
  5115 is scheduled to meet every Monday and
  Wednesday, starting September 3, and ending
  December 10 the final will be sometime during
  the week of December 10. He should enter those
  dates into his calendar, scheduling 945-110 for
  the class. He should also produce a list of
  conflicting appointments that need to be
  rescheduled.

40
Another Example Task

• Professor Terveen is flying on Northwestern
  Airlines to Newark, NJ tomorrow. He wants to
  check in for his flight. He wants to be sure his
  frequent flier number has been entered. He wants
  to be able to check on his seat assignment and
  change to an aisle seat if he isnt already in
  one. Hed also like the seat to be in a row no
  one else is sitting in. After hes got his seat
  assignment, he wants to get a copy of his
  boarding pass.

41
Fundamental role of tasks in TCUID

• represent who actually uses the system
• set goals for system functionality
• basis for design decisions
• Thomas Lets add this cool new feature!!!
• Sharon Why? Which task does it support?
• basis for comparative evaluation of different
  design alternatives
• basis for user testing

42
Defining Tasks

• Concentrate on frequent and infrequent-but-importa
  nt tasks
• 3-5 general-purpose tasks for a very simple
  system
• Separate tasks for special-purpose cases
  (maintenance, installation)?
• 10 tasks for complex systems
• Depth/quality more important than number of tasks

43
From Task to Design

• Write-up tasks, circulate among users
• clarify missing details
• Rough out an interface, using existing systems or
  designs where possible
• Sketch out how each task would be accomplished in
  the interface, then develop scenarios

44
Scenarios

• Specific instances of system use
• From the what to the how
• A particular task
• A particular interface
• What the user would do, in detail
• So someone could complete without task knowledge
• Example
• click on the Check In icon on the screen on
  the next screen, click on the text box next to
  the Please enter your first name label and
  enter your first name,

45
Properties of Scenarios

• Interface-dependent
• Detail appropriate to user, task, interface
• Make certain issues obvious
• how components work together
• design arguments
• tricky parts of the interface
• First step in evaluation

46
Important tasks and scenarios are concrete

• Questions come in different kinds
• Some can be settled through abstract argument
• Are there more real numbers than natural numbers?
• Some only can be settled empirically
• Can students use OneStop.umn.edu to find out
  whether there is room to enroll in CS 5115?

47
Exercise

• Take a look at the student section of
  www.OneStop.umn.edu
• Define 3 tasks (not scenarios) students might try
  to accomplish with the site
• Remember what tasks are used for
• Present tasks, discuss, ask questions

10 minutes
10 minutes