05-830, User Interface Software, Spring, 1998
Lecture 4,   January 26, 1998
Copyright © 1998 - Brad Myers

Usability Engineering Design Process

Usability Engineering

• Like Software Engineering, is a process for developing software to help insure high quality.
• Often, UI analysis just tacked on at end of design:
  • UI guys try to fix up the interface, "beautify" the screens
  • Doesn't work, because usability impacts overall design.
  • "Usability is not a quality that can be spread out to cover a poor design like a thick layer of peanut butter."  p. 16.

Iterative Design Process

1. Study the users and their tasks
2. Study the competition
3. Participatory Design
4. Coordinating the Total Interface for Consistency
   • Include documentation, help, etc.
5. Set usability goals
6. Guidelines and Heuristic Evaluation
   • Evaluate your interface according to the guidelines.
7. Make a Prototype or partial implementation of the system early and quickly
   • Actually is faster to prototype first
8. Empirical testing
9. Iterative design
10. Implementation Phase
11. Collect feedback from field use.

Know the User

• Study the intended users and the use of the product
  • Best if developers go and interview them personally
• Difficult because
  • May want to hide the developers
  • Reluctance of sales people
  • Reluctance of users
• User Characteristics
  • Work experience, education level, age, previous computer experience
  • Time for learning, training
  • Social context of use (beep?)

Task analysis

• Extremely important
• What tasks the users will do?
• Information needs: what does the user need to know or view to do this task?
  • Includes what needs to be on the screen.
  • Both: What does the system need to show? What does the user need to know?
• Look for problems in the current mechanisms for achieving the tasks that are susceptible to automation.
• Look at concrete examples of users doing current tasks
• Important to include exceptions and error conditions
• Build up scenarios of typical uses from the task analysis:
  • Specific example of how a user might use the system.
  • One scenario for each major class of users doing each kind of important task
  • Will want to make those tasks efficient and easy
  • What is important to optimize?
  • Will significantly affect the design
  • Try to include lots of exceptional cases
  • Shows how the interface will be used
  • Uses:
    • Refine the interface
    • Demonstrate to management, marketing, customers what your concept is
    • Can replace much textual specification
• Example, company YYY menu structure based on functions rather than tasks => Inefficient for every task!
• Results of task analysis:
  1. Scenarios to be used during design
  2. List of the things users want to accomplish (goals)
  3. Information they will need to accomplish those goals
  4. Steps to be performed and interdependencies
  5. All the various outcomes and reports
  6. Criteria to determine quality of results
  7. Communication needs of users with other people

Functional analysis

• What really needs to be done.
• Not just the way users are doing it now.
  • May be a more efficient or more appropriate way to achieve same task

Competitive Analysis

• "Know the competition"
• For usability and function
• Read trade-press reviews of products in that category
• Importance of various features, issues

Participatory Design

• Users involved in the design process through regular meetings.
• Users are good at reacting to concrete designs and prototypes
• But users are not necessarily good designers

Goal Setting

• What does it mean to be "easy to use"?
• Some proposed definitions:
  • "I like it
  • "I always do it that way"
  • "That is the way the xxx system does it"
  • "It is easy to implement"
• Much better:
  • Can be learned in less than 20 minutes.
  • User will perform 30 error-free operations per minute.
  • The error rate will be lower than 1 per 40 operations.
  • Tasks will be performed in 30% of the time it took before the system was used.
  • Users will have a high satisfaction with the system as measured by a survey.
• Explicit, specific, measurable metrics.
• Tradeoffs, so have to pick relevant metrics.
• Measures (Nielsen, chapter 2, pp. 26-37):
  • Learnability: Time to learn how to do specific tasks (at a specific proficiency)
  • Efficiency: (Expert) Time to execute benchmark (typical) tasks.  Throughput.
  • Errors: Error rate per task. Time spent on errors. Error severity.
  • Subjective satisfaction: Questionaire.
• Pick Levels for your system:
  • Minimum acceptable level
  • Desired (planned) level
  • Theoretical best level
  • Current level or competitor's level

Financial impact analysis

• Prove It!
• Demonstrates the importance of usability
• # users * their salary per hour * # hours on system = cost of system per hour
• Estimate savings of reduced training, error time, need for support staff, etc.
• Tells how much time to spend on usability
• Example:
  F. Montaniz and G. Kissel, "Reversing the Charges," ACM interactions , vol. 2, no. 3, July 1995, pp. 29-33.
  • Cost of Usability Specialists to identify bad error messages = $533
  • Savings from improving the error messages = $411,918
    • From reducing calls to support personel over 6 months
• Whole book on this topic: Randolph G. Bias and Deborah J. Mayhew, Cost-Justifying Usability, Boston: Academic Press, 1994.

Iterative design:

• Redesign the interface based on feedback from evaluation
• New design may be worse or may break something else.
• Keep track of reasons for design decisions
  • Called "Design Rationale"
  • So don't need to keep revisiting the same decisions
  • When future conditions suggest changing a decision will remember why made that way and what implications for change are.
• Instead of arguing about a design feature, figure out what information would tell you which way to go
  • Experiment, marketing data, etc.

Implementation Phase:

• Waterfall model: 1970:
  • Requirements -> Design -> Detailed Design -> Code -> Integration -> Implementation -> Test
  • fully elaborated documents as completion criterea for stages
• "Spiral" model: 1988
  Barry Boehm, "A Spiral Model of Software Development and Enhancement", IEEE Computer, 12(5), May, 1988, pp. 61-72

Collect feedback from field use

• Follow-up after release
• For the next version
• From bug reports, trainers, initial experiences

Prototypes

• Prototypes cheaper because
  • Don't worry about efficiency, robustness
  • Fake data
  • Might not need to implement anything -- fake the system

Uses of Prototypes:

• What questions will the prototype help you answer?
• Is this approach a good idea?
  • Usually only need to test a few people for test:
  • Most results with first 3 people
  • Can refine interface after each test
• Look what a cool design we have!
• Transfer design from UI specialists to programmers
  • Often better than written specifications
• Design A versus Design B
  • Rare, except in academic environments
• What are the real requirements and specifications?

Types of Prototypes:

• Fewer features = vertical
  • Realistic on part
• Less Level of functionality = horizontal
  • Overview of all
• Paper
  • Designer "plays computer"
  • Also called "Low fidelity" prototypes
• "Wizard of Oz"
  • Subject at a computer, but person is at another computer operating the interface.
  • "Pay no attention to that man behind the curtain"
  • Especially for AI and other hard-to-implement systems
• Better if sketchier for early design
  • Use paper or "sketchy" tools, not real widgets
  • People focus on wrong issues: colors, alignment, names
  • Rather than overall structure and fundamental design
• Examples of Prototyping tools
  • HyperCard, etc.
  • Visual Basic
  • MacroMind Director
  • Landay's SILK
  • Interface Builders and other tools for "Real" code
    • C++

Use of the Prototype	Tools
Working out initial ideas	Paper, SILK
Demonstration of the concepts	Paper, Director, Hypercard, VB
Experiments with users	Paper, ~Director, Hypercard, VB
Release "experimental" version	~Hypercard, VB, C++
Real, delivered system	C++

Back to 05-830 main page