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.

Microcopy and Disaster Avoidance

If you visited my blog over the last few days, you probably noticed it was down for a while. There’s a usability story behind that.

Last Monday I spent about four hours on a blog post, complete with complementary screen shots. I posted it and all was well, until I noticed that I needed to make a slight edit. I tried to log back in to make the changes, but I couldn’t. I kept getting this error message:

Now as much as I’d love to think that millions of people find value in my blog and were hitting it all at once, that seemed pretty unlikely. So I tried a number of typical troubleshooting strategies, all to no avail. Finally, because the problems started shortly after I upgraded my version of WordPress, I decided to uninstall and reinstall it.

That’s when things got interesting.

I’d installed WordPress using a simple WordPress utility page offered by my ISP, so I went there for the uninstall. On that screen, I was duly warned:

This tool can remove WordPress from your hosting account, or remove the installation from our records. These actions are not reversible!

[Uninstalling] will permanently delete this installation. This includes any files installed, as well as any database tables. Additional themes, plugins, modules, cache files, etc will be left behind.

I’d done enough uninstalls and reinstalls of various products to know that there was a good chance something would go wrong. So I carefully downloaded a copy of my blog site from the server to my hard drive. Then I uninstalled WordPress, reinstalled it, and checked my site. All my blog posts were completely gone.

No problem, right? After all, I’d suspected things wouldn’t go smoothly. So I went to my backup. Aha, there were the post folders, all neatly organized by month and year. I opened them up to start retrieving the lost posts—nothing. The folders were all completely empty.

At this point, I started to get concerned. How was it possible to have a complete backup of my site with no blog posts? Googling brought up an answer I definitely didn’t want: the actual text of my blog posts had been stored in a database table, which had been deleted along with my WordPress installation. Who knew?

Not me. Just to be clear, I have a pretty strong technical background. I’ve worked for IT organizations in various companies and managed web sites. But using WordPress was a new experience for me, and my assumption that content was stored in HTML files turned out to be false.

Fortunately, the story has a happy ending, as you can see from my blog (since almost all my old posts are back). Despite the warning that the uninstall was not reversible, I knew from experience that my ISP probably did have a backup of the database table. I contacted them and they were able to restore all but my last post, which had only existed for a few hours and wasn’t included in the timed backups. (Here’s a shoutout for the great help I received from Dot5hosting to get my blog restored!)

So there’s a lesson here, and it has to do with microcopy. I suspect that the average WordPress blogger is like I was and doesn’t realize blog posts are stored in a database table. That being the case, the following revised microcopy could help others avoid the fiasco I just experienced:

[Uninstalling] will permanently delete this installation. This includes any files you have installed; it also includes all content you have added, which is stored in MySQL database tables. (For instructions on backing up your database tables, click here.) Additional themes, plugins, modules, cache files, etc will be left behind.

There’s a feedback link on the WordPress utility page mentioned above. I think I’ll send them a link to this blog post. If it spares someone else the “adventure” I went through, that would be a good thing!

 

The Problem of Proximity

I admit it: As a designer, I’ve occasionally indulged in the fantasy that users carefully (and appreciatively, of course) examine the interfaces I’ve created as they use them. Doing this, they see the logic of the design and are able to complete their tasks without error.

But my own experience using screens designed by others gives me a reality check. When I use a screen, I don’t have the desire or time to analyze it. Instead, I make quick judgments about features and functions based on their context, perhaps looking for key words like “Submit” or “Delete.” I want to complete my task without a hassle and move on.

Lately, though, I’ve used some interfaces that involved a bit of hassle. As I reflected on these experiences, I found a common theme: two elements placed in close proximity made it easy, even likely, for me to make a mistake.

Bait and Switch

When similar elements are placed near each other, it can be too easy to choose the one you don’t really want. For example, the browser image below shows that the x to close a tab is right next to the + to open a new one. It’s inconvenient to open a new tab you don’t want, but it’s worse to close one you didn’t want to close.

close tab and start tab next to each other

AOL’s desktop application has a similar issue with its email inbox. The button to delete an email is right above the link to view recently deleted email. More than once I’ve clicked the Delete button when I just wanted to view deleted mail. (At least when I do that, I can view the email I hadn’t meant to delete, once I click the right element!)

aol delete elements

To solve the problem, it isn’t enough to use different element types (such as a button vs. a link, as on the AOL screen). The better solution is to place the elements far enough apart that the user isn’t likely to click one when they meant to click the other.

Here’s an example. I designed an order fulfillment screen which had a button for saving an order and another for clearing the order form. I didn’t want users to experience the frustration of erasing data they’d meant to save, so I placed the Clear Form button on the opposite side of the screen from the Save Order button, rather than the typical position next to it:

order entry form with save and reset buttons far apart

With this placement, it’s likely that the user will only choose to clear the form intentionally, not by accident.

Hover to Hide

I enjoy family history, so I often visit genealogy web sites. Two of them use hovering where it’s likely to interfere with the task I want to do.

One site offers a History dropdown list which I use frequently. Right above it is a user dropdown menu which is activated by hovering over my logon name.

family history user and history menus

If I overshoot the History menu by even a pixel or two, I accidentally activate the user menu instead, which hides the History menu I’d intended to display:

user menu hiding history menu

Ironically, a more user-friendly approach appears right on the web site: both the Church Websites and History menus are activated by clicking, not hovering, so it’s much less likely they’ll get in the way when I don’t want them.

Here’s an example from a different site. After I run a search and then open one of the results, an All Results link appears at the top of the screen, making it easy to return to the results list:

all results link under menu bar

As you’d imagine, I use this link all the time. But if I overshoot it, I activate the Family Trees menu, which hides most of the link I wanted:

all results link hidden

As a user, I appreciate it when an interface makes it easy for me to make the choice I want, without other things getting in the way.

Making Me Think (Nod to Steve Krug)

Finally, here are several examples of potential confusion due to unclear placement of text. The screen below shows birth information for someone in my family tree. Notice the Sources and Tag options near the bottom of the image. When elements are placed next to each other and separated by a vertical line, they are typically choices on a menu. I assume that if I click Sources, I’ll be able to take some action related to sources; if I click Tag, I’ll be able to do something with tags.

However, this screen breaks with convention: Although Tag functions as I expect, Sources is actually a heading for any sources that may appear below (particularly confusing in cases where no sources appear).

example of unclear placement of text

Here’s another example from a dialog box which allows me to add a link to an email:

example of confusing text on link screen

At first glance, Test this Link appears to refer to the email address, since it’s (sort of) across from it; it’s actually a little lower than the email address, and it’s even farther away from the URL box. But when I click it, it becomes obvious that it refers to the URL box.

Okay, so neither screen is too hard to figure out with a few seconds of thought and experimentation. But shouldn’t UI text be clear without my having to puzzle over it, even briefly?

Here’s a simple change that makes the dialog box above more clear:

The proximity of elements to each other matters. It can enhance the user’s experience or interfere with it. It’s worth a designer’s attention.

Packing a Punch with Microcopy

Someone recently asked me if I’d ever written microcopy. I wasn’t familiar with the term. But as I learned more about it, it turned out I had written quite a bit of microcopy; I just hadn’t called it by that name.

Microcopy refers to short snippets of text which guide the user, in context, as they complete a task. In a post on bokardo.com, Joshua Porter describes it as “small yet powerful copy. It ’s fast, light, and deadly. It’s a short sentence, a phrase, a few words. A single word. It’s the small copy that has the biggest impact.”

Most often, microcopy is used to

  • instruct (“Enter your credit card billing address below.”)
  • inform (“You can change your choice later on the Preferences tab.”)
  • reassure (“We will NEVER give your email address to anyone else. Period.”)
  • warn (“If you leave the Name field blank, others will not be able to search for you by name.”)

Joshua Porter and Connie Malamed both assert that microcopy can make or break a design. In my experience, that’s not an exaggeration. An earlier post gave some examples of microcopy gone bad, with consequences ranging from confusion to late rent payments.

So how do you write effective microcopy? Consider these guidelines:

  • See things from the users’ perspective. What will they wonder about? Be concerned about? What mistakes are they likely to make?
  • Make it as short as possible while still being absolutely clear.
  • Make it noticeable. Microcopy doesn’t do any good if it falls in the user’s blind spot.
  • Test it on users. Something that might be perfectly clear to you may be obscure to your users.

Getting the microcopy right will go a long way toward getting the design right.

Sending the Right Message

When interface text works well, it’s unobtrusive; it sends the right message instead of getting in the way of the message.

Recently I attended a conference which provided an app for attendees. Among other things, the app allowed me to add other conference-goers as “friends.”

When I tapped the Friends icon to add my first friend, I got a screen that said, “You currently have no friends.” It made me smile because it sounded like some kind of backwards fortune from a fortune cookie. While I knew what was meant, a better alternative would have been, “You have not added any conference attendees as friends,” or “Your conference friend list is currently empty.”

That’s a fairly light-weight example: the end result was nothing more serious than humor.

Here’s another example from the same app, a little more problematic. When updates were available for the app, users got a message on a red background:

The arrow at the end of the message appears to be pointing to the left border of the gear icon, which of course doesn’t make sense. I initially thought that the arrow was just off a little and I needed to tap the gear icon. However, I discovered I had to tap the large red icon on the far right.

Of course it wasn’t too hard to figure out what I was supposed to do. But every time I saw the message, the inaccurate text drew attention to itself and distracted me, however momentarily, from completing the task at hand.

This example is intriguing because the designer was apparently trying to compensate for the inaccurate UI text by making the correct icon large and red, rather than solving the underlying problem. But the problem could have been solved fairly easily:

Inaccurate or unclear interface text isn’t always so harmless. An apartment complex where I once lived gave renters the option to schedule recurring online rent payments. Great convenience, right? So I signed up. When my rental contract came up for renewal some months later, I logged on to the site to make sure the new amount was shown (yeah, they’d raised the rent). I saw a screen like this (fake amounts, of course):

The title—Current Monthly Charges and Monthly Auto-Pay—led me to believe I was looking at my monthly auto-pay. The new amount was correct, so I logged off, confident that my rent would be paid on time.

Several days later, I found a demand for payment taped to my door.

I logged back in to the site, looked at the screen, and it still took me a few minutes and some playing around to figure out what was going on. Apparently when my contract was renewed, my old auto-pay was deleted. But the screen gave no indication of a cancelled auto-pay. It wasn’t until I clicked Schedule Monthly Auto-Pay that I was taken to a screen informing me that no auto-pay was set up.

When I examined the screen more closely, I realized the auto-pay columns were blank, and the sum in the Auto-Pay Amount column amount was zero. But I had focused on the section heading and rent amount, which were correct, so I didn’t realize there was a problem.

The simple addition of the text shown below would minimize the chance of error (and save a lot of hassle for renters):

Clear, accurate interface text can make the difference between a design that works and one that doesn’t.