BAEF :: Forum Index: Web Bloopers: Avoiding Common Design Mistakes

September 21, 2004
Presented by Jeff Johnson
Organized by Sarah Adams and Bonnie Britt
Notes by Dawn Adams

Not Ready for Prime Time—Web Bloopers and Usability

Build it and they will come. That's the kind of attitude that makes for sloppy interface design, according to Jeff Johnson, usability consultant and author of two books, GUI Bloopers and Web Bloopers. Johnson, of UI Wizards, Inc. and a graduate of Yale and Stanford, has been designing and consulting on user interfaces for over 25 years, and the move from in-house text-based systems to graphics-heavy Web-based ones has not changed the fact that a pretty design does not mean that it's user-friendly.

"Most people act like Web design is graphic design," Johnson said. "Companies expect for me to say, make this blue, move these buttons, not to say, 'You need a new database.'"

Truth is, no one has to use your particular Web site. If it doesn't give the customer the information he or she needs quickly and comprehensibly, there's always the back button. According to Johnson, one of the fundamental issues that all companies should consider before putting up a Web site at all is, what value will the Web site have? There must be a business purpose, aside and apart from "Every company needs a Web site."

"The Web is not ready for prime time," Johnson said. "The bottom line is that the Web has not attained commercial quality. People accept defects in Web sites because they think, 'I'm really stupid. Why can't I figure this out?'"

Johnson advocates the Aunt Geraldine litmus test: Would his Aunt Gerri be able to use a particular Web site? Web sites need to be designed with the users in mind—and for many consumer sites, that means someone who doesn't speak Geek.

Johnson's book, Web Bloopers, is a compilation of the 60 most common Web site design mistakes that make using Web sites frustrating. The master checklist (along with some bloopers that didn't make it into the book, discussion areas, and other information) is available at web-bloopers.com. During his talk, Johnson highlighted some of the most common Web bloopers, giving examples from live Web sites. He noted, however, that no Web site can avoid every blooper.

"There are trade-offs in design," he said. "You have to know which blooper is going to cost you the most. So much Web design is unconscious that people don't know which mistakes they're making, or what those are costing."

Content Bloopers

Homepage identity crisis
Ever gone to a Web site and had no idea what the company did? That's homepage identity crisis. Using the example of PriceWaterhouseCoopers, Johnson noted that no where on their home page do they explain what "professional" services they offer. (As Johnson says, that could be anything from lawyers to workers in the red light district.) To avoid this error, Johnson suggests:

placing the organization's name prominently (especially if it's self-explanatory)
providing a brief summary of purpose (tag line)
displaying a picture showing the product or service
having links that provide an overview of the site

Unfinished content
"Lorem ipsum dolor . . . " does not belong on Web sites. That text, known as Greeking from the print industry, is dummy copy. Surprisingly enough, it's on quite a few live Web sites, according to Johnson, who used SIwafer.com and the Stanford conferences page as examples.

"Sometimes you get the 'Zen' experience on a Web site," Johnson said. "The void—pages with nothing. You should always be working on your site, but don't put pages up until they're finished." Ways to avoid this include:

not going live until the site is ready (Johnson recommends not missing your own deadlines—yanking posted deadlines down quickly once they're past)
keeping the old site up until the new one is complete
omitting unfinished pages
checking and rechecking the site

Task Support Bloopers

Requiring unneeded data
Forms on the Web can be frustrating to fill out, even for experienced Web users. For example, if you want to write your representative, House.gov requires that you provide both your state and zip code. Why? As Johnson notes, the zip codes are state-specific, so why is it necessary to provide both pieces of information? A form on Agilent.com has only required fields, even Address 2 and Fax. If you don't have a second address line you have to make one up to proceed.

"Software developers are used to having a captive audience, and they haven't woken up to the fact that they don't have one anymore," Johnson said. "You don't want drop-off on your site by asking for information you don't need and that people don't want to give." He suggests:

asking for the minimum data possible, sticking to the current transaction (if you can proceed without it, it isn't required)
not requiring data some users won't have
deducing all you can from the data you have (e.g., not asking for birthdate and age)

Clueless back-end
Using the example of traveling by air from SFO to Ann Arbor, Johnson notes that some databases with Web front-ends are not designed to support the user tasks (e.g., not recognizing that Detroit is the nearest airport). The end result is that customers end up calling in, the very thing that having information on the Web is supposed to avoid. The best way to rectify this situation is to design the back-end so that it provides the correct information to the user.

Navigation Blooper

Not linking directly
Some Web site links take users other than where they want to go. For example, on the B&N Computer books page, if you click on the Best of link, it takes you to the Best of all books, not just computer books. Even worse, for some charitable organizations, the donate link takes you to the home page of a third-party that doesn't even reference the charity from whence the user came. Johnson recommends:

making links fulfill their promise by taking users to their goal
staying on track with the goal, and preserving the level of specificity that the user had reached (i.e., allowing deep links)

Form Blooper

Intolerant data fields
There are as many ways to have a bad form as there are forms on the Web, according to Johnson. And intolerant data fields run rampant. For example, on the United Airlines Web site, if you type in your frequent flier number the way it appears on the card (with spaces), the number will be rejected, because spaces are information. Johnson gives these solutions:

matching the field length to the data length, approximately
accepting common formats
accepting your own formats
considering all who might use the form (Aunt Gerri may be your customer)
making case irrelevant
providing a pattern (e.g., mm/dd/yyyy)

Search Blooper

Hits look alike
Don't provide boilerplate text in every search result a la Digiguide.com or SiliconValley.com, Johnson said. Search engines should accomplish the following:

showing and stressing important data
minimizing repetition between items
distinguishing most of every item from other hits
cutting noise and emphasizing information
minimizing the need to click to see if a hit is relevant

Text and Writing Blooper

Too much text
Johnson will cover this topic more fully in the November forum, but for the September session, he focused on the Jeep Find a Dealer page, which forced the user to read through a paragraph of information when just a few punchy sentences would have sufficed. Web users don't read, they scan; thus Johnson suggests:

avoiding long prose passages
keeping link labels under three words

Link presentation bloopers

Nonlinks look like links
Because of various factors, many companies will use color schemes and conventions that make nonlinked text look like hyperlinks. Johnson advises against this because it confuses the users. He suggests:

not underlining nonlinks, regardless of the text color
underlining links, although you could use a strong color difference if underlining appears on mouse-over
deemphasizing nonclickable graphics

Click here: Burying links in text
"Click here" belongs on John's baby pictures Web site, not on a professional's, Johnson said. You don't have to tell users to click links anymore. Avoid this error by:

putting links in headings
putting a link on the most important word in a phrase

Graphic and Layout Blooper

Unobtrusive error messages
On the Citibank Web site, one error message appears in the status line, a place that most people rarely look, according to Johnson. Error messages also need to be descriptive and state clearly what the error is. Johnson suggests:

putting the error message where users are looking
putting the error message near the error
using red for errors, not for anything else
using a standard error symbol