Overview of HCI Design and
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
FAX: (412) 268-1266
October 28, 1999
Copyright © 1998, 1999 - Brad A. Myers
These notes are stored on:
Lecture notes for my course: User Interface Software,
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.
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
- 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: email@example.com
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
- 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
- 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
- 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
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
- User Interface design is a creative
- 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,
- Need for prototyping and iteration
- Can't "unlearn" something.
- After you know what is there, it
is hard to remember how "not" to see
- 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)
- 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
- 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
- Not the waterfall model: specify, design, implement, test,
- 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
- 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
- Lower testability
- No tools for regression testing
- Little language support.
- Primitives in computer languages make bad user
- Enormous, complex libraries
- Features like object-oriented, constraints,
- Complexity of the tools
- Full bookshelf for Microsoft MFC and friends
- Difficulty of Modularization
Usability Engineering Design Process
- 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
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?)
- 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
- Includes what needs to be on the screen.
- Both: What does the system need to show? What does the user need to
- 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
- 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
- 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
tasks => Inefficient for every task!
- Results of task analysis:
- Scenarios to be used during design
- List of the things users want to accomplish (goals)
- Information they will need to accomplish those goals
- Steps to be performed and interdependencies
- All the various outcomes and reports
- Criteria to determine quality of results
- Communication needs of users with other people
- 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
- "Know the competition"
- For usability and function
- Read trade-press reviews of products in that category
- Importance of various features, issues
- 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
- 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
- Users will have a high satisfaction with the system as measured by a
- 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
- Efficiency: (Expert) Time to execute benchmark (typical) tasks.
- 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,
- Tells how much time to spend on usability
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
- 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.
- 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 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
- Less Level of functionality = horizontal
- Designer "plays computer"
- Also called "Low fidelity" prototypes
- "Wizard of Oz"
- Subject at a computer, but person is at another computer operating
- "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
- Interface Builders and other tools for "Real" code
User Interface Guidelines
Attributes of good UIs:
- 1) Invisible
- 2) Minimal training requirements (easy to
- 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
- 8) It is flexible
- 9) It is intelligent
- 10) People like it (subjectively pleasing)
- 11) ... and many others
(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
- 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
- 4) The user should control the system. The system shouldn't control the
user. The user is the boss, and the system should show
- 5) The idea is to empower the user, not speed up the
- 6) Don't overload the user's buffers.
- 7) Keep it simple.
- 8) Things that look the same should act the
- 9) The user should be able to do what the user wants to
- 10) Every action should have a reaction.
- 11) Everything in its place, and a place for
- 12) Let people shape the system to themselves, and paint it with their
- 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
- 16) The more you do something, the easier it should be to
- 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
- 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
- 25) Eliminate unnecessary decisions, and illuminate the
- 26) You should always know how to find out what to do
- 27) If I made an error, let me know about it before I get into REAL
- 28) Even experts are novices at some point. Provide
- 29) Provide a way to bail out and start over.
- 30) Don't let people accidentally shoot
- 31) Color is information.
- 32) The user should be in a good mood when
- 33) The fault is not in thyself, but in thy
- 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
- 39) Accommodate individual differences among users through automatic
or user tailoring of the interface.
- 40) Make it easy for a beginner to become an
- 41) No you can't just explain it in the manual.
- 42) Provide user documentation that is easy to search, focused on the
task, lists concrete steps to be carried out, and is not too
- 43) The system should speak the users' language, following real-world
- 44) Instructions for use of a system should be visible or easily
- 45) What does marketing think it wants? Ok, now how do we show them they're
- 46) What does management think it wants? Ok, now how do we show them
- 47) Allow users to tailor frequent actions.
- 48) Users don't know what they want, and users can't always say what
- 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
- 54) Minimize the amount of information a user must maintain in short-term
- 55) It's a jungle. Be careful out there.
- 56) People should not have to remember information across a
- 57) Make it impossible to make errors that will get the user into REAL
- 58) Dialogues should not contain information that is irrelevant or rarely
- 59) Testing, testing, testing.
- 60) Keep the user mental workload within acceptable
- 61) Minimize the amount of information recoding that is
- 62) Minimize the difference in dialogue both within and across
- 63) An ounce of good design is worth a pound of technical
- 64) Provide the user with feedback and error-correction
- 65) So how is this better than what the competition is
- 66) Provide good error messages that are expressed in plain language,
indicate the probem, and constructively suggest a
- 67) Whadya mean, they're not all computer
- 68) Support undo and redo.
- 69) Different words, situations, or actions should result in different
- 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
- 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
- Recognize, not recall (generate)
- Menus rather than type-in (but short enough)
- Prompts provide format
- Don't require retyping of remembered
- 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
- Macintosh: deleting files vs. disks
- 9) Provide appropriate feedback
- About what system is doing, and how input is being interpreted.
- 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
- 12) Good error messages
- Help users when they are in trouble
- Opportunities for users to learn about the
- 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:
- 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
- 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
- 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
- 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