GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers

Many of the bloopers described in this book are illustrated using brief anecdotes from my professional experience. One might call these "war stories." In addition to those brief war stories, which mainly pertain to specific design or management issues, I thought it would be useful to describe a few of the consulting experiences I have had in greater detail, that is, tell some war stories in their full glory. That is the purpose of this chapter. Each war story in this chapter touches on many different issues discussed elsewhere in this book.
The fact that an engineer, organization, or company commits some of the bloopers described in this book does not mean that the engineer, organization, or company is bad. As Gentner and Grudin [1990] and Grudin [1991] point out, software product development involves balancing competing interests and goals, and making trade-offs on many issues. In fact, in some of the situations described below, I committed bloopers. I admit it. Sometimes designers are forced into corners. Sometimes one must choose between the lesser of two bloopers.
The first war story, about my experience redesigning the user interface of a computer game, is adapted from a previously published article [Johnson, 1998]. Since that article was written with the approval of the client and identifies the client, there is no reason not to identify the client in this adaptation of the article. In the second war story, about designing the user interface for a television set-top box, the name of the...