Usability

1
Usability
2
User Satisfaction (or not)
As users, it is often easy to become distracted
by the pretty colours and graphics, the flashing
lights and the cute sounds. We dont notice
quite often how primitive our computer systems
currently are.
3
Computer User Interfaces - 1984
4
Computer User Interfaces - 2007
5
The Productivity Paradox

• Annual increase in productivity1950 - 1960 3
• Annual increase in productivity1960 - 1990 1
• Personal computers have not significantly
  improved the productivity of the workforce in the
  last 30 years.

6
The Paradox of the Active User

• People have trouble using computers.
• They tend to achieve a mediocre level of skill.
• The active user tends to be the least efficient.

7
The Paradox of the Active User
Indeed, the typical pattern we have observed is
that people simply strike out into the unknown...
If something can be interpreted...then it will be
interpreted. Interfacing Thought Cognitive
Aspects of Human-Computer Interaction, edited by
John M. Carroll, Cambridge, MA, MIT Press, pp.
80-111.
8
Production Paradox
It is good to want to get something done. One
would only ever want to learn to use a new tool
if one wanted first to get something done. But
wanting to get something done can also be a
problem, if one lacks the prerequisites you have
to learn to do in order to do. Merely wanting to
use a new tool may be necessary but it is not
sufficient.
9
Users Know Stuff

• Most users are experts in their domain.
• When they use a system
• it is to get real work done,
• it is to work in their area of expertise,
• it is not to read step-by-step instructions.
• Novices in a domain require more support.

10
Ways to Fix This

• Ease the focus on end-products
• make benefits of learning more obvious,
• increase the level and variety of user feedback.
• Make learning safe.
• Give the users what they want.
• Manuals should be task-oriented rather than
  process-oriented.

11
A Supportive Environment

• Allow the user to learn.
• Allow the user to experiment safely.
• Allow the user to develop skills (easily).
• Dont constrain the system to operating the way
  you want it to
• You wont be able to. The user will always find a
  way to bend the rules of your system.

12
Consequences of Actions

• Make sure the user is aware of consequences of
  their actions.
• Avoid dangerous actions happening behind the
  scenes.
• Avoid actions that can happen without the users
  consent.

13
Test Before Installation
14
User Screwups

• No matter how simple you (as a designer) think
  the system is, there will always be a user who
  will make a mistake, break something, or
  misunderstand your intentions.
• Just when you think you have made your system
  foolproof, someone invents a better fool.
• As a designer, you should not get upset or angry
  when a user breaks your system.

15
Tog on User Testing

• Programmers test
• Architects test
• Iterative design and testing will produce
  consistently successful results.

16
Tog on User Testing

• Fix problems before you ship
• Concentrate on real problems
• Test, dont debate
• Reduce development time
• Sell stuff that works

http//www.asktog.com/columns/037TestOrElse.html
17
Designing for Usability

• Early Focus on Users
• Early User Testing
• Iterative Design
• Integrated Design

Gould, J. 1988. How To Design Usable Systems.
In M. Helander (ed.) Handbook of Human-Computer
Interaction. North-Holland, 1988. pp 757-789.
18
Early Focus On Users

• Decide who the users will be,
• Talk with users,
• Visit the customer's work location,
• Observe users working,
• Analyse the users tasks,
• Participatory design,
• Set behavioural goals.

19
Fictional Users (personae)

• Develop a precise description of the user and
  what (s)he wishes to accomplish.
• Cannot always use a real person, who may not know
  the answer anyway.
• Make up pretend users and design for them.

20
Personae vs the elastic user

• We are always specific about the OS that we are
  targeting.
• We need to be equally specific about the user.
• Users are elastic, personae are not.

21
Defining a persona (1)

• It must be precise, although not necessarily
  accurate.
• Should define the centre of the target
  population, not the edge.
• That said, personae are specific, not averages.

22
Defining a persona (2)

• For all but the largest project there should be
  no more than 3 personae, one defined to be the
  primary persona.
• Personae will have names, occupations, attributes
  and characteristics.
• Even worthwhile finding pictures to show people.

23
Early User Testing

• Paper-based scenarios.
• Write the user manual first.
• Early prototypes and simulations.
• Evaluate prototypes.
• Try To Destroy It.
• Field evaluation.

24
Iterative Design

• Use tools to make development efficient.
• Avoid unexpected changes.

25
Case Studies

• Roll-aboard suitcase.
• Sticky notes.
• Dodge Ram pickup (ute).
• Happy customers.

26
Next Lecture
More on Usability
27
Resources

• http//www.sitepoint.com/article/real-history-gui
• http//www.joelonsoftware.com
• http//www.asktog.com (In particular
• http//www.asktog.com/columns/065WorstInterface.h
  tml,
• http//www.asktog.com/Bughouse/10MostWantedDesign
  Bugs.html)
• Library Books
• The inmates are running the asylum, Alan Cooper.
• Designing Web usability, Jakob Nielsen.
• Taming Hal designing interfaces beyond 2001,
  Asaf Degani
• User interface design for programmers, Joel
  Spolsky