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.
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.
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?
- 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.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
