05-830, User Interface
Software, Spring, 1997
Lecture 3, January 20,
Copyright © 1997 - Brad
Lecture . . .
- 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
- 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 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
- 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
- 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
- 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 the system.
- 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 dialogue.
- 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 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
- 70) The best user interface is one the user doesn't notice.
- 1) Use Iterative design
- Involve the user in the design team
- 2) 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)
- 3) Less is More ("keep it simple")
- If complex to explain/document - redesign
- Concise language
- Avoid extraneous pictures and information
- Fewer option
- s and menu choices
- reduces planning time
- reduces manual size, etc.
- E.g. in XXX product,
- "Show Cartouche", "swap"
- 4) 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"
- 5) Use appropriate Mappings and Metaphors
- Task analysis to understand user's domain
- Metaphors can help or hurt
- 6) Minimize User Memory Load
- Short-term memory = 7 \xb1 2 items; 30 sec to 2 min
- 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
- 7) 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
- But not always (Grudin, CACM, Oct 89, pp. 1164-1173)
- default menu option
- "Print" applied to a folder
- 8) 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
- 9) 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
- 10) Prevent errors
- Selection rather than entry
- Remove or grey-out illegal choices
- 11) 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
- "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?
- 12) Provide Shortcuts
- For experienced users
- command keys, macros, styles, recent files (Boomerang)
- 13) 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
- 14) "Know the user"
- 15) Help the user get started with the system
- No more than 1 simple overview screen to get started doing real
- 16) 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"
- 17) Use cognitive directness
- Minimize mental transformations
- ^C rather than ESC-F7 for "Cut"
- 18) Accommodate individual differences
- Novice and expert
- Handicapped users
Back to 05-830 main page