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