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.


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.


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?

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.

Design Bloopers #2: Tablet Power Management

I love my Evo tablet—it has revolutionized the way I manage my life. Like most tablet owners, I try to maximize battery life. One of the main ways I do so is by keeping the screen on its dimmest setting when I’m indoors.

But my tablet has an odd quirk: when it alerts me that the battery level has reached critical, it simultaneously adjusts the screen brightness to the highest setting! At the very point when my tablet most needs to conserve battery power, the tablet changes my setting to drain the battery even more quickly.

Was this intentional? I doubt it. I can’t imagine a developer coding a battery alert to include a power drain. So it was probably caused by a unexpected line of code somewhere. But once again, it points to the importance of testing designs in realistic scenarios to make sure they work as expected and are free of glitches. User testing adds to the cost of the project; but failing to do user testing costs even more.

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.

Design Bloopers #1 — Email Attachments

Lately I’ve had reason to ask, “Is it just really hard to design a good user experience when saving email attachments?” Here’s how the process works on AOL:

  1. I receive an email with an attachment. At the bottom is a Download button, so I click it and download the attachment.
  2. I also want to save the text of the email to my hard drive, so I click Save. I get the following dialog box:

  3. Okay, it would have been nice if they realized that I just downloaded the attachment. Or maybe I really didn’t— otherwise, why would they be asking me again?

    So I click Yes and get this dialog box:

    It’s not just AOL. The other day at work I received an attachment in Outlook. I opened the document and made some changes, then tried to close the email.

    “Do you want to save the attachment?” Outlook asked me. I clicked Yes.

    Responded Outlook: “You cannot save this attachment because it is read-only.”

    Humor aside, the issue isn’t that it’s hard to design a good user experience for email attachments. The issue is that user observation or testing can prevent design failures like these, along with an illogical and even frustrating user experience.