• What is a good length of string?– Depends on its use

• How do you design a good length of string?– Can be determined by a process

• What is a good user interface?– Depends on its use

• How do you design a good user interface?– Can be determined by a process

The Task-Centered Design Process

• figure out who's going to use the system to do what

• choose representative tasks for task-centered design

• plagiarize• rough out a design• think about it• create a mock-up or prototype

The Task-Centered Design Process (Continued)

• test it with users• iterate• build it• track it• change it

Figure Out Who's Going to Use the System to Do What

• industry terminology: “task and user analysis.” “personas” “user experience"

• need for task analysis goes beyond “doing what's needed”

• traditional requirements analysis can miss a multitude of interface considerations

• understanding of the users themselves is equally important

• task and user analysis requires close personal contact between members of the design team and the people who will actually be using the system. this is hard but: “It's certain, however, that early and continued contact between designers and users is essential for a good design.”

Some practical issues

• Who are the users?

• What are ‘needs’?

• Where do alternatives come from?

• How do you choose among alternatives?

Who are the users/stakeholders?• Not as obvious as you think:

– those who interact directly with the product– those who manage direct users– those who receive output from the product – those who make the purchasing decision – those who use competitor’s products

• Three categories of user (Eason, 1987): – primary: frequent hands-on– secondary: occasional or via someone else– tertiary: affected by its introduction, or will influence

its purchase

Who are the stakeholders?Check-out operators

CustomersManagers and owners

• Suppliers• Local shop

owners

Choose Representative Tasks for Task-Centered Design

• In contrast to software engineering's formal specifications

• formal specification don't work because people are unpredictable

• representative tasks keeps the design focused on users and usability

• Choosing these becomes easier if you've done a good job in step one.

• They must be real task actually described by the users

Choose Representative Tasks

• Tasks should completely cover the functionality of the system

• can make a checklist of functions and compare those to the tasks to ensure that coverage has been achieved.

• Examples– for a word processor: “transcribe a memo and send it to a

mailing list” – for a spreadsheet: “produce a salary budget for next year” – for a communications program: “login to the office via modem” – for an industrial control system: “hand over control to next

shift”

Plagiarize

• Not in the legal sense, of course• Find existing interfaces that work for users and

then build ideas from those interfaces into your systems

• People will be able to learn your system faster if is like something they already know.

• Look past the requirements of your system; the “best” solution for your system may not work if inconsistent with other systems the users have.

• Stick to what the user knows if possible, but look for improvements.

Rough Out the Design

• Don't commit too early• Don't program yet• Sketch ideas... explore alternatives• Check your design against the

representative tasks

Think About It

• Formal analysis methods are available and may help.

• Examples– Action analysis (GOMS modeling)

• counting keystrokes and mental operations

– Cognitive walkthroughs

Create a Mock-Up or Prototype

• Need to begin to show the users something

• Even low fidelity prototypes reveal problems and misunderstandings.

• Wizard of OZ emulation can be effective.

Test the Design With Users

• Users think aloud while doing representative task.

• Record time, errors, problems or surprises.

Iterate

• Test to improve, not prove (e.g. change it and test again)

• Severe problems may even require a re-examination of the tasks and users

• Iterate until:– usability objectives have be been met– management decides benefit of further

improvement is less than cost of not getting product to market

Build the Design

• Build for change (modular object oriented style is best)

• If using RAD tool (i.e. UIMS) for prototypes much is already done

Track the Design & Change the Design

• Designers should not be isolated from the marketplace (the real customers).

• Designer must have contact with users after the design hits the street

• interactions with users can also yield surprises about other applications that have been found for the product

• results in better task descriptions for the next revision

Managing the Design Process

• Task-Oriented Vs. Waterfall Design – waterfall does not allow the iterations

needed for a deep understanding of the user’s task

• The Design Team – they need to care about users– they need to have experience with both bad

and good interfaces– they need to be committed to and optimistic

about creating an effective system

• Responsibility should be centralized

Summary

Four basic activities in the design process1. Identify needs and establish requirements2. Design potential solutions ((re)-design)3. Choose between alternatives (evaluate)4. Build the artefact

User-centered design rests on three principles1. Early focus on users and tasks2. Empirical measurement using quantifiable &

measurable usability criteria3. Iterative design