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.
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!)
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:
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.
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:
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:
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:
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).
Here’s another example from a dialog box which allows me to add a link to an email:
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.