Task Centered User Interface Design

1
Task Centered User Interface Design

• Overview of
• Task Centered U.I. Design Approach
• Explains U.I. design/development as a part of the
  entire software systems development

2
Task-Centered Design Process

• Whos doing what?
• Representative tasks?
• Plagiarize
• Rough out a design
• Think about it

• Create mock-up
• User test the design
• Iterate
• Build it
• Track it
• Change it

3
Who is doing what??

• Called task and user analysis in the HCI industry
• Must be more than doing whats needed
• Must merge smoothly into the users existing
  world and work

4
Who is doing what?

• Ease of correcting errors
• Hardware should fit in workspace
• Users Systems require certain features
• Traditional Requirements Analysis miss much of
  these considerations

5
Choosing Representative Tasks

• Task-centered design begins by
• Choosing several representative tasks
• Tasks described by users
• Initially short descriptions
• Validated and supported by
• User Task Analysis

6
Choosing Representative Tasks

• Tasks represent complete functionality of system
• Simple tasks aid early design
• Complex tasks reveal interface problems
• Tests designers understanding of users and tasks

7
Plagiarize

• Not in the legal sense!!!!
• Build on ideas from other interfaces
• Effective for
• High-level interaction
• Low-level control/display

8
Plagiarize

• High Level paradigm examples
• Spreadsheet cell by cell entry
• Object-oriented graphics package
• Benefits of plagiarizing High Level
• Lower risk (drawing on users models)
• Fewer design decisions to make
• Easier to implement

9
Plagiarize

• Low Level Detail Examples
• Button placement, Menu names
• Keystoke sequences
• Benefits of plagiarizing Low-Level
• User familiarity with product
• Reduction of user errors
• Fewer design decisions to make

10
Roughing out a Design

• Begin by putting the design on paper
• Programming effort demands
• Design decisions too early
• All proposed features justifiable by the
  representative tasks

11
Roughing out the Design

• Representative tasks are a checklist
• Features not supporting a task are eliminated
• Any task not supported gt more development
• Tasks supported gt done this round

12
Thinking About The Design

• Assess the design before the high-fidelity
  prototype
• User evaluations
• Cognitive walkthroughs
• GOMS analysis or
• Heuristic evaluations

13
Creating a Prototype

• Using paper prototypes and
• Use prototyping systems or
• (Hyper Card, Demo Package, )
• Use development tools

14
Creating a Prototype

• No need to implement entire design
• Focus on representative tasks
• Emulate System Functionality
• Wizard of Oz
• Preloaded appropriate responses (Danger!)

15
User Testing

• Get users to
• Perform one or more representative tasks
• Think aloud as they go
• Dont Coach
• Record test (videotape)
• note times, errors, problems, surprises

16
Iterating

• Design will most likely need revising
• Use testing to spot problems
• Balance costs of solutions vs. severity
• Test again
• Stop testing once usability objectives are met

17
Building the System

• Prototyping with the development tool helps
• However!! Build for change
• Modular code and good software engineering

18
Building the System

• Dont hardcode things like
• Colours, sizes, number of items
• Use variables that are easily changed
• Good code is important! U.I. ½ of code

19
Tracking the System

• Interface Designers should not be isolated!
• Designers communicating with users
• Temporary duty on service hotline??

20
Tracking the System

• Try to answer
• Is the system doing what it is designed to?
• Also
• What else are users doing with it?

21
Changing the System

• Often systems inadequate in a few years
• Tasks and users change
• Work patterns change
• Revisions respond to problems and opportunities

22
Getting to Know Users and Their Tasks

• Chapter 2 discusses what is needed from user and
  task analysis in the
• Task-Centered User Interface Design Method

23
Identify the Users and Tasks

• Called task and user analysis in the HCI industry
• Must be more than doing whats needed
• A successful system must merge smoothly into the
  users existing world and work

24
Task-CenteredUser Interface Design

• Identify the tasks the users will want to
  accomplish with the system
• Use these tasks to
• Raise issues about design
• Aid in making design decisions
• Evaluate the design as it is developed

25
Look at the Details of the Tasks

• Request information in the order the users
  likely to receive it
• Must be easy to correct previously entered data
• Hardware should fit into the available space

26
Understand the User

• Awareness of the users background knowledge
  helps designers choose
• Appropriate names for menu items
• Materials to include in training packages and
  help files
• What features the system should provide

27
Communication Important I

• Effective task and user analysis requires
  effective communication between
• Members of the design team
• People who are the future users

28
Effective Communication II

• Designers may have to persuade their managers
  that on-site visits are necessary
• Managers of users may want to be the sole
  specifiers of the system that they are funding

29
Task and User Analysis

• Dont rely on illusory customers.
• Startup company wanted to build a system to help
  people build intelligent tutoring systems
• Did not stop to determine exactly who would use
  the system to do exactly what

30
Generic and Designer Users

• Im not trying to support any special
  population. My system is a tool for any XXX user,
  no matter what theyre working on.
• Experience shows that many ideas that are
  supposed to be good for everybody arent good for
  anybody

31
Requirements Analysis

• Ground requirements on real people tasks
• Step 1 find people who are potential users
• Step 2 get them to spend time with you
• Discuss what they do and how your system might
  fit in

32
Choosing Representative Tasks

• Develop concrete, comprehensive, detailed
  examples of tasks users perform or want to
  perform
• i.e., tasks that your system should support
• Warning make sure your contact is directly with
  the users

33
Example Project

• Develop a system for modelling traffic street
  layout, traffic volumes, accidents etc.
• Provides a GUI which allows small changes to the
  model and examines the results
• Developed a list of twelve things that users
  would want to do with the system

34
Description of an Example Task

• Change the speed limit on Carling Avenue between
  Island Park Drive and Bronson Avenue. Calculate
  projected traffic flows on Carling Avenue west of
  Preston assuming speed limits on Carling between
  40 and 80 in increments of 5 kph.

35
Analysis of Example Task I

• States what the user wants to do but does not say
  how the user should do it.
• Makes no assumptions about the nature of the
  modelling tool / interface
• Thus can be fairly used to compare design
  alternatives for the system and interface

36
Analysis of an Example Task II

• Very specific statement
• States not only exactly what the user wants to
  do, but also specifies particular streets
• Forces you to face domain specific details when
  evaluating relevant designs

37
Analysis of Example Task III

• Describes a complete job
• Doesnt just say
• Change the speed limit or
• Calculate the projections for Carling Avenue
• Forces designers to consider how features of the
  interface work together

38
Analysis of Example Task IV

• Tasks should mention who users are
• Allows you to get more information if it becomes
  relevant
• Note user characteristics that will be important
• What their job is
• What expertise they have

39
Describing a Complete Job I

• A key feature of the task-centered approach
• Often requirements are lists of little things the
  system should do
• Doing the complete job may be tedious,
  frustrating, difficult, and/or awkward

40
Describing a Complete Job II

• Must determine where inputs come from and where
  outputs go.
• How are traffic model parameters changed?
• Where do simulation outputs go?
• No answers
• ? system wont perform well in practice

41
Choosing Sample Tasks I

• Choose examples that illustrate the kinds of
  support that you (as a designer) think the system
  should provide
• Outline what the system does in generalities
• Try to find tasks that are examples of these

42
Choosing Sample Tasks II

• Also need to reflect the interest of the
  potential users
• Find tasks that illustrate the proposed
  functionality in the context of the work users
  really want to do

43
System Functionality I

• During the design process, some possible
  functions of the system may be dropped
• Designers might opt for optimization functions
  that can change parameters in the traffic model
  to find best results (given measure of quality)
• Users may say they prefer to solve problems by
  framing and evaluating alternative combinations
  of parameters themselves

44
System Functionality II

• Not uncommon for designers and users to disagree
  on the usefulness of a function
• No simple resolution exists
• designers put optimization on hold
• convinced that users would eventually want it

45
System Functionality III

• The user not ALWAYS right
• Designers often have insight into future of
  technology (insight that users lack)
• Be careful!

46
System Functionality IV

• Most designers are outsiders to the task domain
• Recognize that users know a lot more about their
  work than you do!

47
Industry Example

• A company was hired to develop an interface for a
  file management system
• Interface passed the lab tests but not user
  tests
• The scrolling file list was 20 characters wide
• The file names customers used were often
  identical for more than twenty characters!

48
Second Industry Example

• Company asked to evaluate a phone-in bank service
  that passed all lab tests
• Users could check their balance, see if a check
  had cleared, etc.
• Test tasks did not test transitions between
  options
• Significant problems ensued.

49
Third Industry Example

• An early business graphics package had
  disappointing sales
• Worked well when users typed in numbers
• Performed badly when input was a file
• System did a good job of making the graph, but
  file IO was not considered

50
Fourth Industry Example

• Oncocin a cancer therapy advisory system
• Doctors unwilling to spend a little time to learn
  a new system
• Medical technicians could ordered to learn the
  tool
• The Oncocin designers first decided who their
  user group was