Usability Principles

1
Usability Principles UCD

• Guidelines
• Avoiding Bad Design
• User-Centered Design

2
Agenda

• Usability Principles
• Why?
• System of principles
• Good vs. bad design
• User-centered Design (UCD) Process
• Individual steps

3
Good Design (our goal!)

• Every designer wants to build a high-quality
  interactive system that is admired by colleagues,
  celebrated by users, circulated widely, and
  imitated frequently. (Shneiderman, 1992, p.7)
• and anything goes!

4
Why Principles Guidelines?

• Because, well, not everything goes
• Intended to prevent many bad designs before they
  begin, or evaluate existing designs on a
  scientific basis
• Guidelines based on previous designs,
  experimental findings
• Rules can all be broken (but usually in order
  to satisfy another principle)

5
Concepts, Principles, Guidelines

• No cookbooks
• No simple, universal checklists
• There are many concepts, principles, and
  guidelines
• Understand the higher level principles that apply
  across situations, display types, etc.
• Implement the standards and guidelines
• a few details

6
Levels of Consideration

• Meta-display level
• Apply to the whole system, across media across
  displays
• Focus on this in Basic Layout Stage
• Display Layout
• Apply to groups of elements in a display
• Focus on this in Prototyping and Redesign
• Element level
• Details about specific parts of a display
• Colors, sound attributes, symbols

7
UI Design Principles

• Categories
• Learnability
• Support for learning for users of all levels
• Flexibility
• Support for multiple ways of doing tasks
• Robustness
• Support for recovery
• Always think about exceptions, suitability

8
1. Learnability Principles

• Ease with which new users can begin effective
  interaction and achieve maximal performance
• Predictability
• Synthesizability
• Familiarity
• Generalizability
• Consistency

9
Predictability

• I think that this action will do.
• Operation visibilityCan see avail actions
• e.g. menus vs. command shell
• grayed menu items

10
Synthesizability

• Support for user in assessing the effect of past
  operations on current system state
• Moving a file in UNIX shell vs. Mac/Windows
• Is same feedback needed for all users, all apps?

11
Familiarity

• Does UI task leverage existing real-world or
  domain knowledge?
• Really relevant to first impressions
• Use of metaphors
• Potential pitfalls
• Are there limitations on familiarity?

12
Generalizability

• Can knowledge of one system/UI be extended to
  other similar ones?
• Example cut paste in different applications
• Does knowledge of one aspect of a UI apply to
  rest of the UI?
• Aid UI Developers guidelines

13
Consistency

• Likeness in behavior between similar
  tasks/operations/situations
• In different things
• interacting
• output
• screen layout
• Is this always desirable for all systems, all
  users?

14
2. Flexibility Principles

• Multiplicity of ways that users and system
  exchange information
• Dialog Initiative
• Multithreading
• Task migratability
• Substitutivity
• Customizability

15
Dialog Initiative

• Not hampering the user by placing constraints on
  how dialog is done
• User pre-emptive
• User initiates actions
• More flexible, generally more desirable
• System pre-emptive
• System does all prompts, user responds
• Sometimes necessary

16
Multithreading

• Allowing user to perform more than one task at a
  time
• Two types
• Concurrent
• Input to multiple tasks simultaneously
• Interleaved
• Many tasks, but input to one at a time

17
Task Migratability

• Ability to move performance of task to entity
  (user or system) who can do it better
• Spell-checking, safety controls in plant
• For what kinds of tasks should the user be in
  control?

18
Substitutivity

• Flexibility in details of operations
• Allow user to choose suitable interaction methods
• Allow different ways to
• perform actions, specify data, configure
• Allow different ways of presenting output
• to suit task user

19
Customizability

• Ability of user to modify interface
• By user - adaptability
• Is this a good thing?
• By system - adaptivity
• Is this a good thing?

20
3. Robustness Principles

• Supporting user in determining successful
  achievement and assessment of goals
• Observability
• Recoverability
• Responsiveness
• Task Conformance

21
Observability

• Can user determine internal state of system from
  what she perceives?
• Browsability
• Explore current state (without changing it)
• Reachability
• Navigate through observable states
• Persistence
• How long does observable state persist?

22
Recoverability

• Ability to take corrective action upon
  recognizing error
• Difficulty of recovery procedure should relate to
  difficulty of original task
• Forward recovery
• Ability to fix when we cant undo
• Backward recovery
• Undo previous error(s)

23
Responsiveness

• Users perception of rate of communication with
  system
• Response time
• Time for system to respond in some way to user
  action(s)
• Users perceptions not always right
• Consistency important
• Response OK if matches user expectations

24
Task Conformance

• Does system support all tasks user wishes to
  perform in expected ways?
• Task completeness
• Can system do all tasks of interest?
• Task adequacy
• Can user understand how to do tasks?
• Does it allow user to define new tasks?

25
Application

• In doing design and implementation of your
  project, revisit this list
• Assess your design against these usability
  principles

26
Good Design (reminder!)

• Every designer wants to build a high-quality
  interactive system that is admired by colleagues,
  celebrated by users, circulated widely, and
  imitated frequently. (Shneiderman, 1992, p.7)
• and anything goes!

27
The Good
28
The Good
29
The Bad
30
The Bad
31
The Bad
32
The Ugly
33
The (really) Ugly
34
But What Makes it Good?

• Functionality
• Speed efficiency
• Reliability, security, data integrity
• Standardization, consistency
• USABILITY !

35
A Philosophy

• The human user of any system is the focus of the
  design process. Planning and implementation is
  done with the user in mind, and the system is
  made to fit the user, not the other way around.

36
Good Design Means

• Systems are built for humans must be designed
  for the user
• Recognize individual differences appreciate
  design implications of these human factors
• Recognize the design of things, procedures, etc.,
  influences human behavior and well-being
• Emphasize empirical data evaluation
• Rely on the scientific method
• Things, procedures, environments, and people do
  not exist in isolation

37
Good Design is NOT

• NOT just applying checklists and guidelines
• These can help, but UCD is a whole philosophy
• NOT using oneself as the model user
• Know your real users recognize variation in
  humans
• NOT just common sense
• Knowing how to design a fire alarm so it will be
  heard over background noise is not something we
  all know.
• The HF specialist knows where or how to get the
  information needed to answer design questions

38
Design (sidebar)

• Start reading Don Normans DOET
• Well return to design as a focus topic in few
  weeks

39
User-Centered Design

• A way to force yourself to identify and consider
  the the relevant human factors in your design
• Helps reduce the number of decisions made out of
  the blue, and helps focus design activities
• Helps document and defend decisions that may be
  reviewed later

40
The Tao of UCD
DESIGN
IMPLEMENT
USE EVALUATE
41
UCD 9 Step Overview

• Define the Context
• Describe the User
• Task Analysis
• Function Allocation
• System Layout / Basic Design
• Mockups Prototypes
• Usability Testing
• Iterative Test Redesign
• Updates Maintenance

42
Design Implications

• At each stage, consider how the details of your
  discovery process affect your design

43
1. Define the Context

• Context the type of uses, applications
• Life critical systems, applications
• Industrial, commercial, military, scientific,
  consumer
• Office, home, entertainment
• Exploratory, creative, cooperative
• Market
• Customer (not the same as the User)
• Design Impacts?

44
2. Describe the User

• Physical attributes(age, gender, size, reach,
  visual angles, etc)
• Physical work places(table height, sound levels,
  lighting, software version)
• Perceptual abilities(hearing, vision, heat
  sensitivity)
• Cognitive abilities(memory span, reading level,
  musical training, math)
• Personality and social traits(likes, dislikes,
  preferences, patience)
• Cultural and international diversity(languages,
  dialog box flow, symbols)
• Special populations, (dis)abilities

45
3. Task Analysis

• Talk to and observe users (NOT customers) doing
  what they do
• List each and every TASK
• Break tasks down into STEPS
• ABSTRACT into standard tasks(monitor, diagnose,
  predict, control, inspect, transmit, receive,
  decide, calculate, store, choose, operate, etc.)

46
4. Function Allocation

• Consider the whole system!
• Decide who or what is best suited to perform each
  task (or each step)
• e.g., system remembers login id, and reminds the
  user, but user remembers the password
• Base this on knowledge of system hardware,
  software, human users abilities, culture,
  communications protocols, privacy, etc.
• Allocation constraints Effectiveness
  Cognitive/affective Cost Mandatory
• Dont forget the design implications!

47
5. System Layout / Basic Design

• Summary of the components and their basic design
• Cross-check with any Requirements Documents
  Human Factors refs Hardware specs Budgets Laws
  (ADA) etc.
• Ensure that the system will support the design
  and comply with constraints
• (Verification and Validation, in the language of
  software engineering)

48
6. Mockups Prototypes

• Informed Brainstorming
• RAPIDLY mock up the user interfaces for testing
  with real people
• Pen and paper or whiteboard to start
• Iterate, iterate, iterate!!
• Increasingly functional veridical
• List audio visual details at same levels of
  detail in the prototypes
• (i.e. dont forget either of them)

49
7. Usability Testing

• Get real (or representative) users to do what
  they do, using the prototypes
• Subjective and objective feedback. Sometimes
  users want features that actually yield poor
  performance
• Video tape, lots of notes
• Be rigorous wherever possible (stats, etc.)
• Feedback into the iterative evaluation redesign
  of the system
• Discount usability testing can be very
  effective, using fewer subjects, more rapid
  results

50
8. Iterative Test Redesign

• Repeat cycles of testing and reworking the
  system, subject to cost/time constraints
• Focus on Functionality First !
• Plan for several versions during development

51
9. Updates Maintenance

• In-the-field feedback, telemetry, user data,
  logs, surveys, etc.
• Analyze and make iterative redesign/test
  recommendations
• Updates and maintenance plan as part of the
  design!
• (design it so it can be fixed or updated)

52
UCD 9 Step Overview

• Define the Context
• Describe the User
• Task Analysis
• Function Allocation
• System Layout / Basic Design
• Mockups Prototypes
• Usability Testing
• Iterative Test Redesign
• Updates Maintenance

Design Implications?!!
53
UCD Focusing Your Efforts

• There are real-world constraints
• Cutting out steps is not the way to economize!
• Optimize the efficiency of each step
• Here Focus on the context and the user, to get
  the most value for the time spent

54
Short HW 1

• Interfaces in your environment
• Kiosk in student center

55
Next on the Menu

• Human Abilities
• Physical (senses)
• Cognitive
• SHW 1 due
• Project Milestone 0 due
• Read ch. 1, 2