“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?
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.