Why usable design matters, and what we can do about it

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.

(Usability) Adventures in Job Hunting: When Minutes Count

Searching for work opened my eyes to an area of user experience I’d never thought much about before: the online experience of finding and applying for jobs.

While searching one day, I found two jobs at XYZ Company* which looked like good opportunities. So I clicked the career link on their web site to apply.

XYZ Company’s job application process invites applicants to create a profile which hiring managers can view in connection with their job application. The profile is essentially a résumé, including contact information and work experience. Because I’d applied for a different job previously, my profile was there but outdated.

So I started by updating my profile. That’s when things got interesting. I’d made a few changes, and then noticed that there was a button to attach a LinkedIn profile. Had I done that before? I didn’t remember for sure, and there was no indication on the page as to whether the LinkedIn profile was actually attached. So I clicked the button just to be safe. When I finished attaching (or reattaching?) my LinkedIn profile and returned to my profile page, all my recent changes had been lost.

After retyping my changes, I reviewed the work experience section. A recent job was missing, but the only place to add it was at the end of the work experience list, which put it out of order (work experience was listed most recent first). There was no way to reorder the items, so my two choices were to put the job out of order, or insert a blank job entry at the bottom, and then copy and paste everything down one item so I could insert the latest job at the top. Because I wanted my profile to be accurate and well-organized I opted for the latter, which took considerable time and required double-checking to make sure I hadn’t made errors as I laboriously copied and pasted several dozen fields.

The next task was to update the cover letter, which oddly was part of the profile. My old one was there, but it wasn’t relevant to my new job. But then I realized I could only have one cover letter, and I was considering applying for two jobs. There was no option but to write a generic cover letter, which was definitely not ideal.

The final usability glitch was that the button at the bottom of the profile screen was labeled Submit. Did it mean I was submitting the application for a certain job, or just saving my changes? It wasn’t clear, and I never got the chance to find out. After spending several hours wrestling with the online form, I returned to the job listings and found that between the time I started the online application and the time I checked, the job had been removed from the list of open positions.

Did usability issues make a difference here? Well, possibly XYZ Company missed out on an employee who would have been a perfect fit for their job. I definitely lost out on the opportunity to apply. Usability made the difference here, where minutes counted.

*The names of the guilty have been changed to protect possible future job opportunities.

Wanted: Helpful Error Messages

I would love to have written a post on well-designed error messages. The trouble is, I can’t think of any I’ve seen lately. In fact, the idea for this post came recently as I was trying to install Windows updates. When the installation finished, I got the following error message:

win_update1

There was the seemingly obligatory error code that means nothing to the user, though presumably it would to a tech support person (although when I worked in tech support for a computer manufacturer, I never remember seeing a list of these error codes and how to resolve them).

However, I was grateful that it wasn’t the only indication of the problem—until I read the text. “Windows Update encountered an unknown error.” Not too enlightening. It’s also not clear if the text below the error code about restarting is related to the error or not. After all, if it is, why is the error unknown?

At least I was encouraged that I could click a link to get help with the error—until I clicked it. This is what appeared:

win_update2

It seems that with an exact error message, Windows Help should have presented the exact Help document. When it gave me the long list, I scanned over it to find one that matched the error code I got. I couldn’t see one. So I gave up trying to get help that way.

Finally, I decided to reboot, and the error message disappeared. As it turned out, nothing failed; the error message was unnecessary. The computer just needed to be restarted, as it often does after updates.

Takeaways: What are the elements of a good error message?

  • It only appears when there’s actually an error.
  • The error message explains the error or problem clearly, in terms that make sense to the average user.
  • If an error code is given, the message explains what it means and how it is used (e.g., provided to tech support).
  • The error message gives concrete action the user can take to fix the problem.

It isn’t rocket surgery, as Steve Krug would say. But it does take awareness and caring enough about the user to make it happen.

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.

The Power of Conditions

“If…then” is logic a computer understands very well. In other words, computers are great at doing different things depending on different conditions. For example, my gmail background changes depending on the time of day. Adobe’s web site also uses conditions: when I start to download software, the site determines which browser I’m using and presents download instructions customized for my browser.

Making different options conditional is generally easy from a coding standpoint: In other words, if you’ve already written the code for options A, B, and C, it’s usually pretty easy to allow users to choose between them, or to specify parameters to make the computer to choose between them.

We usually notice when conditions should have been used but weren’t. I had to smile when opened the Vitacost mobile app and saw a message inviting me to download the mobile app—yes, the one I was using. Conditional code could easily have ensured that mobile users didn’t see that message.

Here’s a more significant example where conditional code could have improved the user experience. I was searching for hotels in the Austin (Texas) area for An Event Apart. The Hilton web site brought up two hotels that met my search criteria, and then gave me a message that they were displaying additional hotels for me. A nice touch—except that the first hotel on the list had no rooms available! Conditional code could easily have been used to avoid showing alternate hotels that couldn’t be booked.

hotel_bad_example

The Marriott site, on the other hand, made good use of conditional code. Different rates were shown on different tabs, and if a tab had no rates, it was greyed out with a red message that telling me those options weren’t available for the dates I requested. I wasn’t offered options, only to be told they couldn’t be selected.

hotel_good_example

Harnessing the power of conditions can do wonders to improve the usability of a web site or application. Are there areas where you could use conditions to give your users a better experience?

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.

The Irony of Force

Recently I borrowed a DVD from the library. After watching the previews, I started the movie. But partway through I had to turn it off and take care of some other tasks.

Later, when I was able to watch the movie again, I tried to start where I left off—but I couldn’t. Navigation was disabled and I was forced to go through the previews again. This happened several times.

So did I gladly watch the previews over and over again each time I put the DVD in? No, I either muted the sound or turned my attention to other things. Finally I discovered I could at least fast forward through them.

I found myself wondering about the motivations of the company who configured the DVD to make viewers watch the previews each time the DVD was started. They seemed to think that if they didn’t force us to watch them, we wouldn’t. (That in itself says something about their confidence in the appeal of the previews!) But what if I’d already seen them? What if I were in a hurry? What if the movies being previewed didn’t interest me?

Did they think that forcing me to watch the previews would sell more DVDs? The truth was, it made me not want to buy the DVD I’d borrowed or the ones being advertised! They thought they could make viewers watch the previews, but their plan backfired and left me with a poor user experience.

Whenever possible, designers should give users a choice instead of forcing a given configuration on them. Obviously, there may be times when offering users a choice is not feasible. In that case, it’s crucial for designers to understand users, not make assumptions that end up frustrating them.

Apples vs. Apples

Many web forms have two buttons at the bottom of the page: Submit and Cancel (or their equivalents). A user who accidentally clicks Cancel when she meant to click Submit could unintentionally lose all her form data—frustrating for any user.

In an online discussion on this topic, a poster suggested that the primary action should still have a button, but the secondary should be changed to something completely different, like a link, to avoid this type of confusion.

Would this reduce the number of times users click something they don’t mean to click? Possibly, although as mentioned in The Problem of Proximity, I still accidentally clicked the option I didn’t want out of a button and link pair because they were close together.

The trouble is that changing one button to a link introduces a new set of problems. When we mentally process elements on a page, we tend to see things in terms of their functions or category. Buttons at the bottom of a form to fall into the category of “possible actions I can take on this page.” When one option appears as a button but the other appears as a link, it looks like the two options are not in the same category. In addition, hyperlinks have a semantic meaning: they are supposed to link to related information. The fact that they can be scripted to behave like buttons doesn’t mean that it makes sense, or that doing so provides a good user experience.

As an analogy, consider the confusion that would result at a traffic intersection if the stop signal were a red light, but the go signal were a green sign. Stop and Go are possible actions at an intersection, and drivers expect them to be different variations on the same type of control: a red light or a green light.

And there are times I do want to take the secondary action. In that case, I don’t want the option to look drastically different. I want to be able to tell at a glance that it’s one of the possible actions I can take on this page.

Here’s a real-life example from familysearch.org. When I create a source, I see a bright blue button labeled Save at the bottom of the page. Next to it are two other options presented as links. For quite a while, I didn’t even realize those options were there because my eye was drawn to the large blue Save button and I subconsciously ignored the things-that-are-not-buttons when considering actions to take on this page.

But even later, when I realized that the Save and Attach option was available and would save me time, I still found myself forgetting to click it because it didn’t grab my attention and didn’t look like a button. I had to force myself to create the habit of clicking something that didn’t look like it should be clicked to process the form—definitely not an optimal user experience.

Google did a good job with their Insert Image dialog box. The primary button is clearly highlighted, but the secondary option is still the same type of control: a button.

In other words, they’re both apples. There’s no need to make one look like an orange, especially when it’s confusing to the user.