Web Bloopers, Part 1: Avoiding Common Design Mistakes

September 21, 2004
Presented by Jeff Johnson
This forum was arranged by Sarah Adams and Bonnie Britt
Notes were written by Dawn Adams

Our speaker for the September forum was Jeff Johnson, president and principal consultant at UI Wizards, Inc., a product usability consulting firm that offers UI design, usability reviews, usability testing, and training. He has worked in the field of human-computer interaction since 1978. After earning B.A. and Ph.D. degrees from Yale and Stanford Universities, he worked as a user-interface designer, managing engineer, usability tester, and researcher at Cromemco, Xerox, US West, Hewlett-Packard Labs, and Sun Microsystems. He has published numerous articles and book chapters on a variety of topics in human-computer interaction and the impact of technology on society. Johnson assisted in the design and evaluation of the Election Incident Reporting System, a Web-based system to report voting problems. The system was used to monitor the 2004 U.S. elections. In addition to authoring GUI Bloopers and GUI Bloopers 2.0, he wrote Web Bloopers: 60 Common Design Mistakes and How to Avoid Them (2003).

The Bay Area Editors' Forum is grateful for the time and insights from his research that he shared with us, both in September and in November 2004.

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, says Johnson, who moved from the early days of the Internet with in-house, text-based systems to graphics-heavy Web-based ones. His experience teaches 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 that‘s needed quickly and comprehensibly, there‘s always the back button that moves the reader away from your pages to somewhere else. Anyone putting up a Web site should have an answer to this question: What value will this Web site have? Johnson said there must be a business purpose, aside and apart from “Every company needs a Web site.”

“The Web has not attained commercial quality. Johnson said 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 design mistakes that cause frustration. 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: The 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:

• Be sure the organization’s name is in a prominent spot, specially if it’s self-explanatory.
• Provide a brief summary of purpose.
• Display a picture of the product or service.
• Include links that offer a site overview.

Unfinished content
“Lorem ipsum dolor . . . ” does not belong on Web sites. That text, known as Greeking in the print industry, is dummy copy. Surprisingly enough, it’s on quite a few live Web sites, says 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.&rdquo. Here are some ways to avoid this.

• Don’t go live until the pages are ready and have been proofread. (Don’t miss your own deadlines—quickly yank posted deadlines once they are in the past.)
• Keep the old site up until the new one is complete.
• Omit unfinished pages.
• Check and recheck your pages and links.

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 Bloopers: Not linking directly
Some links take users to pages where they don’t want to go. For example, at one computer book store, when you click the “Best of” link, you are taken to that store’s version of the best of all books, not just computer books. Even worse, the "donate" link on the pages of some charitable organizations takes readers to the home page of a third-party that doesn’t even reference the charity from whence the user came. Johnson recommends creating links that take readers to where they say they’ll take them. Also, stay on track by preserving the level of specificity reacched by the user. That means allowing deep links.

Form Bloopers: Intolerant data fields
There are as many ways to create bad forms as there are forms on the Web, Johnson said, 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 offers the following solutions.

• Matching field length to data length, approximately
• Accepting common formats
• Accepting your own formats
• Considering all who might use the form (Aunt Gerri might 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.

• Show and stress important data;
• Minimize repetition between items;
• Distinguish nearly every item from other hits;
• Cut noise and emphasize information;
• Minimize 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 and keeping link labels under three words.

Link Presentation Bloopers: Nonlinks that Look Like Links
Because of various factors, many companies use color schemes and conventions that make nonlinked text look like hyperlinks. Johnson advises against this because it confuses readers. Do not underline what are not links, regardless of the text color. Underline links, although it is preferable to use a strong color difference if underlining appears on mouse-over. Deemphasize nonclickable graphics

Click here: Burying links in text
“Click here” belongs on a Web site for John’s baby pictures, not on a professional’s, Johnson said. You don’t have to tell users to click links any more. Avoid this error by placing links in headings and putting a link on the most important word in a phrase.

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

• Placing the error message where users are looking;
• Placing the error message near the error;
• Using red for errors, and not for anything else;
• Using a standard error symbol.

The first chapter of Johnson’s book Web Bloopers is here.

Go to summary of Jeff Johnson's related talk: Web Bloopers, Part 2: Avoiding Common Text Errors