Overview of HCI Design and Implementation

Notes for HCI Talk by Brad A. Myers Human Computer Interaction Institute School of Computer Science Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213-3891 (412) 268-5150 FAX: (412) 268-1266 bam+@cs.cmu.edu http://www.cs.cmu.edu/~bam

October 28, 1999

These notes are stored on:
http://www.cs.cmu.edu/~bam/uicourse/special/

Good references:

Lecture notes for my course: User Interface Software, http://www.cs.cmu.edu/~bam/uicourse/1999spring/

Jakob Nielsen. "Usability Engineering". Boston: Academic Press, Inc. 1993. ISBN 0-12-518405-0.

Randolph G. Bias and Deborah J. Mayhew, Cost-Justifying Usability, Boston: Academic Press, 1994.

Talk Abstract

Why are so many user interfaces hard to use? Why are user interfaces difficult to design and implement? What is the Usability Engineering Process, and how can it help improve user interfaces? Why should companies employ people trained in user interface design? This talk will provide a quick overview of the challenges and opportunities in user interface design and implementation, also called Human-Computer Interaction. It will conclude with a list of design principles that should be considered when designing and evaluating user interfaces.

HCI at CMU

Human-Computer Interaction Institute
- Over 50 professors associated with it
- MS, BS and new PhD programs
- HCI specialization in MSE program
- http://www.cs.cmu.edu/~hcii
Weekly HCI seminar series
- Wednesday afternoons at 3:30 in 5409
Monthly lunch meetings of HCI faculty
Let me know if you want to be on the HCII mailing list: pgh-hci@cs.cmu.edu

Why are Interfaces Important, and
Why are they Hard
To Design and Implement?

Why Are User Interfaces Important?

Sit-down-and-use computers and software
- don't read the manuals
Usability is critical to software sales:
- In magazine ratings
- "User friendly"
Productivity paradox
HCI-trained people build better interfaces.
- Programmers don't think like end-users
- Exposure to different kinds of interfaces, problems
- User model, not system model
- Guidelines
There are well-defined methods and techniques
Not just opinions, luck, domain-experience
Very expensive to not do usability engineering
- Interfaces will be re-designed: before or after release
- Studies show that usability engineering saves money
  - $39,000 $613,000 $8,200,000
  - Up to 5000 times the cost
- Disasters
  - Aegis
  - Therac-25
Recognized by industry, government, etc.
- Plenty of jobs.
- Money for research
Significant time and code devoted to HCI now
- Brad A. Myers and Mary Beth Rosson. "Survey on User Interface Programming," Proceedings SIGCHI'92: Human Factors in Computing Systems. Monterrey, CA, May 3-7, 1992. 195-202.

Percent devoted to the UI:

Why Are User Interfaces Hard to Design?

``It is easy to make things hard. It is hard to make things easy.''
User Interface design is a creative process.
Designers have difficulty thinking like users:
- "Know thy user"
- Often need to understand task domain
- Specifications are always wrong
- "Only slightly more than 30% of the code developed in application software development ever gets used as intended by end-users. The reason for this statistic may be a result of developers not understanding what their users need."
  -- Hugh Beyer and Karen Holtzblatt, "Contextual Design: A Customer-Centric Approach to Systems Design," ACM Interactions, Sep+Oct, 1997, iv.5, p. 62.
- Need for prototyping and iteration
- Can't "unlearn" something.
  - After you know what is there, it is hard to remember how "not" to see it!
Tasks and domains are complex
- MacDraw 1 vs. Illustrator
- CAD programs with 1000 commands
Various aspects of the design must be balanced
- Standards (style guides, related products)
- Graphic design (artistic)
- Technical writing (Documentation)
- Internationalization
- Performance
- High-level and low-level details
- External factors (social issues)
- Legal issues
- Time to program and text
- Special requirements (CSCW, etc.)
All UI design involves tradeoffs
Existing theories and guidelines are not sufficient
- Too specific and/or too general
- Standard does not address all issues.
- Macintosh standard UI could be all dialog boxes and menus.
- Not sufficient just to use icons and windows
Iterative Design is difficult
- Getting users
- Running tests
- Changes make the system worse

Why Are User Interfaces Hard to Implement?

They are hard to design, requiring iterative implementation
- Not the waterfall model: specify, design, implement, test, deliver.
They are reactive and are programmed from the "inside-out"
- Event based programming
- More difficult to modularize
They generally require multi-processing
- To deal with user typing; aborts
- Window refresh
- Window system as a different process
- Multiple input devices
There are real-time requirements for handling input events
- Output 60 times a second
- Keep up with mouse tracking
- Video, sound, multi-media
Need for robustness
- No crashing, on any input
- Helpful error messages and recover gracefully
- Aborts
- Undo
Lower testability
- No tools for regression testing
Little language support.
- Primitives in computer languages make bad user interfaces
- Enormous, complex libraries
- Features like object-oriented, constraints, multi-processing
Complexity of the tools
- Full bookshelf for Microsoft MFC and friends
Difficulty of Modularization

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." Nielsen text, p. 16.

Iterative Design Process

Study the users and their tasks
Study the competition
Participatory Design
Coordinating the Total Interface for Consistency
- Include documentation, help, etc.
Set usability goals
Guidelines and Heuristic Evaluation
- Evaluate your interface according to the guidelines.
Make a Prototype or partial implementation of the system early and quickly
- Actually is faster to prototype first
Empirical testing
Iterative design
Implementation Phase
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?
- Involve the user in getting them.
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 Windows95 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.
Objective 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
For Web applications, users just go elsewhere
# 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.
- Objective, rational, "scientific" way to make design decisions

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
- Visual Basic
- MacroMind Director
- Visio
- Interface Builders and other tools for "Real" code

User Interface Guidelines

Attributes of good UIs:

1) Invisible
2) Minimal training requirements (easy to learn)
3) High transfer of training (easy to remember)
4) Predictability
5) Few errors
6) Easy to recover from errors
7) People perform real tasks well (efficient to use)
8) It is flexible
9) It is intelligent
10) People like it (subjectively pleasing)
11) ... and many others

Usability Slogans
(Jakob Nielsen, "Usability Engineering", ch 1)

Your best guess is not good enough
The user is always right
The user is not always right
Users are not designers
Designers are not users
Vice presidents are not users
Less is more
Details matter
Help doesn't
Usability engineering is a process

More slogans

1) Things that look different should act different.
2) If it is not needed, it's not needed.
3) The information for the decision needs to be there when the decision is needed.
4) The user should control the system. The system shouldn't control the user. The user is the boss, and the system should show it.
5) The idea is to empower the user, not speed up the system.
6) Don't overload the user's buffers.
7) Keep it simple.
8) Things that look the same should act the same.
9) The user should be able to do what the user wants to do.
10) Every action should have a reaction.
11) Everything in its place, and a place for everything.
12) Let people shape the system to themselves, and paint it with their own personality.
13) Error messages should actually mean something to the user, and tell the user how to fix the problem.
14) The best journey is the one with the fewest steps. Shorten the distance between the user and their goal.
15) Everyone makes mistakes, so every mistake should be fixable.
16) The more you do something, the easier it should be to do.
17) Cute is not a good adjective for systems.
18) Keep it neat. Keep it organized.
19) Consistency, consistency, consistency.
20) The user should always know what is happening.
21) Minimize the need for a mighty memory.
22) Know they user, and YOU are not thy user.
23) If I made an error, at least let me finish my thought before I have to fix it.
24) Design for regular people and the real world.
25) Eliminate unnecessary decisions, and illuminate the rest.
26) You should always know how to find out what to do next.
27) If I made an error, let me know about it before I get into REAL trouble.
28) Even experts are novices at some point. Provide help.
29) Provide a way to bail out and start over.
30) Don't let people accidentally shoot themselves.
31) Color is information.
32) The user should be in a good mood when done.
33) The fault is not in thyself, but in thy system.
34) To know the system is to love it.
35) Deliver a model and stick to it.
36) Follow platform conventions.
37) Make it hard for people to make errors.
38) The system status (i.e., what's going on should always be visible.
39) Accommodate individual differences among users through automatic adaptation or user tailoring of the interface.
40) Make it easy for a beginner to become an expert.
41) No you can't just explain it in the manual.
42) Provide user documentation that is easy to search, focused on the user's task, lists concrete steps to be carried out, and is not too large.
43) The system should speak the users' language, following real-world conventions.
44) Instructions for use of a system should be visible or easily retrievable.
45) What does marketing think it wants? Ok, now how do we show them they're wrong?
46) What does management think it wants? Ok, now how do we show them they're wrong?
47) Allow users to tailor frequent actions.
48) Users don't know what they want, and users can't always say what they know.
49) Roll the videotape.
50) Common sense is an uncommon commodity.
51) Make objects, actions, and options visible.
52) Data drives good design.
53) Help users develop a conceptual representation of the structure of the system.
54) Minimize the amount of information a user must maintain in short-term memory.
55) It's a jungle. Be careful out there.
56) People should not have to remember information across a dialogue.
57) Make it impossible to make errors that will get the user into REAL trouble.
58) Dialogues should not contain information that is irrelevant or rarely needed.
59) Testing, testing, testing.
60) Keep the user mental workload within acceptable limits.
61) Minimize the amount of information recoding that is necessary.
62) Minimize the difference in dialogue both within and across interfaces.
63) An ounce of good design is worth a pound of technical support.
64) Provide the user with feedback and error-correction capabilities.
65) So how is this better than what the competition is doing?
66) Provide good error messages that are expressed in plain language, precisely indicate the probem, and constructively suggest a solution.
67) Whadya mean, they're not all computer scientists?
68) Support undo and redo.
69) Different words, situations, or actions should result in different things happening.
70) The best user interface is one the user doesn't notice.

Guidelines for good UIs:

1) Use Iterative design Involve the user in the design team
2) Give the user a mental model of the system Not just a bunch of ad-hoc features Related to consistency Visual cues can help = "affordances"
3) Good Graphic Design and Color Choice Appropriately direct attention Group related objects (alignment, decorations) Balance and white space Maintain display inertia Few fonts and colors (5 to 7 colors) appropriate contrast some people are color blind (8% of males)
4) Less is More ("keep it simple") If complex to explain/document - redesign Concise language Avoid extraneous pictures and information Fewer options and menu choices Reduces planning time Reduces manual size, etc. E.g. in XXX product: "Show Cartouche", "swap"
5) Speak the User's Language Use common words, not "techno-jargon" Error messages and feedback refer to user objects Allow full-length names E.g. "Hit any key to continue"
6) Use appropriate Mappings and Metaphors Task analysis to understand user's domain Metaphors can help or hurt
7) Minimize User Memory Load Short-term memory = 7 +/- 2 items; 30 sec to 2 min unless interrupted Recognize, not recall (generate) Menus rather than type-in (but short enough) Prompts provide format Don't require retyping of remembered information Pervasive, generic rules (cut/paste) E.g. in Aegis, remembering altitude
8) Be consistent Same command always have the same effect Locations for information, names of commands Size, location, color, wording, function, sequencing, ... Following standards helps Seems easy, but often not followed. e.g. in XXX naming "F#1.C#1" vs. "F#1", "C#1" line-style, fonts & color dialog boxes work differently for getting the current value consistent with industry standards: e.g., Copy prefix vs. postfix: "delete" vs. "moving object" Macintosh: deleting files vs. disks
9) Provide appropriate feedback About what system is doing, and how input is being interpreted. "articulory" and "semantic" Response time: 0.1 sec for articulory up to about 4 sec for an operation Percent-done progress bars E.g. in XXX product, "really ungroup?" -- loses associated behavior
10) Clearly marked Exits Cancel buttons Make all user actions easily reversible (undo) Users (even experts) will make errors E.g. in XXX product, no way to get out of editing a text field
11) Prevent errors Selection rather than entry Remove or grey-out illegal choices Confirmation
12) Good error messages Help users when they are in trouble Opportunities for users to learn about the system Clear language; no codes Be precise. Not "syntax error" Constructively help the user solve the problem?(tell why the error happened and how to fix it) Be polite and not accusing; positive wording: Not: "FATAL ERROR", etc. Blame the system, not the user "Unrecognized" vs. "illegal" command No humor or snide comments Easy error recovery E.g. in CMU CL: segvhandler: No mapping fault: 0x00e80000 E.g. in XXX product, "can't save file" -- why not? E.g., in YYY product:: "SID: Failed MAC check on message"
13) Provide Shortcuts For experienced users Command keys, macros, styles, recent files (Boomerang)
14) Minimize modes Definition: same user action has different results Make unavoidable modes visible E.g. in XXX product, fillet uses invisible mode E.g. Typing "daytime" to a mail program
15) Help the user get started with the system No more than 1 simple overview screen to get started doing real work
16) Use cognitive directness Minimize mental transformations ^C rather than ESC-F7 for "Cut"
17) Accommodate individual differences Novice and expert Handicapped users Customization

Summary

Good user interfaces don't just happen
Design of good interfaces benefits from special training and experience
High usability requires a process
- Must be considered from the beginning of the design