What is a good length of string

1

• What is a good length of string?
• Depends on its use
• Can be determined by a process
• What is a good interface.
• Depends on its use
• Can be determined by a process

2
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

3
The Task-Centered Design Process (Continued)

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

4
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

5

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

6
Some practical issues

• Who are the users?
• What are needs?
• Where do alternatives come from?
• How do you choose among alternatives?

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

8
Who are the stakeholders?
Check-out operators
Suppliers Local shop owners
Customers
Managers and owners
9
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

10
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

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

12
Rough Out the Design

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

13
Think About It

• Formal analysis methods are available and may
  help.
• Examples
• Action analysis (GOMS modeling)
• counting keystrokes and mental operations
• Cognitive walkthroughs

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

15
Test the Design With Users

• Users think aloud while doing representative
  task.
• Record time, errors, problems or surprises.

16
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

17
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

18
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

19
Managing the Design Process

• Task-Oriented Vs. Waterfall Design
• waterfall does not allow the iterations needed
  for a deep understanding of the users 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

20
Summary

• Four basic activities in the design process
• Identify needs and establish requirements
• Design potential solutions ((re)-design)
• Choose between alternatives (evaluate)
• Build the artefact
• User-centered design rests on three principles
• Early focus on users and tasks
• Empirical measurement using quantifiable
  measurable usability criteria
• Iterative design