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 Customers Managers 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 process 1.Identify needs and establish requirements 2.Design potential solutions ((re)-design) 3.Choose between alternatives (evaluate) 4.Build the artefact User-centered design rests on three principles 1.Early focus on users and tasks 2.Empirical measurement using quantifiable & measurable usability criteria 3.Iterative design