ACM Interactions

Authors:
Joshua Seiden

---

  Design is Simple

The essence of the designer's process is simple: first you figure out the problem, then you figure out the solution. As simple as this is to state, it's correspondingly difficult to execute.

The vexing part is not what you might expect—figuring out the right problem. There are lots of systems and methods for this, and many of them are straightforward and effective. In the worst-case scenario, you get everyone in a room and you agree on the problem—and you're done. You've figured out the problem. Now you can go about figuring out the solution.

Go ahead.

  The Gap

Getting to the solution is the vexing part. The problem faced by designers here is sometimes called "the gap" [Wood, et al., 1997]. Getting across the gap is a creative endeavor. Designers need to transform problems into solutions, questions into answers. If you've used a good method to define the problem, you will have an advantage: The size of the gap between problem and solution will be smaller. Still, though, there will be a gap. How do you cross it? And why is it so hard to cross successfully?

Too often, it's because we lose sight of the problem—and the smaller questions that form it—as we pursue the solution. When we do that, it's easy to get lost.

  Bridge the Gap with Questions

When we look for answers, it's only natural that the first ones we discover are the standard ones. We are sorely tempted to accept them. After all, when we do, we can move on to the next question. But we do so at a price.

Say you are working on a user interface for entry of addresses. There is a standard way to do this: present the user with a dozen neatly labeled fields in which to type First Name, Middle Initial, Last Name, Company Name, and so on.

This is the standard answer, and also the wrong answer. Users do not want to type in a million tiny little fields, and they do not want to learn to press Tab after each component of their names. What they want to do is enter their addresses in a simple, natural manner.

Ask yourself, then, what is a simple, natural manner in which to enter addresses? You might come up with some simple answers. What if I got rid of all the tiny little fields and replaced them with one big field? That would be better, wouldn't it? But when would it work, and when wouldn't it? Why do we do it the old way?

You might even come up with this: Wouldn't it be better if our personal computers stored our personal information, and could release it when instructed to do so? (If you were an operating system company, you might be very interested in this line of thinking, although as of this writing, none seem to be.)

By paying attention to the problem, and by asking a simple question, you've quickly generated two possible alternative solutions. Neither is perfect—few ideas are, at first—and both require further thinking and effort. But both hold the possibility of solving the problem in a better way. And isn't that what you are trying to do in the first place?

  Attitude Will Help Bridge the Gap

As designers, we must exercise judgment about how well our solutions answer the questions we ask. To do that, we need first to pay attention to our own questions. When we accept the standard answer without question, we effectively give up our own judgment.

There's just one teeny-tiny problem: Everyone and everything will encourage you to accept the standard answer. Certainly some of the most well respected voices in our business tell you to do so. Jakob Nielsen advises us to obey standards precisely because they are standard. "If 90% or more of the big sites do things in a single way, then this is the de-facto standard and you have to comply" [Nielsen 1999]. Even Alan Cooper, who rails against the status quo with all the considerable force at his disposal, tells us to "obey standards unless you've got a darn good reason" (Cooper 1995, p. 500).

Don't do it! Your job as a designer is to recognize that you do not have to comply with the de facto standard. Your job is to look for that darn good reason not to.

  Why the Standard Answer is Not a Good Answer

In the world of user-interface design, things rarely become standards for the right reasons. Interaction idioms become standard because it's easier for designers to reuse existing ones than it is to rethink the problem and come up with a new solution. Controls become standards because it's easier for developers to use an existing control from a code library than it is to create a new control from scratch. These are valid reasons from the implementer's point of view, certainly, but not user-centered reasons.

As a designer in a user-centered context, your role is to advocate for the user. You cannot do this and simultaneously give up your thoughtful engagement with the problem you are solving.

If you accept the standard answer, you do just that.

  Engage Your Judgment by Asking Yourself Questions; Demand Good Answers

The good news is that, if you pay attention, you will come to see that the standard answer is your unsuspected ally, because it presents you with the opportunity to ask another question. If you seize this opportunity, and if you ask the right questions, you will find yourself designing better solutions, and you will have more confidence in your answers.

  Seven Opportunities To Do Better

Here then, is a list of some unsuspected allies, all of which are interaction idioms. When you come across these allies, you must stop; you must interrogate; you must be merciless. You must ask, "Will you mess up this design? Will you cause heartache to my users? Is there a better answer?"

 1. Pop-up windows

When you open a pop-up window, you are taking your user out of the context of work, and asking that he refocus attention on a new piece of your user interface. You are also asking him to manage a new piece of user interface, moving it around so that it does not obscure what is below it, closing it when finished.

Whenever you open a pop-up window, ask yourself "Is this OK? Am I right to make the user shift context? Is it OK to add overhead here? Or am I popping up this window because it's easier than designing a solution that keeps the user in the flat plane of the current window?"

Ask yourself "Is the task in the pop-up window really tangential to what the user is working on in the original window?" If it is, then pop up, by all means. But, as a rule, a related task belongs in the same windows as the original.

 2. Hierarchies

Whenever you see a deep hierarchy, you are looking at a structure that is easy to create with computers. You are also looking at a structure that is not often found in users' mental models. And if you stop and make yourself aware of that, you are seeing an opportunity to do better.

Ask yourself "Is this information really hierarchical?"

If you have an org chart, you have hierarchical data, and you should represent it that way. Similarly if you have a family tree. But if you have a bunch of files in storage, what are you looking at? The information is not hierarchical, but the storage mechanism might be. Now you need to ask some more questions.

Ask "Am I doing the user a service by representing the structure of the storage mechanism?" I'll answer that one for you: No, you're not. Then ask: "What is a better way to visualize this information?" I'll answer that one, too: Represent it in terms of how the user thinks of his or her work.

 3. Breadcrumbs

Why are breadcrumbs good? You know what I'm talking about: that little set of links> at the top> of the Web page. These help users navigate sites that have deeply hierarchical site structures.

What's wrong with them? Well, there's nothing inherently wrong with navigational aids, except for this: They tell you, the designer, that you have created a site in which the user needs navigational aids!

What Don Norman said about labels holds true for breadcrumbs: "Wherever [they] seem necessary, consider another design" [Norman 1988, p. 78].

When you find yourself using breadcrumbs, it's time to ask yourself, "What's wrong with this site structure that I need so much navigational support?" And, "How can I simplify the information architecture so that I don't need to give the user crutches?"

 4. Error messages

Every error message is an admission of failure. You should never design one. Never.

Not, at least, until you have struggled to avoid it by asking these questions: "What can I do to prevent this error message from ever appearing?" And "If we know enough to detect an error condition, don't we know enough to fix it before it occurs?"

---

Every error message is an admission of failure. You should never design one. Never.

---

 5. Save buttons

Work from this assumption: The likelihood that the users wants to preserve their work is 10,000 times greater than the likelihood that they will want to discard it. This means that you have an obligation: Treat users' work as valuable to them. The standard way we do this is to allow users to save their work. This standard answer is wrong. This answer forces users to specify over and over again, "My work is valuable to me. Please save it." When you find yourself designing a Save button, ask yourself: "Shouldn't we just save this for them? How can I structure the save operations so that they are reliable and yet transparent to the user?"

 6. Confirmation messages

Confirmation dialogs are typically used when the user is about to do something dangerous, irreversible, or unwise. But they are annoying at best. At worst, they are ineffective and annoying.

So ask yourself "Is this operation inherently dangerous, irreversible, or unwise?" The answer is usually no. File deletion is the classic example: Rather than spend your time on confirmations, spend your time making the operation reversible: incorporate an Undo function into your design.

Now, perhaps your system really does control an irreversible process. Perhaps your application delivers lethal injection. In that case, ask yourself: "Don't I want something more effective here than a confirmation dialog?"

 7. Required fields

Like error messages and breadcrumbs, required fields are an indicator that a better design may be available. Users dislike them because they reverse the basic social dynamic of commerce, which mandates that the customer is always right. When you find yourself using required fields, ask yourself "Is this bit of data worth transforming the nature of my relationship with my customer?"

Ask yourself "Is there another way I can get this information? Can I wait and gather it later? What is the minimum amount of information I can collect and still function appropriately?"

Most important, ask, "For whose benefit am I collecting this information?" If it's for your own benefit, or to make the software easier to code, you probably need another design.

  "It Doesn't Work That Way"

Have you ever had a design meeting with your team in which your proposed solution was rejected by the engineers? (I know, this never happens.) It doesn't work that way, they say.

Here you need to ask: "How does it work? Why does it work that way?"

To be an effective advocate, you must work to understand your team and the problems that they face. Understanding how the application works—and more important, why it works that way—is critical to your success. Without a demonstrated understanding of these issues, your design may be a good one, but your team will not take you seriously, and your role as a user advocate will not be effective.

After you demonstrate understanding, you have one more question to ask: "Shouldn't it work the way that I've designed it?" Invariably, the answer is, "Yes it should, but..."

And here's where the rubber meets the road. Here is where you must lead your team through the exercise of asking good questions and creating good answers. Don't settle for the "but..." It's the standard answer and rarely serves your users' interest.

  References

Cooper, Alan. 1995. About Face. Foster City, California: IDG Books.

Nielsen, Jakob. 1999. When Bad Design Elements Become the Standard. Alertbox, November 14, 1999. (http://www.useit.com/alertbox/991114.html).

Norman, Donald. 1988. The Design of Everyday Things. New York: Doubleday

Wood, Larry E., ed. 1997. User Interface Design: Bridging the Gap from User Requirements to Design. Boca Raton, Florida: CRC Press.

  Author

Whiteboard Column Editor
Elizabeth Buie
Senior Principal Engineer
Computer Sciences Corporation
15245 Shady Grove Road
Rockville, MD 20850
+1-301-921-3326
fax: +1-301-921-2069
[email protected]

Joshua Seiden is an interaction designer and president of 36 Partners, a small consulting company based in New York City. Before founding 36 Partners, he spent four years at Cooper Interaction Design, designing interactive products and helping to build and develop Cooper's practice. He can be reached at [email protected].

 

©2002 ACM  1072-5220/02/0100  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2002 ACM, Inc.