• By Everett McKay on November 30th, 2010
  • Getting from good UX to great UX

Courageous Design

On November 6, 2010, I gave the Keynote at Design Camp Boston/New England UX entitled Courageous Design: Why great design requires intelligent risks.

Here’s a synopsis:

While you can design a good user experience by playing it safe, creating a great design often requires the courage to take intelligent risks. In this keynote, Everett McKay explores courageous design and how courage affects making decisions through consensus and the use of data, asking questions in UI, simplicity, software personality, and, most importantly, team culture. As Everett says, “You can measure the greatness of a user experience by the courage required to design it.”

Here’s a rerecording of the Keynote:

Here’s a link to the Courageous Design slide deck.

While I felt good about the Keynote and received a lot of generous, supportive feedback afterward, I felt great about it after seeing Casey McKinnon’s Building a User-Centric Company because it could have easily been retitled “FreshBooks: Why everything Everett just said really does work.” Loved it! If you didn’t see Casey’s presentation, I strongly recommend taking a look.

I’m definitely interested in giving this presentations (or variations) at companies and other conferences. If you are interested, please contact me.

The cost of unnecessary features

Suppose you have an idea for a command, option, or mode. You’re not sure if your users really need it but there’s a small chance that it might have value (a solution looking for a problem, but still…), so you’re reluctant to cut it. You think: What could be the harm?

An example

So, what could be the harm? Before I answer, consider this story:

I’ve been doing a lot of video recording lately, and have been using the Audio Technica ATR-6550 microphone. Before I bought it, I watched an Amazon video customer review, where the reviewer strongly recommended the Tele setting over the Normal setting. In fact, the reviewer said “don’t even use the Normal setting because I just don’t think it works.” After getting the mic, my testing confirmed that Tele was definitely the way to go and that—despite its name—I should never use Normal. The setting is made with a small slider switch. The settings are Off, Normal, and Tele.

Today, after recording for about 2 hours, I went to turn the mic off. As I was turning it off, I realized that I was sliding the switch in the wrong direction but still I unexpectedly heard a click. Yup, I mistakenly had the mic in the Normal setting for 2 hours without realizing it. While recording, there’s obvious feedback that the mic is off, but there’s no obvious feedback about its mode.

The mic would be a much better product by eliminating the Normal mode and having a simple, foolproof on/off switch. I haven’t checked the results yet, but worst case I just wasted two hours because of this questionable feature.

All features have a cost, but unnecessary ones aren’t worth it

So, what’s the harm in having unnecessary features? There’s a cost for you the developer:

  • Direct costs to design, implement, test, document, and support.
  • Opportunity costs of not spending your limited resources on something else more worthwhile.

But more importantly, there’s a cost to users who have to:

  • Discover Know that the feature exists. The more features there are, the harder discovery becomes.
  • Distinguish Recognize the difference between the desired and undesired results.
  • Learn Learn when to use or not use the feature.
  • Decide Every time users perform an interaction that involves the feature, they have to choose not to use it. This ultimately makes all interactions more difficult, even if the feature is never actually used intentionally.
  • Confuse Over time, users will forget the distinction, use the undesired feature by accident, and have to recognize, recall, and correct the problem.
  • Avoid If users get confused too many times, they will have to learn to an extra step to avoid the feature in the future.

The insight here is that all features have a cost—to you and to your users—even if never used. Good features are well worth their cost, but questionable features are not.

Examples of unnecessary features

It’s easy to find rarely used features, but it’s more challenging to find features that I never intentionally use. In addition to my mic’s Normal setting, here’s my list so far:

  • The Panic button on my car remotes I have yet to press a Panic button intentionally. While pressing the Panic button does in fact cause panic, causing panic isn’t its intended purpose.
  • Car “auto” power windows Having my driver’s side window go all the way down on one touch is never what I want. Whatever the scenarios are for this feature, I don’t have them.
  • Non-automobile GPS modes when driving my car I was baffled when my GPS started acting strangely, avoiding freeways and giving crazy high time estimates. You’d think a GPS would recognize when you are driving instead of walking.
  • Caps Lock, Ins keys I’ve never used these keys on purpose and never expect to. Caps Locks should be documented as the “type in the wrong case” key. For me, this feature has 100% failure rate.
  • The Windows scroll wheel button Clicking this button displays that up/down arrow in a circle, and puts Windows into a crazy, unusable scroll mode. A potentially good idea, but the mechanics are so poor that I never do this intentionally.
  • Windows AutoPlay dialog For me, the correct answer is always Open Folder to View Files. Even if I really wanted to do something else, I’d rather do it from somewhere else. Using this dialog requires more thought and effort than it deserves.
  • The majority of the buttons on the majority of my remote controls. I’ve got several remotes with 30+ buttons where I only use about 6. I have a Sony TV with a great solution: one remote with all the buttons and another with the few buttons I’m actually going to use.

This list is just a start. I’ll add to it over time. Feel free to mention your personal favorites in the comments.

Some solutions

If a feature never makes sense, do your users a favor and just get rid of it. I think having a keyboard without Caps Lock would be a major breakthrough. But to make it interesting, suppose you have a useful, but rarely used feature that you just can’t cut. Consider using one of the following:

  • Make it intentionally hard to find and use. Progressive disclosure and intentional affordance are great ways to do this. I wouldn’t mind the Normal setting on my mic if I didn’t have to worry about using it accidentally.
  • Learn from context. If an option is impossible in the current context, remove it automatically from that context.
  • Learn from user behavior. If you offer a questionable option 10 times and the user never goes for it, get a clue and stop offering. If later users discover that they really need it, let them go out of their way to get it.

But we don’t know what users are going to want or do

This is a classic excuse, but I don’t buy it. You should know. Use scenario-based design instead of features-based design, and make sure your features really are justified by the scenarios. Gather metrics to find out what people are really doing. And if the feature is in fact rarely needed or used, use some design courage and either cut or hide it (using the previously mentioned techniques).

  • By Everett McKay on November 22nd, 2010
  • Quizzes and interview questions

UX Design Trivia Quiz #1

Which of the following common household items has had an extraordinary influence in modern consumer electronics design?

  1. The portable radio
  2. The toilet
  3. The light switch
  4. The remote control
  5. The toothbrush

Give up? Here’s the answer.


Suppose a car alarm goes off in a parking garage. Do you:

  1. Call the police and inform them that there’s a burglary in progress.
  2. Check the car to see if there is anything wrong.
  3. Ignore it completely and hope it stops soon.
  4. Go somewhere else to avoid the noise.

It’s pretty much a sure thing that you won’t do options 1 or 2. Why? Because you’ve learned from experience that it’s almost certainly a false alarm. You’ve probably never seen a car alarm go off that wasn’t a false alarm.

A trustworthy user experience (TUX) earns the user’s trust so that they are willing to rely upon and take risks with it. By contrast, an experience that fails to earn the user’s trust SUX (where you can provide your own “s”).

Let’s change this scenario slightly to make it a bit more interesting. Suppose the built-in CO detector near your bedrooms goes off in the middle of the night. Do you:

  1. Evacuate your family to safety.
  2. Call your heating guy to fix the problem.
  3. Inspect your home for gas leaks.
  4. Turn the damn thing off and go back to bed.
  5. Ignore it and have your family die of carbon monoxide poisoning.

The first time this happened to me, I did both options 1 and 2. It was a false alarm—the unit had failed and needed to be replaced. (And BTW, having the heating guy verify that it was false plus having the home security guy replace the defective unit cost me a small fortune.)

This happened a second time just recently. This time, I did options 3 and 4. The awful dilemma here is that it’s very difficult for a homeowner to be absolutely sure that option 4 isn’t really option 5. Fortunately, I had a spare plugin CO detector, so I was able to verify that things were safe. Again, it turned out to be a false alarm—the power supply to the built-in unit had died and needed to be replaced.

What both scenarios have in common is that they require trust, but both failed to earn it because false alarms are so much more common than real ones, nor are they easily distinguishable.

Is there a solution?

Yes, there’s a simple solution: The key is to earn the user’s trust by providing specific information. With a poorly designed CO detector, all failure states have the same results: the alarm going off. With a well designed CO detector, the unit earns the user’s trust by providing specific, easy-to-differentiate information—the amount of CO detected, a low power indicator, a general failure indicator, etc. With this specific information, the user can check the status and make an informed decision on what action to take. Those CO units with the status displays—or any other type of alarm system with specific status—are well worth the extra money.

UI is Communication

I just completed a New York road trip where I presented UI is Communication to the Central New York .Net Developer Group in Syracuse on August 11th and the Tech Valley .Net Users Group in Albany on August 12th. These presentations had a great turnout (about 30 people each), with excellent audience participation and supportive feedback. I’ve very pleased by how they went. Many thanks to Griff Townsend, Andy Beaulieu, and Jim O’Neil for making this happen.

Here is a brief summary of the UI is Communication concept:

  • UI design is ultimately all about communicating to users, both in terms of what you say and how you say it
  • If you can explain how to perform a task to someone in person in a way that’s clear and concise, you can apply those same communication techniques in a UI
  • We should have the same standards for software interaction as we do for human interaction
  • Focusing on communication is the simplest way to develop design thinking and focus on user goals

Consequently, focusing on communication is a great way for non-designers to get started in UI design.

I’m interested in presenting UI is Communication to other groups, especially to those within driving distance (New England, New York, Pennsylvania, Montreal, Ottawa) as well as places that I often travel to (Washington DC, Seattle, California, Florida). If you’re interested, please contact me.

For more information, please contact info@uxdesignedge.com

All Content Copyright © UX Design Edge