Transcript No Slide Title

• 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 taskcentered 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
• Suppliers
• Local shop
owners
Managers and owners
Customers
Choose Representative Tasks for TaskCentered 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 reexamination 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.
2.
3.
4.
Identify needs and establish requirements
Design potential solutions ((re)-design)
Choose between alternatives (evaluate)
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