GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos by Jeff Johnson | NOOK Book (eBook) | Barnes & Noble
GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos

GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos

5.0 2
by Jeff Johnson

View All Available Formats & Editions

Is your application or Web site ready for prime time?

A major revision of a classic reference, GUI Bloopers 2.0 looks at user interface design bloopers from commercial software, Web sites, Web applications, and information appliances, explaining how intelligent, well-intentioned professionals make these mistakes--and how you can avoid them. While equipping you


Is your application or Web site ready for prime time?

A major revision of a classic reference, GUI Bloopers 2.0 looks at user interface design bloopers from commercial software, Web sites, Web applications, and information appliances, explaining how intelligent, well-intentioned professionals make these mistakes--and how you can avoid them. While equipping you with the minimum of theory, GUI expert Jeff Johnson presents the reality of interface design in an entertaining, anecdotal, and instructive way.

* Updated to reflect the bloopers that are common today, incorporating many comments and suggestions from first edition readers.

* Takes a learn-by-example approach that teaches how to avoid common errors.

* Covers bloopers in a wide range of categories: GUI controls, graphic design and layout, text messages, interaction strategies, Web site design -- including search, link, and navigation, responsiveness issues, and management decision-making.

* Organized and formatted so information needed is quickly found, the new edition features call-outs for the examples and informative captions to enhance quick knowledge building.

* Hundreds of illustrations: both the DOs and the DON'Ts for each topic covered, with checklists and additional bloopers on

Editorial Reviews

There are so many ways to foul up a user interface. But there's only one best way to avoid doing so: Read GUI Bloopers 2.0. The first edition was a classic. Programmers have been waiting ages for the second, but the wait's been worth it.

Jeff Johnson again begins with first principles. ("Consider function first, presentation later.... Don't distract users from their goals.... Facilitate learning...deliver information, not just for responsiveness.... Try it out on users, then fix it...") The principles are crucial; even more crucial is his guidance on actually implementing them.

Then, the "bloopers" -- and the fixes. Virtually every example here is new: those covering GUI control, navigation, text, layout, responsiveness, interaction, and more. Following its own philosophy, the book's own interface is improved. New callouts, captions, and checklists make it even more efficient and usable: You can finally retire your old, dog-eared copy. Bill Camarda, from the November 2007 Read Only

From the Publisher
“GUI Bloopers 2.0 is an extremely useful book for any software developer or interaction designer. If you have never made any of these mistakes, it’s because you have never designed a UI. If anything, these bloopers are even more common now than when version 1.0 was published, so the need for the book has only increased.” —Jakob Nielsen, Principal Nielsen Norman Group (

"This is the most entertaining design book I've read. Jeff Johnson has once again done a fabulous job of reminding us about all the silly design mistakes we can make and giving us great advice on how to avoid them in our own designs." —Jared M. Spool, Founding Principal, User Interface Engineering

“The second edition of GUI Bloopers is that true rarity: a sequel to something great that’s even better than the original. (Think Godfather II.) While Jeff could have settled for just updating the examples, as near as I can tell he’s rewritten nearly the entire book, and it shows. The organization is terrific, the insights are easier to grasp, and above all, the writing is leaner. If you ever picked it up in the past and ended up not plunking down your money, definitely take another look. It’s gone from a great book to an excellent one.“ —Steve Krug, Advanced Common Sense

Product Details

Elsevier Science
Publication date:
Interactive Technologies
Sold by:
Barnes & Noble
File size:
13 MB
This product may take a few minutes to download.

Read an Excerpt

GUI Bloopers 2.0

Common User Interface Design Don'ts and Dos
By Jeff Johnson


Copyright © 2008 Elsevier Inc.
All right reserved.

ISBN: 978-0-08-055214-9

Chapter One

First Principles


Basic Principle 1: Focus on the users and their tasks, not on the technology

Basic Principle 2: Consider function first, presentation later

Basic Principle 3: Conform to the users' view of the task

Basic Principle 4: Design for the common case

Basic Principle 5: Don't complicate the users' task

Basic Principle 6: Facilitate learning

Basic Principle 7: Deliver information, not just data

Basic Principle 8: Design for responsiveness

Basic Principle 9: Try it out on users, then fix it!


This book describes common user-interface bloopers found in software-based products and services and provides design rules and guidelines for avoiding each one. First, though, it is useful to lay the foundation for the discussion of bloopers by describing the basic principles for designing effective, usable user interfaces.

The nine basic principles in this chapter are not specific rules for designing graphical user interfaces (GUIs). This chapter does not explain how to design dialog boxes, menus, toolbars, Web links, etc. That comes later in this book, in the rules for avoiding bloopers.

The nine basic principles represent the cumulative wisdom of many people, compiled over several decades of experience in designing interactive systems for people. The principles are also based on a century of research on human learning, cognition, reading, and perception [Card et al., 1983; Norman and Draper, 1986; Rudisill et al., 1996]. Later chapters of this book refer to these basic principles to explain why certain designs or development practices are bloopers and why the recommended remedies are better.

More comprehensive explanations of UI design principles are presented in several books, e.g., Smith and Mosier [1986], Cooper, Reimann, and Cronin [2007], Isaacs and Walendowski [2001], Raskin [2000], Shneiderman and Plaisant [2004], and Tidwell [2005].

Basic Principle 1: Focus on the users and their tasks, not on the technology

This is Principle Numero Uno, the Main Principle, the mother of all principles, the principle from which all other user interface design principles are derived:

Focus on the users and their tasks, not on the technology.

Now that you've read it, we're done, right? You now know how to design all your future software, and nothing more needs to be said.

I wish! Alas, many others have stated this principle before me, and it doesn't seem to have done much good. And no wonder: it is too vague, too open to interpretation, too difficult to follow, and too easily ignored when schedules and resources become tight. Therefore, more detailed principles, design rules, and examples of bloopers are required, as well as suggestions for how to focus on users, their tasks, and their data.

What does "focus on users and their tasks" mean? It means starting a software development project by answering several questions:

* For whom is this software being designed? Who are the intended users? Who are the intended customers (not necessarily the users)?

* What is the software for? What activity is it intended to support? What problems will it help users solve? What value will it provide?

* What problems do the intended users have now? What do they like and dislike about the way they work now?

* What are the skills and knowledge of the intended users? Are they motivated to learn? How? Are there different classes of users, with different skills, knowledge, and motivation?

* How do users conceptualize the data that the software will manage?

* What are the intended users' preferred ways of working? How will the software fit into those ways? How will it change them?

It would be nice if the answers to these questions would fall out of the sky into developers' laps at the start of each project. But, of course, they won't. The only way to answer these questions is for the development team to make an explicit, serious effort to do so. That takes time and costs money, but it is crucial, because the cost of not answering these questions before starting to design and develop software is much, much higher.

Understand the users

Several of the questions listed above are about the intended users of the software: Who are they? What do they like and dislike? What are their skills, knowledge, vocabulary, and motivation? Will they be the ones who make the decision to buy the software, or will someone else do that? These questions are best answered using a process that is part business decision, part empirical investigation, and part collaboration.

Decide who the intended users are

Early in development, you need to decide who you are developing the software for. It is tempting to say "everyone": most developers want the broadest possible market. Resist that temptation! Software designed for everyone is likely to satisfy no one. Choose a specific primary target population as the intended user base in order to focus your design and development efforts, even if you believe that the software will also have other types of users.

In reaching this important decision, confirm that your target user base is aligned with your organization's strategic goals. Seek input from the marketing and sales departments, because it is they who are usually responsible for identifying and categorizing customers. However, remember that Marketing and Sales focus on customers of the product or service, whereas you need to understand the users. A product's customers and its users are not necessarily the same people, or even the same type of people, so Marketing and Sales' ideas about who the product is aimed at may have to be filtered or augmented in order to be useful to you.

Investigate characteristics of the intended users

Understanding the users also requires investigation. This means making an effort to learn the relevant characteristics of potential users. Surveying potential users helps you find specific populations whose requirements and demographics make them an attractive target market. After identifying a primary target user population, learn as much as possible about that population.

How do you gather information about the intended users? By talking with them, inviting them to participate in focus groups, observing them in their "natural" environment, talking to their managers, or reading about their business.

Users: Not Just novice vs. experienced

Software developers often think of their intended users as varying on a continuum from computer "novice" to "expert." People who have never used a computer are on the novice end; professional computer engineers are on the expert end. With that assumption, figuring out who the users are for a particular application is largely a matter of determining where they fall on the continuum.

However, the continuum is wrong. No such continuum exists. A more realistic and useful view is that the intended users can be placed along three independent knowledge dimensions:

* General computer savvy: how much they know about computers in general

* Task knowledge: how facile they are at performing the target task, e.g., accounting

* Knowledge of the system: how well they know the specific software product, or ones like it

Knowledge in one of these dimensions does not imply knowledge in another. People can be high or low on any of these dimensions, independently. This explains situations such as the following:

* A long-time C++ programmer doesn't know how to program his DVR.

* An experienced Linux system administrator struggles with Microsoft Word, while an office secretary who has never even heard of Linux handles Word with ease.

* Computer novices and experts alike get lost in an online travel agency's Web site.

* A programmer with no accounting experience has trouble learning to use an accounting package, while an experienced accountant with no programming experience learns it easily.

When creating user profiles, position the target user types along each of the three dimensions, rather than on a single novice-to-expert scale. The users' motivation is also a factor: why would they learn and use the software? Is it a job requirement, or is the software for home use, used at the customer's discretion? Are there alternatives?

Collaborate with the intended users to learn about them

Finally, understanding the users is best accomplished by working with them as collaborators. Don't treat users only as objects to be studied. Bring some of them onto your team. Treat them as experts, albeit a different kind of expert than the developers. They understand their job, experience, management structure, likes and dislikes, and motivation. They probably don't understand programming and user interface design, but that's OK—others on your team do. A useful slogan to keep in mind when designing software is:

Software should be designed neither for users nor by them, but rather with them.

Bringing it all together

The goal of this three-part process—decision, investigation, and collaboration—is to produce profiles that describe the primary intended users of the software. The profile should include information such as job description, job seniority, education, salary, hourly versus salaried, how their performance is rated, age, computer skill level, and relevant physical or social characteristics. With such a profile in hand, developers know what they are aiming at. Without it, they are, as Bickford [1997] says: "target shooting in a darkened room."

Some designers go beyond constructing profiles for the intended users of an application. Cooper [1999] advocates making user profiles concrete by elaborating them into fleshed-out personas: characters with names, vocations, backgrounds, families, hobbies, skills, lifestyles, and realistic complexities. This is similar to the practice among novelists and scriptwriters of writing "backstories" for every significant character in a book, movie, or play. A character's backstory helps ground decisions about what that character would and would not do. Similarly, the personas in Cooper's design methodology help ground judgments about the designs a particular user type would find easy, difficult, annoying, fun, useful, useless, etc. Because most products have more than one type of user, it helps to develop and use a range of personas covering the most important user types.

The trick is to build profiles and personas from real data obtained from prospective users. User profiles and personas based on pure armchair speculation would not help inform design decisions and so would add no value.

Understand the tasks

As with understanding your users, understanding your users' tasks should be a three-part process: part business decision, part empirical investigation, and part collaboration.

Decide what set of tasks to support

Understanding the intended tasks is partly a business decision because no organization is completely open-minded about what applications to develop. No organization is going to pick a group of potential customers purely at random, figure out what they need, and design a product to fill that need. Instead, decisions about what to offer are strongly influenced—one might even say "predetermined"—by:

* the organization's strategic goals, reflecting the interests of its founders, top management, and shareholders;

* the expertise of its employees;

* its past history;

* its assets, processes, and infrastructure;

* its perception of market opportunities and niches;

* new technologies developed by researchers.

The last bullet above, "new technologies developed by researchers," is especially important. In the computer and software industries, decisions about what products or services to bring to market are often more influenced by technological "push" than by "pull" from the marketplace [Johnson, 1996a]. Whether this is good or bad is a subject of debate. Norman [1998] argues that it is often good for emerging markets, but usually bad for mature ones.


Excerpted from GUI Bloopers 2.0 by Jeff Johnson Copyright © 2008 by Elsevier Inc. . Excerpted by permission of MORGAN KAUFMANN PUBLISHERS. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Meet the Author

Jeff Johnson is president and principal consultant at UI Wizards, Inc., a product usability consulting firm (www.uiwizards.). He has worked in the field of Human-Computer Interaction since 1978, as a software designer and implementer, usability tester, manager, researcher at several computer and telecommunications companies, and as a consultant. In the course of his career, he has written many articles, co-written several books, and given numerous presentations on a variety of topics in Human-Computer Interaction. His books Designing with the Mind in Mind and GUI Bloopers are seminal guides to improving design.

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >