Drop Nice-to-Have Features
Almost every mature application in existence contains at least a few features that were probably first described in a statement that started with “Something that would be really nice to have is <insert description here>.” But most of these things are exactly what clutter up interfaces all over the web and on our devices, and it’s our job to fend these things off with a big stick. They need to be removed from your next application before it’s even built. An obvious interface is one that is focused on what’s most important and leaves out the things that are simply nice to have.
In its book Getting Real, 37signals has this to say about focusing on only the important features:
The statement is similar to something Steve Krug said in his book Don’t Make Me Think, one of the greatest books out there on web usability. It’s Krug’s Third Law of Usability:
And Krug’s law can be traced back to William Strunk, Jr., and E. B. White’s The Elements of Style:
Say it again, brother.
All these people are in the business of simplicity. Simplicity makes the point clear. It lets messages stand out. It offers communication that cuts through the noise.
The Unnecessary Test
To create applications that cut through the noise, you have to be willing to slice your application’s feature list down to its bare bones, and you have to recognize what’s most important.
With that in mind, try the following exercise, which I call the Unnecessary Test:
Open an application you’ve worked on recently and find a feature you thought was really important a long time ago, perhaps before you started building the application.
Ask yourself the following questions:
- Is there more than one way to complete the task this feature supports?
- Does this feature contribute directly to the completion of the task?
- Is the task this feature supports vital to the activity this application supports?
If you answered no to any of these questions, the feature may be unnecessary. You’ve found yourself a likely candidate for the cutting room floor.
If, on the other hand, you answered yes to all of these questions, you’re either looking at a rock star feature or you’re not looking hard enough at the feature to be objective. Try your best to detach yourself from all the work you did and ask these questions from a more objective point of view.
Regardless of your answers, it’s likely there are several features in your application that could be scrapped, so you should take the time to go through every feature and run each one through the Unnecessary Test.
When you’re done with the testing, close the application and ask yourself three more questions.
- What are the circumstances of the situation my application is meant to support?
- If this application didn’t exist and I needed to handle the same situation, and I could wave a magic wand to create an application that helped me with this situation with the greatest of ease, what would the application do? (Hint: You should limit this answer to a few very big-picture statements that relate to the principal desired outcome.)
- How long will it take to rebuild my application to make it do that?
Sorry—that last question is a joke (sort of). After all, you’re likely to have answered one of the first two questions in a way that prevents you from having to admit you were wrong. I know—I’ve done this myself. It’s difficult to admit your application may not be living up to its promise.
If this is true, have someone else answer the same set of questions and see if the answers are different. Even better, ask one of your users.
I’m not suggesting you start ripping functionality out of an existing application. Doing this could have the rather negative side effect of making some of your users extremely upset. To the people using the more obscure features, removing them would be a huge mistake. I’m only suggesting you learn from what you’ve already done so you can create more focused applications in the future.
The 60-Second Deadline
Here’s another quick way to learn to effectively aim low and keep your application focused on the 20 percent that matters:
Pretend I’m your boss. I walk into your office and very matter-of-factly state, “The project time line has been cut in half. We have about 60 seconds to decide what to keep and what to throw away before we meet with the client in the conference room.”
How do you respond to this statement?
Whatever you do, don’t impulsively offer up the theoretical answer—the one where you say how much you’d love the low-carb sandwich. Figure out the real answer.
Grab a notepad and a pen, write down the list of features you have planned for an upcoming application, and see what you can cut in 60 seconds. Draw a line through each feature you can cut without completely destroying the application.
The goal is to leave yourself only with what is most essential for the application to serve its purpose.
Show me only the pieces you absolutely have to keep for the tool to do its job.
When you’re done, cut one more feature, just for good measure. Cut the one you’re holding onto only because it’s really cool. C’mon, I know there’s at least one on your original list. Draw a line though it.
Your 60 seconds are up. Good job.
Now, take out a second sheet of paper and write a new list that shows only what you have left, just so you can see it sitting there all nice and clean. Looks much better, doesn’t it? I know, it probably hurts a bit to have lost so much stuff, but I bet your application is now easier to explain.
Finally, take out another sheet of paper and write down the list of things you drew a line through earlier. Title this page “Nice-to-Have Features,” stick it in your filing cabinet, and forget about it. We’ll look at it again later.
The first time you do this, it can be quite revealing. You may find you’ve been wasting a lot of your time and energy on things that don’t really contribute to the application in any meaningful way. Of course, this may be a bit unsettling, but hey, knowing is half the battle. Next time around, you can use the Unnecessary Test and the 60-Second Deadline exercise before you start coding, to see what really needs to be built—and you can spend all your time working to make those things as good as they can be.
And since building what’s most important takes much less time than building what’s not important, you can get more sleep, take more vacations, get more weekends off, and live a happier, healthier life.
Or you could do what I do and use all that saved time to design more applications. I know that’s what you really want to do.
Regardless of how you do it, the ultimate goal is to determine what’s most important to the application by whittling your list of features down to about 20 percent of what was built or what you were planning to build. Yes, some of the remaining 80 percent of your features may be useful somehow, to someone, some of the time, but they are most likely useless to 80 percent of your users, 80 percent of the time. And you probably spent 80 percent of your development time building things that aren’t essential to the application.
This is because the 80-20 rule has made its way into the world of software.
Known formally as the Pareto principle (named for Vilfredo Pareto), the 80-20 rule was originally suggested to indicate that 80 percent of the effects come from 20 percent of the effort.
In terms of good, clean application design, it means that 80 percent of an application’s usefulness comes from 20 percent of its features. It also works the other way around, to illustrate that 20 percent of the development work produces 80 percent of an application. The other 80 percent of the work satisfies only 20 percent of the outcome.
To create more focused applications, stick to building the 20 percent of features that are essential—the ones you’ll stick on the mobile version—and you’ll take care of 80 percent of the user’s needs. Let your competitors worry about the rest. While they’re floundering around trying to one-up you by fleshing out the other 80 percent of the application, you could be taking 80 percent more vacations and enjoying 80 percent of the market share.
Less is more. Aim low.
A job application form I saw once was composed of two windows. One window got the user through the first few screens of the process, and then it launched a second window to complete the bulk of the application. The first window was connected to the user’s log-in session, which was timed and was designed to log out the user automatically if the system remained inactive for 20 minutes. However, the second window was not tied to the session. So, when a user tried to complete the job application in the second window—the part of the process that took the longest amount of time—the system invariably logged the user out after 20 minutes, rudely doing so without any notification whatsoever.
The company’s solution was to add a bit of text in the original window warning users that they would be logged out after 20 minutes—a weak attempt to get their pesky users to stop complaining. This was a band-aid. It did not solve the problem, it just told people what to expect. Users would still have to complete the job application in 20 minutes or less. The company was essentially saying, “Sure, we’ve created a terrible system that will likely terminate your session before you can complete your job application, but hey, we’re warning you before you start, so it’s okay!”
I don’t like band-aids.
Instead of putting band-aids on problems, I perform surgery on them. Interface surgery.
In this first installment of Interface Surgery, we’ll cut out a bunch of unnecessary features from a fictitious web-mail application. Instead of finding ways to make a ton of unnecessary gadgets easier to present and use, we’re going to rip them out and leave only what’s absolutely essential for the application to do its job.
This application has a ton of features. In addition to being able to simply check your email, you can search the web, see how much storage space you’ve used, make sure you’re logged in using a particular user name, reuse saved searches, apply actions (such as set up an automatic response email), move email to other folders you create yourself, configure options for the Inbox (such as font settings), and even change how many messages should be displayed in the list before having to switch to a new page.
Some of these things are necessary, some are not.
To get started, let’s strip out the part of the Search feature that lets users search the web. There are already plenty of ways to search the web, and most modern browsers feature a built-in search bar, making this action accessible 100 percent of the time the user has the browser open. There’s no need to replicate what’s already ubiquitous. And since we’re leaving only the option to search mail, we can remove the two radio buttons and shrink down the space this piece takes up.
Let’s also get rid of the ability to save searches. It’s more difficult to save a search, find it again later, and rerun it than it is to simply reenter a few keywords. This might be nice for some users, but it’s not going to seriously benefit most users, most of the time. And since we’re getting rid of it, we can lose the tabbed interface that displays it. Since the Folders view is now the only option, it no longer needs a label or a tab.
Next, let’s get rid of the percentage indicator that tells users how much storage space has been used up. If we decide this is essential later, we can move it into the Settings screen. There’s no reason to give it a permanent position in the main interface.
Next, let’s get rid of the text that indicates which user is currently logged in. This is unnecessary most of the time, because most users will only ever have a single account, and since they have to manually log themselves in before they can see this screen, it’s pointless to show them something they already know.
Also, let’s kill the option to change how many messages display in the list at once. This can certainly be retained as a feature, but it’s not the kind of thing users are going to use every day, so we can move it to the Settings screen.
And since a Search bar is provided in the left-hand sidebar, we can remove the Search link from the top of the page.
Showing a title bar for which folder is currently being displayed is redundant, because the label for the folder in the sidebar is made larger and bold when that folder is displayed. And if we remove the Folder title bar, we can free up some vertical space for more important content—like mail.
When an email is being displayed, another small bar appears above the email offering Reply, Reply All, Forward, and Delete functions, as well as a way to mark an email as junk.
But there’s already a Delete button in the bar above the message list. If we remove the button and tidy things up a bit, we can consolidate the bar and unify the message options into a single interface element, which means less code, less interface, and less confusion.
Finally, let’s add some logic to the application and have it disable the Reply, Reply All, and Forward links if more than one message is selected at a time. Delete, Junk, and Create Filter can all be applied to multiple messages, so we’ll leave those active. In doing this, we make the message options more functional while still taking up less space.
Ahh, that’s much better. We stripped out a few features, removed a few interface elements, cleaned things up, and came out with an application interface that is easier to understand at a quick glance and easier to use on a daily basis.
We’ll perform interface surgery throughout this book as a way of improving applications one step at a time.
Reevaluate nice-to-have features later
So, when is it time to take the list of nice-to-have features back out of the filing cabinet? The simple answer is this: not one second before your application has been released.
Once your application is out there, being used by real users, and you’ve given it some time to stabilize by fixing a lot of the immediate bugs that have inevitably come up since the release, then it’s time to review the list of nice-to-haves. It’s also time for a good laugh.
What usually happens is that users start to speak up about what they wish your application did, things that bother them, and so on, and no one ever mentions the items on your list of nice-to-haves. Users very quickly form different perspectives on your application than you may have ever had, and since none of them use the application exactly the way you thought they would, the complaints and wish lists that emerge are usually different than what you thought was important.
If this is the case for you, feel free to put that list of nice-to-haves into the other filing cabinet—the one shaped like a trash can—and call it a day. The things we often think are so important at the beginning of a project usually prove to be about as useful as adding another color to a logo. And more often than not, adding them way back when would have meant putting the rock star features at risk by making them harder to find, harder to configure, harder to use.
Let them speak
Once your application is being used out in the wild and you want to hear all the little screaming voices of your users, you need to give them a way to talk to you. This means providing a way for users to offer feedback about your product or talk to others about it, getting out of the way so they can speak freely while you take notes and carefully interpret.
Something as simple as setting up a forum on your site and directing people there from your Support page can dramatically lower your customer-support costs (a forum costs extremely little to maintain), while greatly increasing the amount of information you get from customers.
Note, however, that you will probably not like everything that gets posted. Invariably, there will be some dissatisfied and possibly rude users who scream about your “horrible” application and say nothing constructive, but you have to let this happen. If you moderate user comments to filter out the negative, you’ll defeat the purpose of the forum, which is to hear the complaints. The goal is to feel the pain.
When you allow your users to speak up, you’ll quickly come up with a whole new list of nice-to-haves. Put those in the filing cabinet as well.
Avoid bending to users’ whims if the high-demand features don’t fit into your grand vision for the application. You might try pooling a few beta users together and have them try out a prototype of the proposed functionality to see how it really works before unleashing it to all your customers. There’s no shame in pulling the feature back out if it just doesn’t work. Better now than later.
Focus only on the features that are the most essential. Build only what is absolutely necessary.