Archive for the ‘Design principles’ Category

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).


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.

Intuitive UI: What the heck is it?

For any UX project, it’s almost a sure thing that a top goal is to have an “intuitive UI.” To users, describing a UI as intuitive is among the highest praise they can bestow. Given this, it’s reasonable to ask what it means for a UI to be intuitive. Surprisingly, nobody really knows. Ironically, people’s definition of intuitive is, well, intuitive, as they struggle to define the term in a specific, meaningful way. (Other popular UI goals share this problem, “simple,” “easy to use,” and “clean” being runners up.)

A practical question: How can you achieve a project goal if you don’t even know what it is?

My practical answer: You can’t. The term “intuitive” is meaningless as a UI characteristic, so—with the exception of casual conversation—we should avoid using it, at least without prior definition.

Struggling for a definition

I used to work at Microsoft and as a Microsoft employee, it wasn’t uncommon for people to tell me (with a certain glee) that, they, unfortunately, prefer using a Mac. While I primarily use PCs, I too have a Mac and have had a current model for decades. I like the Mac and appreciate its advantages (along with its disadvantages), but knowing that my lack of disapproval would be disappointing, I always keep that detail to myself. Everyone assumes Microsoft employees hate Macs.

From this point, the conversations have been remarkably consistent. My response: “Really, why is that?” To this their response is consistent and immediate: “I find the Mac much more intuitive.” My response: “Interesting—could you give me some specific examples of how it is more intuitive?” With this question, their glee turns to shock and horror as if to say “Of course, the Mac is more intuitive—how dare you question that!”  From this point, they would struggle to come up with some sort of answer, ranging from “it just is” to “it just works” to “it’s simpler” to “Mac apps have a more consistent look and feel.”

Sure, there’s an element of “intuitiveness” in those responses, but there is no clear, consistent definition. Sans the reality distortion field, in practice intuitive just means better. But going back to our UX project, imagine a project goal being a “better UI.”  An equally useless as a goal, just more obviously so.

A dictionary definition

Starting with the definition of intuition from Wikipedia, I’ll say that the “dictionary definition” of intuitive is:

A UI is intuitive when users understand its behavior and effect without use of reason, experimentation, assistance, or special training.

For such intuition to be possible requires prior knowledge, either from experience in the real world or with other software. So, for example, if something looks like a push button, we know from the real world that we can click on it to make something happen. Alternatively, if something looks like a link, we know we click on it from experience with other software.

We can boil this definition down to two requirements: affordance and consistency, where affordance allows us to predict what is going to happen based on appearance, and consistency to make that prediction correct. Labeling and context are also factors in making the prediction.

So is intuitive just a fancy word for affordance, consistency, and predictability? It could be, but when people use the term, I think they have more in mind.

Everett’s definition

I like to define things, so I’ll take a crack at it. A UI is intuitive when it has an appropriate combination of:

  • Affordance Visually, the UI has clues that indicate what it is going to do. Users don’t have to experiment or deduce the interaction. The affordances are based on real-world experiences or standard UI conventions.
  • Expectation Functionally, the UI delivers the expected, predictable results, with no surprises. Users don’t have to experiment or deduce the effect. The expectations are based on labels, real-world experiences, or standard UI conventions.
  • Efficiency The UI enables users to perform an action with a minimum amount of effort. If the intention is clear, the UI delivers the expected results the first time so that users don’t have to repeat the action (perhaps with variations) to get what they want.
  • Responsiveness The UI gives clear, immediate feedback to indicate that the action is happening, and was either successful or unsuccessful.
  • Forgiveness If users make a mistake, either the right thing happens anyway or they can fix or undo the action with ease.
  • Explorability Users can navigate throughout the UI without fear of penalty or unintended consequences, or of getting lost.
  • No frustration Emotionally, users are satisfied with the interaction.

Of these elements, the first two reflect the dictionary definition, and the others are those extra attributes that go beyond the literal definition.

Achieving your goals

If your goal is an “intuitive” UI, I think it’s best to explicitly spell out exactly what you want using the above attributes. Don’t use the term in specs, proposals, or plans unless you define the term in detail beforehand. When evaluating a UI, always do it in terms of the specifics. Otherwise, intuitive will end up being a vague synonym for good instead. That’s at best. The world’s most confusing UI could be credibly described by its creators as intuitive as long as the term isn’t defined specifically.

If you do only one thing:
Don’t use the term intuitive to describe a UI without a definition because nobody understands what it means. Instead, define the term specifically in your documents or describe your goals using more specific terms.

A footnote

I’ve got 80+ UI books in my library, but only two bothered to define the term. In The Humane Interface, Jef Raskin defines intuitive as familiar. I prefer consistent though because it is more specific and actionable. In Software for Use, Larry Constantine and Lucy Lockwood define it as guessable and behaving as expected.

Effective software branding

Branding is the emotional positioning of your product and company as perceived by your customers. Product branding is achieved through a combination of factors, including the product name and logo, use of color, text, graphics, and sound, the style of various other design elements, marketing, and most importantly, the attributes of the product experience itself. Branding is used to differentiate a product from its competition.

Historically, the term branding came from cattle branding, where ranchers burned their mark onto their cattle hides for easy identification.  Samuel Maverick famously refused to brand his cattle on the grounds that it was painful for the animals, but his competitors believed that was just a ploy for him to claim any unmarked cattle.

I wrote a solid guidelines article on Software Branding while I was at Microsoft, so there’s no need to repeat any of that here. For this post, I’d like to look at some examples of effective and ineffective branding.

Hilton Garden Inn

I recently drove across the country and stayed at a Hilton Garden Inn at each stop. I was very pleased with this choice. Here are the details I like about Hilton Garden Inn:

  • The hotels have an inviting lobby with a fireplace and free coffee, cookies, newspapers.
  • There is always a pool, spa, and exercise room.
  • The rooms are new, clean, well appointed, and stylish.
  • The rooms always have a comfortable bed, a good TV, a desk, and a comfortable desk chair.
  • The hotel offers a good breakfast that is a quick, convenient, and fairly priced.
  • The rooms a priced competitively and are a good value.
  • The hotels and rooms vary from property to property (so they aren’t cookie cutter), but are consistent enough to always meet my expectations.

In short, the Hilton Garden Inn brand is clean, comfortable, well appointed rooms for a good value. Now you might be thinking: Wait, that’s not the hotel’s branding, that’s the hotel properties themselves.


When done well, a product’s banding is completely reflected by the product itself. Branding isn’t something superficial that you tack on to a product. This is a mistake many developers make and as a result, “brand” their product by slapping the product name and logo on every UI surface. Bigger logos does not make better branding. While those elements affect users’ ability to identify your product, they are just the superficial part of branding.

Google user experience principles

Google has published their Ten principles that contribute to a Googley user experience, which are:

  • Focus on people–their lives, their work, their dreams
  • Every millisecond counts
  • Simplicity is powerful
  • Engage beginners and attract experts
  • Dare to innovate
  • Design for the world
  • Plan for today’s and tomorrow’s business
  • Delight the eye without distracting the mind
  • Be worthy of people’s trust
  • Add a human touch

This is a good set of principles and I recommend reading the original article. If you read them carefully, you’ll notice that these principles are really Google’s branding statement. And a very specific, actionable one at that. I can see how a team could apply these principles in a design review to make better design decisions. Contrast that with the vague laundry list of adjectives so often using in branding.

Windows 7 branding details

Effective branding creates a positive image of your product or company in the user’s mind. Generally, this means you should avoid associating your brand with any experiences that are unwanted, unpleasant, or annoying. Consider rare exceptions only when your product addresses those situations in a way that is significantly better than the competition. For example, Volvo associates their brand with safety and how their cars score favorably in safety tests, but they don’t dwell on crashes.

The User Account Control (UAC) feature in Windows 7 isn’t an especially popular and the Windows team wanted to avoid associating security problems with their branding. The standard Windows security shield has the Windows branding colors, so Windows 7 uses a special blue and yellow UAC shield to not associate this feature with the Windows brand. This is a smart move.

For a not-so-smart move, Windows 7 dialog boxes flash rapidly seven times when a program needs your attention. Flashing rapidly seven times goes well beyond annoying—even four times would too many. I’m sure this was intended to be a clever branding detail (Windows 7…flashing seven times…get it?), but this is not a good way to brand. This idea should have never seen the light of day.

If you do only one thing:
Establish clear, actionable branding principles. (Of course, work with your branding pros if you have them.) Use your branding principles as a design decision making framework and make sure that your design decisions are consistent with your branding.

If your branding principles don’t affect your design decisions, you’re not doing it right.

Accidental manipulation and intentional affordance

In my post Getting started in interaction design, I recommend that you pay attention to design and learn to appreciate good design. I had a chance to do both last weekend. I was at Stowe Mountain Lodge, my favorite resort in Vermont, and noticed that the controls on their Technogym exercise equipment were particularly well designed. To appreciate why, I’d like to start by explaining a significant problem with direct manipulation, and give a couple examples of direct manipulations that aren’t so well designed.

Direct manipulation

Direct manipulation is a crucial ingredient of a modern UX. Direct manipulation is the ability for users to perform a task on an object instead of indirectly through some intermediary. For example, moving a window using a Move Window menu command is indirect manipulation, whereas dragging a window into position is direct. Traditionally we have used a mouse to perform manipulation, but touch-based interfaces feel more direct because there’s nothing between users and the object being manipulated.

Accidental manipulation

But there’s a problem: where there is direct manipulation, there is accidental manipulation. There’s always a chance that the user performed an action either entirely by accident, or performed the wrong operation or acted on the wrong object.  The potential for accidental manipulation is large enough that critical operations shouldn’t be performed without confirmation. (Hmm…did I just drag the North American domain to Fiji?) But note that generally, combining direct manipulations with confirmations is a poor idea because confirmations destroy the very directness you are after.

Touch-based UIs are especially prone to accidental manipulation. This is why a swipe motion (with very little margin for error) is used to initiate interaction with an iPhone—a correctly performed swipe indicates with high probability that the input is intentional.

Well designed direct manipulation must minimize the likelihood of accidental manipulation. Failing to do so will make the design annoying at best and disaster prone at worst.

Bad example: My Miele vacuum

My Miele vacuum is an example of a design that fails to consider accidental manipulation.

Take a look at the handle, and notice the bypass device at the top. Not obvious from the photo is that the bypass device slides open with minimal resistance. Where do you think your thumb will naturally go? When vacuuming, what motion will you naturally make? Guess what happens—constantly—when you naturally use the device as intended.

This vacuum is frustrating to use because I’m constantly opening the bypass without realizing it. The feedback isn’t as obvious as you might think—the vacuum doesn’t work well and sounds louder and eventually you realize that you’ve opened the bypass and wonder how you managed to open it yet again.

Talk about not getting the proper amount of suction.

Another example: Windows 7 Aero Snap

To take a software example, this extremely heavily promoted feature allows you to quickly view two windows side by side by dragging them to their respective sides of the screen. (Snarky comment: from the advertising, you’d swear that this was the most useful thing you could do with a computer.)

Unfortunately, this feature wasn’t designed to prevent accidental manipulation. If you don’t want a window to snap, it’s very difficult to persuade Windows otherwise once you get in Snap’s gravitational field. (“Aero Shake” cancels a snap, but shaking isn’t easy to do and it’s difficult to discover.)

Aero Snap works extremely well better with high resolution, wide-screen monitors, but I find that it’s way too easy to trigger by accident with lower res monitors (like 1024×768). In this case, the accidental snaps happen far more frequently than intentional ones, making the feature a net negative.

This part of Windows 7 wasn’t my idea.

Update (5/11/2011): I finally got fed up and turned off Aero Snap. I find that even on high res monitors, it’s wrong far more often than it’s right. The novelty has long worn off, so it’s just not worth the trouble anymore.

Great example: Technogym

I found that the Technogym level controls are brilliantly designed to prevent accidental manipulation. Here is what the control looks like:

Note how recessed the button is. Here’s how the handle looks when you grab it naturally:

Note how the control lies in the gap between the thumb and the fingers, and how the thumb is naturally away from the control. However, even if you were to slide your thumb around in a variety of positions, you won’t trigger the control accidentally because it is recessed:

But if you do want to change the level, doing so is simple and easy.

The goal is to make it difficult to press the button through casual contact. If you press the button, you almost certainly did so deliberately.

Intentional affordance

I use “intentional affordance” to describe direct manipulation that ensures the interaction is intentional. The challenge is to design simple, natural interactions that are constrained just enough to signal clear intent. The Technogym controls and the iPhone swipe are excellent examples.

If you do only one thing:
Design manipulations that are likely to be performed accidentally to have affordances that require clear, deliberate intent.

The tragedy of great design

The tragedy of great design is that if it is particularly well done, most people won’t even notice it. Their reaction will be “Of course! How could you design it any other way?” I bet most people who used the Technogym controls never gave them a second thought. But the bad examples show that great interaction design happens only when someone designs something carefully and well.

Fixing Aero Snap

As a challenge, design Aero Snap to have intentional affordance. When done, compare your answer to mine.

For more information, please contact

All Content Copyright © UX Design Edge