 |
Principles of
Graphic
Interface Design |
The Principles
| Clustering
| | Visibility Reflects Usefulness | | Intelligent
Consistency |
| Color As a Supplement | | Reduced Clutter |
The Reasons
Why
| Geometry and Movement | | Memory
| | Problem-Solving |
| Attention | | Convention | | Diversity |
The graphic design of an interface
involves decisions about issues such as where to put things on the screen, what size and
font if type to use, and what colors will work best. For these questions as for other,
more substantive design issues, intelligent borrowing should
be your first approach. But that often leaves you with a lot of decisions
still to be made. Here are a few principles of graphic design that will not only make your
interface more attractive, but will also
make it more usable. Each principle is
accompanied by a description of WHY it's important, so you'll be able to consider the tradeoffs when there's a conflict between two
principles or between a design principle and a borrowed technique.
 |
 |
The Principles |
Clustering
Organize the screen
into visually separate blocks of similar controls, preferably with a title for each block |
| "Controls," as we use the word here, include
menus, dialog boxes, on-screen buttons, and any other graphic element that allows the user
to interact with the computer. Modern WIMP (Windows-Icons- Menus-Pointer) systems are a
natural expression of the Clustering Principle. Similar commands should be on the same
menu, which places them in close proximity visually and gives them a single title. Large
numbers of commands related to a given area of functionality may also show up in a dialog
box, again a visually defined block. |
| But the same principle should apply if you are designing a
special control screen with many buttons or displays visible, perhaps a touch-screen
interface. The buttons for a given function should be grouped together, then visually
delineated by color, or a bounding box, or surrounding space ("white space").
The principle should also be applied within WIMP systems when you design a dialog box: If
there is a subgroup of related functions, put them together in the box. |
| There are two important reasons for the clustering
principle. First, it helps users search for the command they need. If you're looking for
the "Print setup" menu, it's easier to find if it's in a box or menu with the
label "Printer" then if it's one of hundreds of command buttons randomly
distributed on the top of the screen. Second, grouping commands together helps the user
acquire a conceptual organization for facts about the program. It's useful to know, for
example, that Bold, Italic, and Outline are all one kind of font modification, while Times
Roman, Palatino, and Courier are another kind. (That distinction, common to most PC-based
word processors, doesn't hold for many typesetting systems, where users have to acquire a
different conceptual organization.) |
Visibility Reflects Usefulness
Make frequently used
controls obvious, visible, and easy to access; conversely, hide or shrink controls
that are used less often |
This is a principle that WIMP
systems implement with dialog boxes and, in many recent systems, with "toolbars"
of icons for frequently used functions. The reasoning behind this principle is that users
can quickly search a small set of controls, and if that set contains the most frequently
used items, they'll be able to find and use those controls quickly. A more extended
search, through dialog boxes, for example, is justified for controls that are used
infrequently.
Intelligent
Consistency
Use similar screens
for similar functions |
| This is similar to intelligent borrowing, but in this case
you're borrowing from one part of your design and applying it to another part. The
reasoning should be obvious: Once users learn where the controls are on one screen (the
"Help" button, for example), they should be able to apply that knowledge to
other screens within the same system. |
| This approach lets you make a concentrated effort to
design just a few attractive, workable screens, then modify those slightly for use in
other parts of the application. |
| Be careful to use consistency in a meaningful way,
however. Screens shouldn't look alike if they actually do significantly different things.
A critical error warning in a real-time system should produce a display that's very
different from a help screen or an informational message. |
Color
As a Supplement
Don't rely on color
to carry information; use it sparingly to emphasize information provided through other
means |
| Color is much easier to misuse than to use well. Different
colors mean different things to different people, and that relationship varies greatly
from culture to culture. Red, for example, means danger in the U.S., death in Egypt, and
life in India. An additional problem is that some users can't distinguish colors: about 7
percent of all adults have some form of color vision deficiency |
| A good principle for most interfaces is to design them in
black and white, make sure they are workable, then add minimal color to the final design.
Color is certainly useful when a warning or informational message needs to stand out, but
be sure to provide additional cues to users who can't perceive the color change. |
| Unless you're an experienced graphic designer, minimal
color is also the best design principle for producing an attractive interface. Try to
stick with grays for most of the system, with a small amount of bright color in a logo or
a label field to distinguish your product. Remember that many users can -- and frequently
do -- revise the color of their windows, highlighting, and other system parameters. Build
a product that will work with that user input, not one that fights it. |
Reduced
Clutter
Don't put too much
on the screen |
| This loosely defined principle is a good checkpoint to
confirm that your design reflects the other principles listed above. If only the most
highly used controls are visible, and if controls are grouped into a small number of
visual clusters, and if you've used minimal color, then the screen should be graphically
attractive. |
| This is also a good principle to apply for issues that we
haven't dealt with specifically. Type size and font, for example: the Reduced Clutter
Principle would suggest that one or two type styles are sufficient. Don't try to
distinguish each menu by its own font, or work with a large range of sizes. Users
typically won't notice the distinction, but they will notice the clutter. |
|
|
|
The Reasons Why |
Analyzing the why's of interface features
is complicated and detailed, as the example showed. But it's possible to identify some
broad kinds of arguments that crop up often.
Geometry and Movement
 |
small targets are harder (and
slower) to hit with a mouse than big targets |
|
long mouse movements are slower
than short ones |
|
icons pack differently from text
strings |
|
more keystrokes take longer to
type |
|
switching between mouse and
keyboard is slow |
Memory
|
it is easier to recognize
something when you see it (for example on a menu) than it is to recall it
from scratch (for example in typing in a command) |
|
it is hard to remember much
information from one step in a process to another (so, for example, having help
information available at the same time as the user carries out an operation is a good
idea) |
|
information that is used together
should be presented together |
|
the interface should present key
information, such as the current mode, rather than requiring the user to remember it |
Problem-Solving
|
interface features should help the
user to select operations that are relevant to their goals, by labeling the operations in
ways that match the way the user thinks about his or her task |
|
the user needs to know what an
operation has actually done (the approach of saying nothing unless something goes
wrong is useless if you are a learner and do not already know what the commands do) |
|
users will make mistakes,
especially if they are exploring options, so give them a way to back out |
Attention
|
information presented with a big
change in the display is more likely to be read |
|
information presented close to
where the user is looking is more likely to be read |
|
auditory signals cannot be ignored
as easily as visual signals (this is a two-edged sword; sometimes you want to be
able to ignore things) |
Convention
If you do things the way your users are familiar with, they
will be happier; conventional ways of using features have stood the test of time, but any
innovation you make has not and thus may suffer from hard-to-anticipate problems.
Diversity
| Different users have different preferences for interaction
styles, and some users have physical limitations that make it difficult or impossible to
use certain features. A blind user, for example, can work with textual menus using a
device that translates on-screen text to audible speech, but graphical icons can't be
translated by the device. A person with impaired motor control may be able to type but may
not have the fine hand control needed to use the mouse, while a person with the use of
only one hand might have problems with two-key combinations and prefer the mouse and
pull-down menus. For all of these users, providing more than one access to a function may
be essential. |
| All of these statements are abstract. It can be hard to
see how or whether they apply to a given design problem without some experience in
applying them. Spend some time looking at a good interface and seeing if you can make
sense of its features in terms of these ideas. |
from Chapter 3 of
Task-Centered User Interface Design
A Practical Introduction
by Clayton Lewis and John Rieman
ftp://ftp.cs.colorado.edu/pub/cs/distribs/clewis/HCI-Design-Book/README
Copyright 1994: please see "shareware notice" at
front of text
|
|
