TaskCentered User Interface Design: An Introduction

1
Task-Centered User Interface Design An
Introduction
2
(No Transcript)
3
Problems

• Jumping
• Replacement

4
Jumping

• Connections
• Black to Ground
• Red to Red
• Gulf of Execution
• Poor visibility of battery
• No easy way to access battery points

5
Replacement

• Process
• Remove retaining bar
• Remove washer fluid container
• Gulf of execution
• Steps are visible (barely), but are there are
  more than usually necessary

6
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 youll
  gather this knowledge

7
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

8
System-Centered Design

• What I find interesting or cool to work on
• Whats 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
  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)

9
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

10
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

11
Key Components of TCUID
What well cover today

• Phase 1 Identification/definition
• Users and tasks figure out whos 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

iterate as necessary
12
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!

13
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

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

15
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

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

17
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?

18
Sample Task - Poor

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

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

20
Sample Task - Detailed

• Rita Neus, the on-line production coordinator for
  the paper sits down at 130 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.

21
Sample Task - Poor

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

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

23
Sample Task - Detailed

• Dr. Wenthold, 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.
  
• 330-430 PM for the candidates research talk.
• 430-530 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.

24
Why Tasks?

• Tasks are fundamental to TCUID
• represent who actually uses the system
• set goals for system functionality
• basis for system design
• 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

25
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

26
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

27
Exercise Part 1

• Consider users
• Who are they?
• What are relevant user characteristics?
• Result ? write personas describing two users

28
Some example users

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

29
Exercise Part 2

• Now consider tasks
• Write 2 task descriptions
• Who are the users?
• What are they trying to do?

30
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