Read an Excerpt
GUI Bloopers 2.0
Common User Interface Design Don'ts and Dos
By Jeff Johnson
MORGAN KAUFMANN PUBLISHERS
Copyright © 2008 Elsevier Inc.
All right reserved. ISBN: 978-0-08-055214-9
Chapter One
First Principles
Introduction
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!
Introduction
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.
(Continues...)
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.
