Design to the Rule or to the Exception?

Microsoft Excel has a lot of great features. But I’ve long wondered why, when you type an equation in a cell, the default is to treat it like text.

For example, when I type 1+2 in a cell, Excel doesn’t add the two numbers, but instead displays “1+2” in the cell.

Now, this is the kind of behavior I expect in a word processing or presentation program. But Excel is a spreadsheet. It’s made specifically for processing numbers. So why did the designers decide that the default should be to treat an equation like text unless I type = or + at the beginning?

In contrast, Corel’s Quattro Pro treats numbers like numbers. When I type 1+2 in a cell in Quattro Pro, I get the result I expect: 3. I don’t have to type an unnecessary symbol at the beginning of the equation to signal that I’m using numbers.

Excel’s counter-intuitive design calls to mind advice from a fellow designer: “Don’t design to the exception; design to the rule.” Her advice is good. As designers, we shouldn’t force users to jump through hoops constantly because we’ve designed to the exception.

However, are there times it is appropriate to design to the exception? Accomodating colorblindness comes to mind. I once designed an interface that relied on color to provide important cues to the user—only to discover that one of our key stakeholders was colorblind.

So how many users are colorblind? I’ve seen estimates ranging from 5 – 8% for males, and less than 1% for females. That means we’re talking relatively small percentages here. Is that too small to design to the exception?

I don’t think so. And here’s the key difference between the Excel example and the colorblind example: in Excel, the exception was an extremely unlikely user scenario. Users virtually never want “1+2” to appear in Excel as “1+2.” They want to see the results of the equation. It doesn’t make sense to design to a scenario that almost never happens.

On the other hand, when we design to the exception for colorblindness, we are designing for a user, not a scenario. Most users probably won’t have challenges because of color in an interface. But for those who do, it affects their entire experience. Not only that, there are alternatives to color that work equally well for either type of user, colorblind or not. So in this case, it makes sense to design to the exception and find a win-win solution for the majority of users.

So when we question whether or not to design to the exception, we can make a better choice by asking if we’re designing for a scenario or for a user.

Designer 1, User 0

Most micowaves have a timer function. On my old microwave, I’d set the timer, then start it by pressing Start. I stopped it by pressing—as you might expect—Stop or Clear.

Then I moved into a new place with a different microwave. I pressed the Timer button, entered the time, and pressed Start. Nothing happened. I pressed it again, harder this time. Still nothing. Did I still not press hard enough? Was the timer broken?

After a bit I noticed a message scrolling slowly across the display: PRESS TIMER.

So not only do I press Timer to set the timer, I also press Timer to start the timer. Turns out I don’t press Stop to stop the timer; I have to press Timer yet again.

In this example, the functions that seem intuitive don’t work, and I have to be guided away from them to functions that seem less logical but which actually work.

Here’s another example: In Dreamweaver, when I click the button to see files on the remote server, I sometimes see the message shown on the screen below. When I first saw it, like many users, I just scanned the text rather than reading it word for word. I saw a button, saw the key words “remote files” and “click”—and I clicked the button.

Nothing happened. Finally, I read the text closely enough to realize that I wasn’t supposed to click the button that looked like it should be clicked. Instead, I needed to go find that button somewhere else. And when I located the button, it didn’t look like the one in the message; in fact, it was grayed out. But clicking it displayed my remote files.

dw_remote_buttons

If we have to direct the user away from what seems logical to them to something that seems logical to the programmer or designer instead, we’re doing it wrong. To use a sports metaphor, we shouldn’t be tackling members of our own team—which users are. Instead, we should be doing everything we can to help them win.

User Point of View? Yes, But…

An earlier post talked about the importance of designers understanding the user’s point of view. There is a caveat, however, illustrated in a quote often attributed to Henry Ford: “If I had asked my customers what they wanted, they would have said a faster horse.” While users’ needs are real and important, the truth is that we as users often aren’t able to articulate what we want. Beyond that, we may not know what’s possible, so we don’t know what to ask for. Finally, we may ask for things we think we want, only to find out we really don’t.

I use a web site that includes a custom directory of people I interact with on the site. The directory is a single page listing all names, and until recently, names were listed in the order in which they were added. Over time, my directory has grown to be quite lengthy (over 400 names) and finding a particular individual could be a hassle.

Other users apparently had the same concerns, because on the support forums more than one user requested the ability to sort the directory by the various columns on the page: name, date added, etc.

The site owners acted on the feedback and put new sort functionality in place—only to have users give negative feedback about it! After using it for a short time, I realized why: sorting really wasn’t that helpful for finding people in my list. What I should have asked for was filtering: the ability to type in a name, for example, and have only matches show up. But I didn’t realize that when I gave my initial feedback, and apparently neither did other users nor the site owners.

Jakob Nielsen summed it up well in his ironically-titled Alertbox article on this topic: “First Rule of Usability? Don’t Listen to Users.” His article includes these “basic rules of usability”:

  • Watch what people actually do.
  • Do not believe what people say they do.
  • Definitely don’t believe what people predict they may do in the future.

Following these “rules” gives designers more more accurate feedback so we can meet our users’ actual needs rather than what they say they need, which may not be the case at all.

Accessibility: Putting Yourself in the User’s Place

I once worked at a building where, oddly, the handicapped parking spaces were not in the row closest to the building, but rather in a long strip perpendicular to the building (simplified picture below). The row closest to the building was partly visitor parking spaces, and partly open spaces.

rob_parking_lot

As an employee I didn’t give it much thought, and frankly, I was happy on the rare occasions that I got one of the coveted spots close to the door.

That was, until the day my father and I attended a Saturday seminar at the building. My father is in his 80s and walks with a cane. Getting around is slow and physically taxing for him. He had his handicap placard, and we looked for a handicap parking place. But there were no close places, and in fact some of the non-handicap places, although not close, were still actually closer than some handicap spaces!

Seeing the experience through my father’s eyes put a whole new spin on it.

I tried to imagine the reasoning of the people who designed the parking lot. Did they justify their choices because handicap spaces near a building’s entrance are often empty? Did they think the handicap places were “close enough”? One thing was clear to me: I doubt they had ever accompanied a handicapped person as they tried to find a close parking place on a busy day.

I came away with some much needed-reminders:

  1. Test designs with differently-abled users, and strive for win-win design.
  2. Frequency of use is not synonymous with importance. Even if my father only needed that parking place for a few hours on a Saturday morning, that need was very important for him.
  3. We can’t excuse ourselves in failing to address accessibility.
  4. Shortcuts and assumptions compromise user experience.There’s no substitute for understanding one’s users, and that understanding means putting ourselves in their place.

User-Optimizable Design

We who work in user experience typically want to delight our users. However, doing so can be challenging: not only is our user base typically diverse, but our users’ needs and preferences change over time. They become more familiar with our product or system, and even with technology in general. In addition, their devices are often quite diverse as well.

Well, with a little creativity and a lot of user understanding, we can delight more of them more often. What’s the key? We could call it “user-optimizable design”: giving users some key choices to allow them to customize their experience in a way that’s best for them.

Here are a few of my favorites.

My Life Organized: Compact vs. Standard View

I love white space sometimes, but not on my to do list. I’d rather see more of my items at a time so I can plan appropriately. That’s why I love the way my favorite life management application, My Life Organized, gives a me choice of standard and compact view. Sounds simple, but it’s a big deal for me because the compact view makes my user experience so much better.

Compact View
Standard View

Gmail’s Reply-to Function

Frequently I bring up an email I’ve sent and reply to it when I need to send additional information to the original recipient (probably because I forgot something in the first email!). When I do this, virtually every email client puts my email address in the To box, which is almost never what I want. Why would I bring up an email I’ve just sent, and re-send it to myself at the same email address?

To my surprise and delight, I discovered that gmail knows what I really want to do. Even when I reply to an email I’ve sent, it places the original recipient’s address in the To box instead of mine. Every time I use that feature, I’m grateful a company took the time to understand its users.

Choice of Tips at Startup

Some applications, such as Techsmith’s Snagit Editor, allow users to choose whether to see a productivity tip each time they start the application. Techsmith understands that users may appreciate a helping hand at one point, but later get to the stage where they don’t need it.

Keyboard Shortcuts

Not everyone cares to use keyboard shortcuts, but for those who type a lot, they’re a major time-saver. Adobe Dreamweaver and Corel WordPerfect allow users to customize their keyboard shortcuts so they make the most sense fo the user. As a bonus, WordPerfect allows users to choose whether to display keyboard shortcuts on menus.

Ancestry’s Suggested Records

Anyone sleuthing for information on an ancestor likely wants to know about any and every record that exists. In a stroke of genius, Ancestry.com added a Suggested Records panel on the screen that shows information on a single record. Based on the user’s search parameters, Suggested Records shows records that are probably for the same person. Sure, not all the records turn out to be relevant, but the bulk of them are, which saves time and alerts researchers to records they may not have known existed.

Of course, user-optimizable design can be carried too far. Too many options for customization can be confusing and actually reduce usability. But if we understand our users well enough, we can provide them with some key customization options that will give them a better user experience.

Getting to the Right Forest, Part 2

In The Design of Everyday Things, Don Norman shares the humorous anecdote of Alice, who was driving with her friend Sally. Alice noticed that the rearview mirror wasn’t adjusted correctly on the passenger side, so she asked Sally to adjust it—or at least she meant to. What she actually said to Sally was, “Please adjust the window.”

Sally was puzzled and tried to get Alice to explain exactly what she wanted done with the window. Alice, on the other hand, couldn’t understand why Sally was having a problem responding to such a simple request. Alice’s solution was to repeat the erroneous request, louder and louder each time.

Not surprisingly, Alice’s best efforts didn’t solve the problem because she didn’t realize what the problem was.

Misdiagnosing the problem is a common human failing. But why does it happen? In my own experience, there are two main reasons. First, we have a tendency to be blinded by our own assumptions, our own world-view. Sometimes we realize we are making assumptions, but they seem so obvious that we don’t feel the need to question them. Other times, we aren’t even aware of the assumptions we’re making. Alice assumed she was communicating clearly. It took some time before she realized that she held this assumption, and that it was in fact untrue.

The second reason, easier to see, but perhaps just as hard to address, is that we don’t do the hard work of gathering data and thinking through the problem. Sometimes when I’m coding, I’ll be stumped by a tricky problem. I’ll try everything I can to figure it out—or so it seems. Finally, I’ll decide to post a question to a forum or help group, which of course requires a clear explanation of the problem and what I’ve tried so far. And more than once, I’ve discovered the solution to my problem in the very act of trying to explain it to someone else. I believed I’d thought through the problem and exhausted all my options, but I really hadn’t.

Thoroughly examining a problem can seem tedious and time-consuming, but it’s not nearly as time-consuming as repairing the mistakes that virtually always result from misdiagnosis.

So how can we avoid these traps and increase our likelihood of correctly pinpointing whatever problem we’re dealing with? Here are some suggestions:

  1. Get as close as you can to the problem. If possible, observe it as it happens. Don’t rely on someone else’s account or circumstantial evidence. See it for yourself.
  2. Ask questions. Is it really a problem? What led to it? Why do we need to solve it? What will happen if we don’t? What are our options? What are the consequences of each one? What would we do if money and time were no object?
  3. Write out the problem as a way of thinking it through. It may help to write as if you’re explaining the problem to a trusted friend or colleague. Chances are good that you’ll experience the same thing I did: the very act of writing out the problem will open your eyes to new information about the problem and potential solutions.
  4. Diagram the problem. In the software requirements course I took at Red Rock Research, we learned how to sketch use cases, complete with computers, systems, actors, and actions. What an eyeopener it was to make myself think through a design problem by sketching all the components and their interaction with each other!
  5. Collaborate. Others will likely have a different take on the problem and different insights into it. Not only that, when you get a group of people together who want to make a good faith effort to solve the problem, the ideas and insights of the group will feed off each other. I saw this repeatedly when I led a team of very talented, creative, and ego-free technical writers. As we brainstormed together, the insights and solutions we came up with were better than any of us could have come up with alone. The whole really was greater than the sum of the parts.

If addressing problems is a major focus of good design, then we can’t do better than to identify the right problems.

Getting to the Right Forest, Part 1

Usable design is both about solving and preventing problems. You might think it would go without saying that we want to be solving the right problems. But it’s not always as easy as it sounds.

Some time ago I worked at a place where the intranet search had a poor reputation. Results were all over the place, often with little or no apparent relevance to the search terms entered. I’d estimate that close to 50% of the time I couldn’t find what I was searching for, even though I knew it existed and that the specific search terms I’d used appeared on the page. Eventually I’d find the page by digging up an old email with the link or asking another employee.

Employees complained about the search, and the intranet engineers acknowledged the problem. Then one day I was surprised to hear one of the engineers talk about the need to make the search “fuzzier,” presumably so it would return more results. I remember thinking to myself, I don’t search to be fuzzier; I need it to be more focused! In other words, the problem wasn’t that I was getting too few results; I was getting the wrong results.

Here’s another example. One of my favorite sites beta-tested an elegant and powerful search form. It was in a narrow banner at the top of the page, and it offered flexible options that made it simple to run a complex search. Not only that, the search form stayed unobtrusive but visible as I continued to refine my results. I never had better search results than with that interface.

Then, for reasons that puzzle me to this day, the user-friendly beta design was scrapped and a less user-friendly one rolled into production. The new design dropped some of the most useful features of the beta; in addition, the search form was moved to a panel on the left of the screen. Even with some of the most useful features removed, the search panel was so long that it went “below the fold” on many monitors, making it necessary to scroll down to see the Search button. And because it was necessary to scroll down to initiate the search, results were loaded into the scrolled-down page so users had to manually scroll up to the top of the results.

Users complained about the new design, and soon an “improvement” was put in place: When the user clicked the Search button, the web page auto-scrolled to the top of the page.

Once again, the problem had been misdiagnosed. Having to scroll up after searching was only a symptom of deeper problems with the new interface.

In her thought-provoking blog post How Reframing a Problem Unlocks Innovation, Tina Seelig shares a quote attributed to Albert Einstein:

If I had an hour to solve a problem and my life depended on the solution, I would spend the first fifty-five minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.

Realizing there is a problem is a great first step, but it’s not enough. We need to be sure we’re not chopping down trees in the proverbial “wrong forest.” We’ve got to identify the problem correctly before we can solve it. How to do that is a subject for another blog post.

Why Else We Design: Of Fences and Ambulances

There’s a poem written in the late 1800s by Joseph Malins about townspeople living near the edge of a cliff. (Googling brings up a number of different versions). Because people kept falling over the edge, the citizens decided something had to be done. Two solutions were put forth: build a fence at the top of the cliff, or put an ambulance at the bottom of the valley.

In the poem, the vote came out in favor of the ambulance. After all, the slip over the cliff only might happen. But once someone falls, well, there’s real damage to take care of.

As crazy as it sounds, in real life we see examples of this type of thinking all around us. We see it when products are developed without thoughtful design. We see it when products are released without adequate testing. We see it when software offers us choices with no indication that one might be wrong—until we get an error message after choosing the wrong option. And the cost of correcting a mistake is virtually always higher than preventing it—often exponentially.

In an earlier post, I asserted that design is about solving problems. That’s true, but I think it goes further. Good design makes the right path clear and minimizes the chances of going down the wrong path. In other words, good design stops problems from happening in the first place.

Why We Design

Some time ago I used a web application that underwent a major redesign. The new design was beautiful–far more artistic than the old design. Unfortunately, the redesign also removed some of the most useful features of the application, in addition to making other features harder to use. Forums were buzzing frustrated users who were finding it difficult to do their work.

I remember hearing one of the designers on the application speak at a conference. Afterward, I came away a sense of why the design seemed to have floundered. For him, the main purpose of design was to create something visually appealing. User experience seemed, if not secondary, at least satisfied by an exceptional visual design.

On another occasion (it might have been the same conference), I remember hearing someone say that design is communication. That seemed accurate, and certainly better than focusing only on aesthetics, but it still didn’t go far enough.

Later, I came across these two quotes which capture for me the essential purpose of design:

Design is not solely about making things aesthetically pleasing, although that is part of it. Design, at its core, is about solving problems. And whatever that problem is—from squeezing oranges to running faster to communicating effectively—designers strive to help their users solve their dilemma in the most convenient, simple, and elegant way. Essentially, designers focus on the experience, making it as beautiful and memorable as possible. (Nancy Duarte, slide:ology.)

[Design] comes to grips with the very essence of a problem and proceeds to develop a solution organically, from the inside out, as opposed to “styling,” which concerns itself largely with the distinctive mode of presentation or with the externals of a given situation. The design activity is based upon an understanding of the intrinsic principle of a given problem and its solution. (Hugh De Pree, quoted by Roger Martin in The Design of Business: Why Design Thinking is the Next Competitive Advantage.)

Solving problems. At the heart of it, that’s why we design!

Book Review: Universal Principles of Design

Universal Principles of Design, by William Lidwell, Kritina Holden, and Jill Butler, has become one of my favorite design resources. The book is effective as a reference, but it’s also an enjoyable read straight through. It’s a book that practices what it preaches.

The edition I have (2003) covers 100 design principles; there’s an updated edition that covers 125. Not only is the book visually appealing, but its organization and layout make it easy to find information. There are two tables of contents: one which lists the principles alphabetically, and the other which lists them by category. Each principle gets a two-page spread, with an explanation on the left and examples on the right. The explanation is readable and the examples engaging and thought-worthy.

A key strength of the book is its cross-disciplinary approach. Examples come from areas as diverse as technology, psychology, and economics, showing how design impacts virtually every profession and every aspect of life. As a result, the book encourages thoughtful application of these principles to a wide variety of situations.

I find that I come back to this book time and again, for a refresher as well as new learning. If I had one suggestion, it would be for the authors to create an interactive online version, with all the benefits of hypertext and digital media. The basic principles won’t change, though, and that’s what makes this book a worthwhile resource for any designer.

1 2