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

October 28, 1999

Copyright © 1998, 1999 - Brad A. Myers

These notes are stored on:

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.


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

Why Are User Interfaces Important?

Percent devoted to the UI:

Why Are User Interfaces Hard to Design?

Why Are User Interfaces Hard to Implement?

Usability Engineering Design Process

Usability Engineering:

Iterative Design Process

  1. Study the users and their tasks
  2. Study the competition
  3. Participatory Design
  4. Coordinating the Total Interface for Consistency
  5. Set usability goals
  6. Guidelines and Heuristic Evaluation
  7. Make a Prototype or partial implementation of the system early and quickly
  8. Empirical testing
  9. Iterative design
  10. Implementation Phase
  11. Collect feedback from field use.

Know the User

Task analysis

Functional analysis

Competitive Analysis

Participatory Design

Goal Setting

Financial impact analysis

Iterative design:

Collect feedback from field use


Uses of Prototypes:

Types of Prototypes:

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)

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
2) Give the user a mental model of the system
3) Good Graphic Design and Color Choice
4) Less is More ("keep it simple")
5) Speak the User's Language
6) Use appropriate Mappings and Metaphors
7) Minimize User Memory Load
8) Be consistent
9) Provide appropriate feedback
10) Clearly marked Exits
11) Prevent errors
12) Good error messages
13) Provide Shortcuts
14) Minimize modes
15) Help the user get started with the system
16) Use cognitive directness
17) Accommodate individual differences