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?
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.
So, what’s the harm in having unnecessary features? There’s a cost for you the developer:
But more importantly, there’s a cost to users who have to:
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.
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:
This list is just a start. I’ll add to it over time. Feel free to mention your personal favorites in the comments.
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:
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).
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:
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.
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.
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.
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.
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.
I like to define things, so I’ll take a crack at it. A UI is intuitive when it has an appropriate combination of:
Of these elements, the first two reflect the dictionary definition, and the others are those extra attributes that go beyond the literal definition.
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.
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.
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.
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:
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 has published their Ten principles that contribute to a Googley user experience, which are:
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.
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.
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 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.
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.
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.
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.
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.
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 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.
As a challenge, design Aero Snap to have intentional affordance. When done, compare your answer to mine.