Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
01 Aug 2001 When computers are at their most usable, we don't even notice them; when they are at their least, they astonish us. Here, Peter explores the Principle of Least Astonishment, and how it can help you develop better interfaces.
Throughout the history of engineering, one usability principle seems to me to
have risen high above all others. It's called the Principle of Least
Astonishment -- the assertion that the most usable system is the one
that least often leaves users astonished. Web pages violate this rule constantly, flagrantly, and in ways that produce a
great deal of the ill-will that Web designers sometimes face. Web pages astonish
users by hiding buttons, providing buttons that don't work, and redefining the
basic visual cues that are supposed to allow users to navigate a page. When users are astonished they usually assume that they have made
a mistake; they are unlikely to realize that the page has astonished them. They
are more likely to feel that they are at fault for not anticipating the page.
Don't take advantage of this; making users feel stupid is not endearing. Button, button, who's got the button?
Visual browsers depend heavily on the idea of the "click." From the "click here to be removed" that spammers use in HTML e-mail, to radio buttons on forms, navigating pages
is all about identifying the objects that have functions, figuring out what those
functions are, and then hitting the button as hard and as often as you can in
the hope that it'll do something. Users expect buttons to have functions. If there's a thing that looks like a
button, the user will expect it to have a discernible purpose, and expect that
clicking on that button will achieve the suggested result. Often, the user is out of luck. The most egregious example of this, by far,
is banner ads that are disguised as error messages, typically using
Windows-style window decorations, with a picture of a Windows-style button
labeled "OK." To be fair, these work in the strictest sense;
ads that use this design frequently
get huge click-through rates. However, most of these users turn right
around when they realize they've been had -- and make no mistake, they know
they've been had, and they know that the company whose ad they just saw
took advantage of them. Users resent being lied to. Sometimes the problem lies in figuring out which objects are the buttons,
and which are just pictures. One shopping cart I used had a strange icon
next to each item in my "cart." When I was done selecting items, I changed
the quantities on all 15 lines, and clicked on the icon labeled
"update quantity." Nothing happened. I hit it again. Nothing happened.
Finally, I realized that what I thought was a button labeled "update quantity" was
not a button at all -- it was a legend telling me how to use the icons found on
each line of the cart, which looked the same, but were buttons.
Furthermore, each of the actual "update quantity" buttons
updated only the quantity next to it. To update all 15 of these
quantities, I needed to modify each one separately, and then click the
mysterious icon next to it. Sometimes, the challenge is figuring out what a button does. We've all seen
pictographic representations of site maps. I don't know about the rest of
you, but I look for words and click on those. I'm not sure what the picture
of, say, a globe means on a company Web page, but I'm pretty sure I can figure
out "Contact us." Maybe the globe is an icon for "do more research on our
competitors" -- that's certainly what I end up doing. It's easy to avoid astonishing users this way. Whenever possible,
use form elements that have useful textual names as buttons. If
you must use pictures, label them. If you absolutely can't label
them, PLEASE try to find something standardized. Don't invent
an "improved" scheme; your page is not interesting enough to merit
the time it will take users to figure out what your buttons do.
Remember, you'll make it much easier for your users if you tell them outright
what a particular button does; otherwise they'll have to figure this information
out for themselves. For effective usability testing, you need people who haven't seen
your page, or been told what your icons are. Ask users what they think the buttons
will do and compare this to what it really does; don't tell them what it does and
ask them whether it makes sense.
A link in any other color
Fresh links are blue. Previously visited links are purple.
Other things are neither blue nor
purple. For some users, links are underlined; certainly, nothing that isn't
a link should ever be underlined. The above paragraph would be all anyone could ever ask from a user interface
perspective. It allows broad latitude for exploration. It permits a
certain amount of experimentation (green links that turn red when
followed, for instance), while preserving enough consistency to keep users
from having to work too hard.
Did I get you? A non-link that is underlined and blue is a painful, painful
thing. Users know that every so often a click misses somehow: Perhaps it missed the
text too much; maybe the mouse click got eaten by system gremlins. So, they click
again. They get frustrated. Even non-blue underlined text is rare enough
that it is often assumed to be a link. Likewise, blue text that isn't
underlined is often assumed to be a link by people whose browsers are set
to not underline links. Don't play games with this. Choosing link colors is like choosing a side of the
road to drive on: There may not be a truly correct answer, but it's very, very bad
if those who are involved don't agree on a single solution, whichever one it is.
Downloads vs. immediate content
Try to distinguish between links to other parts of your site and links to
files users will download. If I'm browsing around a set of HTML technical
specifications, I don't want to click on a link and suddenly see my browser starting to download a PDF. Any time a link points to content to be downloaded, rather than more
pages, try to indicate this in some way. Don't include a link that says "Download now" that doesn't do just that.
A user is likely to
read "Download now! (8375kb)," click on the link, and then go make some coffee
while waiting for the long download. If he comes back to an intermediate
page that isn't actually his download, he's just wasted a bunch of time.
The delay while a browser initiates a connection is often enough to cause
users to walk away and come back, expecting the link to have been followed
successfully. If you're including a download page of some sort, indicate it
in the link.
Local standards are not enough
It's not enough that your page is internally consistent; users will be coming
to your page from other pages, and they will go from your page to other pages.
Try to make sure that your page doesn't make radical or unusual
assumptions about the user experience; this will simply confuse users. Look
at other pages to get ideas of ways to make a page navigable; in particular,
look at pages that a broad variety of visitors find usable. Conversely,
if you see complaints about a page's usability, don't emulate it. If your local convention is bad, it doesn't matter how consistently you
follow it. Imagine a page that, through style sheets or FONT tags, uses
blue text with underline
to represent words that
users are likely to want to look up -- but doesn't actually make them links.
The site may use this convention consistently throughout, but it'll never be
friendly to the users, who will mistake the colored text for links. This doesn't mean your page shouldn't be as consistent as possible; that's
not sufficient to make a page usable, but it's certainly necessary.
Summary
Users will come to the table with expectations, and they will develop new
expectations as they use your page. Try to meet those expectations, and
try to avoid surprising them. Keep an eye out for things that could be
easily misunderstood, and keep an eye out for people who haven't seen your
page yet; their mistakes may reveal a design flaw you haven't seen yet.
This week's action item: Talk to people you know about surprising Web page
behavior. Do the stories sound familiar? Have users ever made
"mistakes" using your page that might be more the fault of the page than of
the user?
Resources - Usability expert Jakob Nielsen's useit.com site features a range of articles, columns, and other resources on usability and Web design.
- Bruce Tognazzini is a recognized leader in human/computer interaction design. His Ask Tog site allows you to send him specific questions, and includes usability news and commentary from Tog himself.
- In the most recent cranky user column, Peter takes Apple to task for making it difficult to turn off ads in the Sherlock search engine.
- Visit the IBM Ease of Use site for the latest in design guidelines, from designing for the Web to out-of-box-experience.
- Find out how IBM's Global Services Usability Engineering team can help you improve your products and make them easier to use.
About the author  | 
| | Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive. |
Rate this page
| 
