http://www.cs.cmu.edu/~bam/uicourse/special/
Notes for HCI Talk byBrad A. Myers
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
- Various aspects of the design must be balanced
- All UI design involves tradeoffs
- Existing theories and guidelines are not sufficient
- Iterative Design is difficult
Why Are User Interfaces Hard to Implement?
- They are hard to design, requiring iterative implementation
- They are reactive and are programmed from the “inside-out”
- They generally require multi-processing
- There are real-time requirements for handling input events
- Need for robustness
- Lower testability
- Little language support.
- 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:
- 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
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?
- Is this approach a good idea?
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
- 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
- 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:
- Blame the system, not the user
- No humor or snide comments
- Easy error recovery
- E.g. in CMU CL:
- 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
- 14) Minimize modes
- 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
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
UX TIDE 
