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

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.

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.

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.

Beyond Fad to Functionality: Hop Off the Carousel

Someone at work asked a group of colleagues to check out a new beta web site. The home page featured one of those trendy, large carousels that took up about half the space “above-the-fold” on my large monitor.

“Looks great!” a couple of people quickly commented. And the image on the carousel was lovely. But I found myself wondering if anyone had thought about how the carousel affected user experience, rather than how pretty the picture was.

Then another colleague raised the same concern. As the discussion went forward, a number of issues surfaced from our own experience:

  • Interference with user goals. When users visit a site, they usually go for a specific purpose. Chances are good that the carousel content will have nothing to do with that purpose, so the carousel can make it harder for users to accomplish their goals.
  • Interference with communication. In addition, carousels typically take up a large chunk of screen real estate. In doing so, they push other content below the fold or even off the screen, making it harder for users to find information they need.
  • Quick obsolescence. Carousels have a short shelf-life. Once users cycle through the images (if they have the patience for it) the carousel becomes old news.
  • User tune-out. More likely, users don’t cycle through the images. So there’s a good chance they won’t see content the site owner thinks they will see.

That got me thinking—these carousels seem to be everywhere. So was I missing something? Or was this another example of a trend being adopted because it “looks cool” and “everyone’s doing it” without considering its impact on usability?

I did a little digging and found this telling post on conversionxl.com. It turns out that extensive usability tests concluded pretty much the same thing: carousels are ineffective. As one UX advocate, Lee Duddell, humorously noted:

Carousels are effective at being able to tell people in Marketing/Senior Management that their latest idea is now on the Home Page.

They are next to useless for users and often “skipped” because they look like advertisements. Hence they are a good technique for getting useless information on a Home Page (see first sentence of this post).

In summary, use them to put content that users will ignore on your Home Page. Or, if you prefer, don’t use them. Ever.

‘Nuff said.

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.

1 2