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

Chapter 1: First Principles

Introduction

The main purpose of this book is to describe user interface bloopers that are often made by developers of computer-based products and services, and to provide design rules and guidelines for avoiding each blooper. First, however, it is useful to ground the discussion of the bloopers by laying out the principles that underlie the design of effective, user-friendly user interfaces. That is the purpose of this chapter.

The principles given in this chapter are not specific design rules for graphical user interfaces (GUIs). There is nothing in this chapter about the right or wrong way to design dialog boxes, menus, toolbars, Web links, and so on. Specific design rules about such issues are provided in later chapters of the book, in the design rules for avoiding each blooper.

Specific user interface design rules are also given in "official" style guides for specific industry-standard GUI platforms, such as the Java Look and Feel Design Guildelines [Sun, 1999], the Windows Interface Guidelines for Software Design [Microsoft, 1995], the OSF/Motif Style Guide: Rev 1.2 [OSF, 1993], and the Macintosh Human Interface Guidelines [Apple, 1993]. Specific GUI guidelines are also provided by many "unofficial" but nonetheless good books, such as Bickford [1997], Fowler [1998], Mandel [1997], McFarland and Dayton [1995], Mullet and Sano [1995], Nielsen [1999d], Shneiderman [1987], Tufte [1983], Weinshenk et al. [1997]. Rather than providing specific GUI design rules, the principles given in this chapter provide the basis for GUI design rules. They are based on the cumulative wisdom of many people, compiled over several decades of experience in designing interactive systems for people. They are also based on a century of research on human learning, cognition, reading, and perception. Later chapters of this book refer to these principles as rationale for why certain designs or development practices are bloopers, and why the recommended remedies are improvements.

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 the technology.

Now that I've stated it, and you've read it, we're done, right? You now know how to design all your future products and services, and I needn't say anything more.

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. Not to mention that this would be a very thin book if I stopped here. Before proceeding to those more detailed principles, design rules, and bloopers, I'll devote a few pages to explaining what I mean by "focus on the users and their tasks."

Focusing on users and their tasks means starting a development project by answering the following questions:

• For whom is this product or service being designed? Who are the intended customers? Who are the intended users? Are the customers and the users the same people?'
• What is the product or service 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?
• How do users conceptualize and work with the data in their task domain?
• What are the intended users' preferred ways of working? How will the product or service 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 beginning of each project. But, of course, they won't. The only way to answer these questions is for the development organization to make an explicit, serious effort to do so. Making a serious effort to answer these questions takes time and costs money. But it is crucial, because the cost of not answering these questions before beginning to design is much, much higher.

1.1 Understand the users

Several of the questions listed above that developers should answer before starting to design are questions about the intended users of the product: Who are they? What do they like and dislike? What are their skills, knowledge, vocabulary, and motivation? Are they going to be the ones who make the decision to buy the software, or will someone else do that? These questions are best

7. Hint: The customer is the person who makes the buying decisions, while the user is the person who . . . well . . . uses the software. These different roles may imply different criteria and needs.

answered using a process that is part business decision, part empirical investigation, and part collaboration.

Decide who the intended users are

To a certain extent, the development organization needs to decide who it is developing the product or service for. It is tempting to decide that the intended user base is "everyone"; most development organizations want the broadest possible market. However, that temptation must be strongly resisted: a product or service designed for everyone is likely to satisfy no one. Developers should choose a specific primary target population as the intended user base in order to focus their design and development efforts, even if they suspect that the software might also have other types of users.

In reaching this important decision, the designers should seek input from other parts of the organization in order to assure that the target user base of the product or service is in line with strategic goals. In particular, developers should seek input from the Marketing and Sales departments because it is they who are usually responsible for identifying and categorizing customers. However, it is important to keep in mind that Marketing and Sales focus-as their job responsibilities dictate-on future customers of the product or service, whereas the designers need to understand the future 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 designers.

Investigate characteristics of the intended users

As described above, understanding the users also requires empirical investigation. Empirical investigation means making an effort to learn the relevant characteristics of potential users. This investigation, first of all, provides information to guide the above-described decision: going out and surveying potential users helps developers discover specific populations of users whose requirements and demographics make them attractive as a target user base...