Drop Nice-to-Have Features

Almost every application I've ever used has contained 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 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:

Stick to what's truly essential. Good ideas can be tabled. Take whatever you think your product should be and cut it in half. Pare features down until you're left with only the most essential ones. Then do it again.

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:

Get rid of half the words on each page, then get rid of half of what's left.

And Krug's law can be traced back to William Strunk and E. B. White's The Elements of Style:

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.

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 a Web 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 question:

Does this feature contribute directly to the user's ability to complete a task that is vital to the activity this application is meant to support?

If you answered no to this question, the feature can be deemed unnecessary. You've found yourself a likely candidate for the cutting room floor.

If, on the other hand, you answered yes, either you're 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 the question from a more objective point of view.

Regardless of your answer, 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.

1. What is the activity my application is meant to support?

2. If this application didn't exist, and I needed to perform the same activity this application is meant to support, and the world was perfect, and I could wave a magic wand to create an application that helped me complete this activitythe core activitywith the greatest of ease, what would the application do? (Hint: You should limit this answer to three or four very big-picture statements that relate to the principle goal of the activity.)

3. How long would it take to rebuild my application to make it do that?

Sorrythat 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 knowI'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 come out differently. 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 answerthe 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.

Bells? Gone.

Whistles? Gone.

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 builtand 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 build more applications. I know that's what you really want to do.

Less is More

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 Web-based software.

Known formally as the Pareto principle (named for Vilfredo Pareto), the 80-20 rule was originally suggested to indicate that 80 percent of consequences are the result of 20 percent of causes.

In terms of good, clean Web 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 is needed to satisfy only 20 percent of users.

To create more focused applications, stick to building the 20 percent of features that are essential, 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.

Interface Surgery

A Web-based 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 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. 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 minutesa weak attempt to get those 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 OK!"

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-based email application being designed for a fictitious Web-hosting company. 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 plenty of other ways to search the Web, and many modern browsers feature a built-in search bar, making Web search 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 used to display 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 contentlike 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 it 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 cabinetthe one shaped like a trash canand 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. Larger companies typically offer customer-support avenues like email addresses or phone numbers so users can ask questions when they get stuck or complain when they're upset. But there are some lessons to be learned from the world of marketing that might be more valuable.

Seth Godin, author of many best-selling books on the subject of marketing, including The Big Red Fez, is a major advocate of viral marketing on the Web. This basically means providing a way for users to talk about your product and then getting out of the way so they can talk freely. Not only is this a great marketing toolyou're creating a way for your customers to recommend your products to other peoplebut it also provides great insight into what problems customers are having and what they'd like to change or add to the product so you can keep those things on your radar. 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 do nothing but scream about your "horrible" application, saying 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 internal beta users together and have them try out a prototype of the proposed functionality to see how it really works before unleashing it on 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 in the most demand, the ones that are most important.