(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.

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.

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.

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.

Why I Love My Kindle App

You know a reading app has a great design when you find yourself wanting to use its features when you read a paper book. Here are my top five reasons for loving my Kindle app:

  1. Pinch and zoom text. A simple motion lets me increase or decrease the text size, depending on my needs. (In contrast, another reading app I use makes me navigate to a setup screen to choose the font size.)
  1. Choice of background colors (but not too many). I can have black on white, black on sepia, or white on black. My favorite is black on sepia. I like having limited options rather than having to worry about pink on green, for example.
  1. Search. Finding a passage or quote couldn’t be easier. This feature comes in handy at our neighborhood book club meetings.
  1. Highlighting. I don’t particularly like marking up my paper books—it can get messy, and it’s hard to erase if I change my mind. But the Kindle app gives me the freedom to mark a passage with a subtle highlight, knowing I can undo it at any time.
  1. Integrated dictionary. Brilliant! I love being able to long-tap a word and get an immediate definition. It makes my reading more meaningful and improves my vocabulary. This is by far my favorite feature, and yes, I find myself wanting to tap words in my paper books.

I don’t just consider the Kindle app user-friendly; it exceeds my expectations for a great user experience.

1 2