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.

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?

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.

Of Choice and Forgiveness

It was five minutes before my meeting with a colleague (on usability, in fact!), and I was shutting down my laptop to head over to the meeting room. Earlier in the day I’d noticed that little exclamation point on my Windows Shutdown button, indicating that updates would be installed when I shut down. However, in my rush to get to the meeting my hand went on autopilot and I clicked the Shutdown button before I remembered the updates.

18 updates this time. Of all the days. Well, I thought to myself, hopefully they’ll be fast.

They weren’t.

20 minutes later, I finally made it to my meeting. (Fortunately, my Android tablet doesn’t have these types of usability issues, so I got a message to my colleague about the delay.) Ah, the irony: poor usability got in the way of my getting to my usability meeting!

Two key usability principles were violated in this experience. The first is that good design gives the user a choice when a course of action could have negative consequences. Windows should have told me approximately how long the updates would take to install, and then let me choose whether or not to install the updates at that time.

The second is that good design is forgiving. Errors should be easy to correct. I hadn’t meant to start the update process, but once I did, there was no way to cancel or pause the updates—only the ominous warning not to shut off my machine. (I learned the hard way that the warning is valid. Once a similar update was making me late for a critical meeting where I was presenting. In desperation I shut the machine off anyway, and it was never the same afterward.)

I’m sure the person who designed the interface and process thought they were justified in not giving me a choice of when to install the updates. After all, updates are good, and people shouldn’t delay installing them. Reasonable assumptions, right?

Not for me that day.

Usable design doesn’t impose assumptions on users; instead, it gives them the ability to make choices and recover from those choices when necessary.

Making the Miracle Happen

One of my favorite cartoons in the world is this one by Sidney Harris. A scientist stands at a blackboard with his colleague. On the board is a complex equation, except at step two, which consists of this simple statement: “Then a miracle occurs.” His colleague responds, “I think you should be more explicit here in step two.”

Most of us have probably found ourselves in the place of the first scientist. Our tendency as human beings to gloss over tasks that are time-consuming and tedious.

This is true in design as in almost every other endeavor. Maybe we get tired or run out of time, but whatever the reason, we skimp on the detailed planning required for a good design. We tell ourselves that somehow it will all work out. Instead of following the old adage “measure twice, cut once,” we measure haphazardly and end up cutting and re-cutting many times. We might think we’re saving time, but we really aren’t—if we don’t have time to plan our design thoughtfully, how do we think we’ll find the time to rework it?

There’s no secret to the miracle: it happens when we pay the price to get to the necessary level of detail for a bullet-proof design.

User Point of View: Elusive but Essential

Creating a hyperlink is one of the simplest things we do online:

  1. Select the text to be linked.
  2. Choose something like Add Hyperlink (usually via shortcut keys, a context menu, or a link icon).
  3. Type or paste in the target URL and save.

Pretty straightforward.

But there’s a way to make it harder, as I discovered when using an authoring/content management application. In this application, everything is stored in a database as a separate “object”: Documents are objects, pictures are objects, text fragments are objects, and yes, hyperlinks are objects. The hyperlink object has properties, such as the type of link (internal or external) and the link destination (internal document or external URL). This structural design makes sense in terms of content management and has some clear advantages.

In the application, the process of creating a hyperlink reflects this structural design. But as a result, it’s a lot more complex.

  1. Select the text to be linked.
  2. Choose Add Hyperlink. I get a list of names of hyperlink objects. Turns out I can’t just specify a destination; I have to use an existing hyperlink object or create a new one. Trouble is, it’s not apparent where any of them are pointing, so I can’t easily tell which one to use.
  3. Start opening hyperlink objects to try to find the right one:
    • If I find it, I close the object, then double-click to select it.
    • If I don’t find it, proceed to step 4.
  4. Click New to create a new hyperlink object.
  5. Name the object, specify the target document or URL, and save. The new object is now automatically attached as a hyperlink to the text selected in step 1.

Does this process make sense based on the underlying structure of the application? Absolutely. But as a user, do I care or even need to know about the underlying structure when creating a hyperlink? Not really; I just wanted to get the job done as quickly and easily as possible.

And here’s the thing that’s easy to lose sight of: the process did not have to reflect the underlying structure. It could have been handled behind the scenes like this:

  1. Select the text to be linked.
  2. Choose Add Hyperlink.
  3. Point to an existing internal document or type an external URL and save. Behind the scenes, the application checks to see if a hyperlink object already exists, based on the target I specify. If it does, the application uses it. If not, the application creates it.

As interface or process designers, it can be tricky to step out of our world and into the users’. It takes thought and observation to determine what matters to them. It can even be hard to give up a design that makes a lot of sense to us or to the software developers, but which doesn’t serve the users. And simplifying the process for users almost always requires more work on the back end. But the result is a more user-friendly, efficient design and process, and that pays big dividends on an ongoing basis.

Design Bloopers #1 — Email Attachments

Lately I’ve had reason to ask, “Is it just really hard to design a good user experience when saving email attachments?” Here’s how the process works on AOL:

  1. I receive an email with an attachment. At the bottom is a Download button, so I click it and download the attachment.
  2. I also want to save the text of the email to my hard drive, so I click Save. I get the following dialog box:

  3. Okay, it would have been nice if they realized that I just downloaded the attachment. Or maybe I really didn’t— otherwise, why would they be asking me again?

    So I click Yes and get this dialog box:

    It’s not just AOL. The other day at work I received an attachment in Outlook. I opened the document and made some changes, then tried to close the email.

    “Do you want to save the attachment?” Outlook asked me. I clicked Yes.

    Responded Outlook: “You cannot save this attachment because it is read-only.”

    Humor aside, the issue isn’t that it’s hard to design a good user experience for email attachments. The issue is that user observation or testing can prevent design failures like these, along with an illogical and even frustrating user experience.