Ambiguity—the Enemy of Clear Design

Design can send confusing signals when elements on the screen seem to contradict each other, or when they don’t follow expected standards.

When I go to turn on wireless on my laptop, I get this screen:

At first glance, it appears my wireless is already on: the most prominent feature on the screen (next to the bright red icon which turns out not to be an icon, but only a graphic) is the glowing green button labeled Radio On. But were I to assume the wireless is on, I’d be wrong: the current status is indicated by text under the word Status immediately to the left.

Furthermore, when I click the icon labeled Radio On, I get this screen:

This one’s even more confusing: I’d intended to turn the wireless on, and after doing so, I get a button that says Radio Off. However, it’s still glowing green as opposed to grey. I can’t tell immediately if the state hasn’t changed, or if wireless really is on, even though it says Radio Off.

To add to the confusion, if I accidentally hover my mouse over one of the other icons at the bottom of the screen, the green glow moves. I haven’t changed wireless status, but now the button in the main section looks even more like wireless is off.

It turns out the green glow simply indicates which button is active when one presses the Enter key on the keyboard. And that brings up the final confusion: the green wireless tower on the far left looks like a graphic because of its placement on the screen and its two-dimensional style. But it turns out that it also indicates wireless state: green if it’s on, grey if it’s off (see the first image above).

Is this screen impossible to figure out? Of course not. After using it a few times and experimenting a little, I know what the buttons do and how to read the current state. Essentially I filter out everything on the screen as noise except for simple text under the word Status. If I want to change the status, I click the button to the right, ignoring its color and text.

But should it have been that hard? Should I have had to puzzle over the elements on the screen or mentally filter out confusion? Probably not.

The examples below show how the screens could be simplified to eliminate much of the confusion. If wireless is on, the following screen could be displayed:

And if it’s off, this screen could be displayed:

Key improvements:

  • The new screen title is clearer.
  • The icon-that-isn’t-an-icon has been removed.
  • The state is unambiguously indicated with the tower icon and accompanying text.
  • The possible action to take is clearly indicated by adding a verb: e.g., “Turn Radio Off” instead of just “Radio Off.”
  • The confusing green glow on the buttons has been eliminated. If I were actually going to put this screen into production, I’d take the time to make one final improvement: I’d use a white glow on the buttons to indicate which is active for the Enter key, so it was clear the glow had nothing to do with wireless state.

Removing ambiguity can go a long way toward making a design more usable.

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.

The Value of Realistic Experience, or Lessons Learned from Herbal Tea

Insomnia is a frequent challenge for me, so I was interested when a friend told me about one of those herbal teas that is supposed to help one relax and fall asleep more easily. Hoping for the best, I drank a cup a little before bedtime—only to be awakened some time later with an extremely full bladder, more so than should have resulted from a small cup of tea near bedtime.

I decided to do a little checking on the ingredients. As expected, I found herbs known to promote relaxation and sleep. Then I found something I definitely wouldn’t have expected. One of the ingredients was a diuretic. Sleep promoter and diuretic: not a good combination!

Did the people who created this herb tea never try drinking it themselves? No, I’m sure they did—but probably during the day time, and probably only in small spoonfuls. In other words, they tested their design for a new herb tea in unrealistic circumstances, circumstances which did not reflect the users’ reality. In doing so, they missed a major problem—a deal breaker, in fact. (I never bought that tea again!)

A design may look good on paper or on the screen. Without trying it in a realistic scenario, users may even tell you it would work. But you never know a design really works until you’ve proven it in the crucible of realistic experience.

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.