Task-Centered User Interface Design: An Introduction

Hall of Shame: AC Remote

Giant button in the middle affords pushing,

but it’s not actually a button

Buttons are similarly shaped, do different

things. Bad visibility.

Button layout could be improved (fan buttons

grouped together, fan arrows unnecessary,

etc)

Hall of ShameAshley Perkins

Ceiling Fan

Current Solutions

User Visit Plans Due Friday

• Written, but informal– specific goals, approaches, people, dates, and times– general ‘script’ indicating who will ask or observe what in

what sequence – what types of notes you will take (do you need note-taking

forms?)• Grade

– How clearly you have thought through what you need to learn from the visits and how you’ll gather this knowledge

Exercise

• Consider the general task of voting– A voter chooses one (or more) candidate from a

set of candidates for a particular office– In a given election, voters may have to make

choices for multiple offices

Exercise – Part 1

• Consider users– Who are they?– What are relevant user characteristics?

• Result write personas describing two users

Some example users

• Voter• Poll worker• Vote counter• Party official / candidate representative

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

System-Centered Design

• What I find interesting or cool to work on• What’s easy to do using: html, 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 can’t think of a really specific example, and that it will be useful in some way to people, even though you can’t say how. But history suggests that you will be wrong. (Lewis and Rieman, Chapter 2)

Instead: User-Centered System Design

• Base design on real people:– Abilities– Needs– Work context– Tasks they are trying to accomplish

• Golden Rule of UI Design:–“Know Thy User”

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

Key Components of TCUID• Phase 1 – Identification/definition

– Users and tasks – figure out who’s going to use the system for what

– Create specific scenarios• 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

What we’ll cover today

iterate as necessary

Who are the users?

• You need to identify real people who will (at least potentially) use your system– if you can’t find users, you’re 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 aren’t the user!

Why “you” don’t count as a user

• You almost certainly aren’t typical– You’re too technically savvy– You don’t care (just) about the task

• It’s “cheating”– Remember:

• Design model System Image User’s Model– But you know the Design Model, so you can’t

test whether the System Image leads users to form an appropriate model

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 they’re trying to accomplish– Context – physical workplace, organizational

setting, etc.

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

Users aren’t perfect either

• Users aren’t 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 envision possible new ways of doing

things• They aren’t 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

Tasks• A detailed description of a complete job that specific

users want to accomplish• Doesn’t 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?

Sample Task - Poor

The user selects the stories that will be in the “news” section of the website.

Sample Task - Better

The user selects from a collection of stories the stories that will be in the “news” section of the website. The user has the ability to edit the list including ordering, and adding/removing incorrect stories.

Sample Task - Detailed

Rita Neus, the on-line production coordinator for the paper sits down at 1:30 AM before going home for the night, and – Selects the stories stokeef.xy, stguns.xy, stvet.xy,

stwres.xy, stcomp.sy (in that order) for the “news” section of the website.

– She decides that stvet.xy should be the lead story– She realizes that stwres.xy is actually a sports story and

moves it to that department.

Sample Task - Poor

The user sets up a schedule for a guest visitor and makes it available for others.

Sample Task - Better

The user sets up a schedule for a guest visitor. This schedule includes 4 or 5 “template” events (some fixed time and some variable time). The schedule is announced so that others can sign up.

Sample Task - DetailedDr. Schafer, head of the search committee, is in charge

of setting up the schedule for the campus visit of a job candidate (Sal Lammy) on February 7th.

He schedules – time to take the candidate to lunch, and dinner. – 3:30-4:30 PM for the candidate’s research talk.– 4:30-5:30 for the “wine and cheese reception.”– A 90-minute block for a campus tour which ends with a

meeting with the Dean (check with the Dean on availability).

He contacts the other members of the department and allows them to schedule 30 minute meetings with the candidate for any time slot not yet taken and to join meals.

Why Tasks?

• Tasks are fundamental to TCUID– represent who actually uses the system– set goals for system functionality– basis for system design

• Thomas: “Let’s add this cool new feature!!!”• Sharon: “Why? Which task does it support?”

– basis for comparative evaluation of different design alternatives

– basis for user testing

Defining Tasks

• Concentrate on frequent and infrequent-but-important 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

Exercise

• Consider the general task of voting– A voter chooses one (or more) candidate from a

set of candidates for a particular office– In a given election, voters may have to make

choices for multiple offices

Exercise – Part 1

• Consider users– Who are they?– What are relevant user characteristics?

• Result write personas describing two users

Some example users

• Voter• Poll worker• Vote counter• Party official / candidate representative

Exercise – Part 2

• Now consider tasks– Write 2 task descriptions

• Who are the users?• What are they trying to do?

Next Steps

• For next time (next week)– Continue discussion of the task-centered user interface

design process– Spend some time talking about the UIDP readings

• Project– Friday will be our first official studio– Project Proposal– Site Visit Plan