05-830, User Interface Software, Spring, 2001
Lecture 3, January 22, 2001
Copyright © 2001 - Brad Myers
Previous Lecture
. . .
Next 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 ("forgiving")
-
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 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 thy 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.
-
Use Iterative design
-
Involve the user in the design team
-
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"
-
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)
-
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"
-
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"
-
Use appropriate Mappings and Metaphors
-
Task analysis to understand user's domain
-
Metaphors can help or hurt
-
Minimize User Memory Load
-
Short-term memory = 7 +/- 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
-
(see comic)
-
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
-
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
-
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
-
Prevent errors
-
Selection rather than entry
-
Remove or grey-out illegal choices
-
Confirmation
-
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?
-
E.g. in YYY product, "SID: Failed MAC check on message"
-
Provide Shortcuts
-
For experienced users
-
Command keys, macros, styles, recent files (Boomerang)
-
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
-
Help the user get started with the system
-
No more than 1 simple overview screen to get started doing real work
-
Use cognitive directness
-
Minimize mental transformations
-
^C rather than ESC-F7 for "Copy"
-
Accommodate individual differences
-
Novice and expert
-
Handicapped users
-
Customization
Back to 05-830 main page