Applications have a natural tendency to grow. If you don’t pay attention, what started out as an elegant, simple application that perfectly solves a single problem, can quickly turn into a huge behemoth of an application that solves a ton of problems, but solves all of them poorly. Features are always more complex than you think, and many small features quickly add up to one large mess.
This is the kind of application you want:
If you are not careful, this1 is the kind of application you will end up with:
Constant vigilance is the price you pay for an elegant application.
This means you have to learn to say «no». Your current customers will ask you for a feature they want. Potential customers will tell you that if you add just one specific feature, they’ll buy the app. You can’t be everything for everyone. You have to let some people be customers of your competitors.
Kathy Sierra puts it like this:
Each of our books, for example, covers fewer topics than its closest competitors. Yet we outsell all of them, and part of that is precisely because we cover less. Our readers learn fewer topics, but nail the important ones, and it turned out that for most people, nailing it was more important than reading it. Our readers put their trust in us to work hard at finding and focusing on what really matters, and brutally cutting the cognitive overload that comes with the rest, and we try not to let them down.
Be brave. And besides, continuing to pile on new features eventually leads to an endless downhill slide toward poor usability and maintenance. A negative spiral of incremental improvements. Fighting and clawing for market share by competing solely on features is an unhealthy, unsustainable, and unfun way to live.
Steven Frank points out:
Since the days of the Apple ][, C64, and Atari 400, all we’ve done is add, add, add. Add more features to sell more computers. We’ve never stopped to take anything away.
You may be thinking that you’re creating a product for power users, so it’s okay to just keep adding features, because people will figure it out. But it’s not okay. Brent Simmons writes:
Here’s the thing about the power users and developers I know: they use a lot of apps. They manage a lot of complexity already. They often have a few powerful apps (Xcode, Photoshop, Final Cut, Excel, whatever) that they use to get their work done.
They’re not sitting around wishing for more complexity. Quite the opposite! But they do wish that some apps fit them better. And in many cases they wish for less complexity.
Of course, if you do ask power users what they want, and then implement every feature they can come up with, you’ll end up with this:
So saying no is good for you, and good for your customers.
But what if you’ve already said yes?
Eventually, you will find yourself in a position where your application contains features it should not. Even if you’ve been vigilant, this will happen. There are various reasons.
Technology Becomes Outdated
When you wrote your application, it made perfect sense to add support for FTP syncing, add a Java bridge or refactor your application to be an OpenDoc container. But the world changes, and a year or two later, what looked like a good idea at the time has now become useless, has turned out to cause huge support problems, or has turned out to be unreliable. Or perhaps most people simply didn’t care, and the feature has made the application more complex without helping anyone.
It Was Free
If your backend supports a feature, it’s often tempting to implement it, because to you, it’s essentially free. Months later, you will find out that while it didn’t cost you anything, it wasn’t free to your users. They now have to deal with a feature they may not care about, and all it does is get in their way. Jason Alderman provides an example:
Our devs whipped up a framework early on that supports categories, subcategories, AND tagging. (…) Tags just adds a layer of complexity to so many screens of the UI, that it’s hard to design a good, consistent user experience.
If the work already went into implementing a feature, it’s hard to argue that it should not be exposed to users. Even if you’re the only one working on the project, the sunk cost fallacy may have tempted you to expose a useless or potentially harmful feature in your user interface.
Mistakes Were Made
It happens. Perhaps it’s a feature the CEO wanted, and there was no way to say «no». Perhaps the people responsible just didn’t think it through.
You’re Creating a Simpler Version
It’s also possible that your application is great as it is, but that there is demand for a simpler version. Maybe you’re creating an iPad version of your desktop app and need to decide which features are not going to make it, or you’re trying to create a new consumer application out of your existing pro application.
What Now?
Regardless of how you got there, eventually you’ll be in a position where you have features in your application that don’t really (or really don’t) belong there. The most obvious solution is to simply keep them. Sometimes, this is a valid solution. Perhaps the features work, they are easy to support, and they don’t bother the people who don’t need them. In that case, it may be okay to just leave them in.
But a more likely scenario is that it’s not okay. Outdated features that most of your users don’t care about are broken windows of user experience design. John Gruber explains the «broken windows» theory:
It’s similar to the «broken windows» theory of urban decay, which holds that if a single window is left unrepaired in a building, in fairly short order, the remaining windows in the building will be broken. Fixing windows as soon as they are broken sends a message: that vandalism will not be tolerated. But not fixing windows also sends a message: that vandalism is acceptable. Worse, once a problem such as vandalism starts, if left unchecked, it flourishes.
If you leave features in your application just because half a dozen people actually use them, you’ll end up with Microsoft Word. Most people only use a small percentage of all features in Word. Unfortunately, most people use a different small percentage of all features in Word. Even the most unpopular, most broken feature is used by somebody. Nadyne Richmond, a user experience researcher in the Macintosh Business Unit at Microsoft, explains it like this:
There are people who insist that Word 5.1 was the pinnacle of word processors, and everything that has been done since then has been nothing more than bloat. They tell us that we should update it to run under OS X (and now they want it as a Universal Binary). Oh, but while we’re in there updating the code, could we please add their ten favourite features? As the ever-insightful Rick [Schaut] points out, ‘by the time you add up all the «Plus’s» you come to something that’s not all that far away from Word 2004, which is how we got here in the first place’.
Presumably, somebody needed Word 5.1 «Plus Web Search», so Microsoft went ahead and added the feature:
To me, this is a cautionary tale. Perhaps Microsoft is in a position where they absolutely have to «add up all the Plus’s»2. But you’re not. You don’t have to try to please everybody and eventually create an application that is liked by nobody. In fact, since your users are in all likelihood in a situation where they can switch applications easily, and since they probably are not locked in by the need to open a specific file format in its native application, it might be a really bad idea for you to go down the «simply add up all the requested features» route of application design.
So eventually, the best course of action is to get rid of some features that just don’t work out anymore.
So how do you go about it without causing a revolt amongst your users? Here are some ideas.
Get Usage Data.
Let your users opt in to sending you usage data.
This is probably the best solution, since it removes the «human factor». People often don’t consciously know how exactly they use an application. Getting objective usage data helps you figure out which features to cut.
If you can’t get objective data, the second-best solution is to ask. Manton Reece has an interesting blog post explaining how he asked his users for this type of feedback. In a follow-up, he writes about his eventual decision:
I eventually did remove a feature, and the survey to customers served as a nice sanity check that the feature wasn’t heavily used. The interesting part, to me, is that the feature I removed was the entire 1.0 product for Wii Transfer. Literally everything that 1.0 did is now gone.
It’s been two weeks so far without any complaints. I like to think that it removes a distraction from the app — one less place in the app that could lead the customer down the wrong path
Inform Your Users About Your Plans. Be Transparent.
Before removing features, tell your users that you plan to do so, and why you’ve decided to remove features. Brent Simmons shows how this is done. He writes:
So one thing I like doing is getting as much feedback on the possibly-to-delete list as I can. I don’t put things up to a vote, because a vote doesn’t tell me the why of anything, and that matters more than just numbers.
I’ve learned a few specific things in the past few hours that I didn’t know: for instance, that people actually do use the HTML Archive feature. That people don’t use the automatic enclosure downloading feature very much, but they do like the possibility of manual downloading. (I didn’t, and don’t, intend to remove manual downloading of enclosures.)
There’s also a great blog post by Adobe’s John Nack, where he explains why removing features is a good idea, and lists a number of features Adobe was going to remove from Photoshop.
Provide Alternative Solutions.
When the people at Bohemian Coding removed the bitmap features from their application DrawIt, they contacted Flying Meat’s Gus Mueller. They were able to work out a deal, and every DrawIt customer got a free copy of Flying Meat’s image editor Acorn.
Keep the Old Version Available (For a Time).
When Apple rewrote iMovie, they kept the older, more feature-complete version of the application online until they felt that the new version was mature enough, thus giving people who were not satisfied with the update a way to keep using the old version, at least for a time. This allowed Apple to add features users needed, and it allowed users to take their time getting comfortable with the update.
Do What You Have to Do. Suck It Up.
Despite of the generous offer of giving Acorn to each owner of DrawIt, Bohemian Coding’s Pieter Omvlee writes that reaction was not entirely positive:
The feedback I got was mixed. Some people were happy with the improvements I made to the vector part in the same update and said they never used the bitmap part anyway. Some complained because they only used the bitmap part, but I could point them to Acorn. Lastly, I received some complaints from people who really liked the combination of both vector and bitmap in one app. Fortunately, only very few people felt that way. In general, it all went well, and I think that’s for a big part thanks to Gus Mueller’s generous offer.
You can’t please all of the people all of the time. Sometimes, you have to make a few people really unhappy in order to make everyone else a little bit happier. Don’t let angry customers dictate your application design - the application isn’t as important to them as it is to you. Keeping your application healthy is your responsibility.
Your customers can switch to a different application if they don’t like yours anymore. You can’t. Your customers don’t know how hard it is to support a feature. You do. Your customers don’t know how popular a feature really is. You probably have a pretty good idea. Your customers likely don’t even really know what features they want, even if they tell you that they do. It’s your job to figure out how to grow - or shrink - your application properly and responsibly. It’s your job to make the hard decisions and cut the features that did not work out.
Conclusion
As a programmer or designer, it’s easy to become a bit too invested in your application’s feature set; accepting that something you’ve put a lot of work in needs to be changed or removed can be hard. But sometimes, it has to be done, and if done carefully, most of your users will appreciate your decision.
Update
Nadyne Richmond has written an answer to this post. She writes:
Using usage data to decide which features to cut is fundamentally flawed. Usage data doesn’t tell you why a feature isn’t used. (…) There are plenty of reasons that a feature might not get used, and removing the feature is not the only solution to the low-usage problem.
(…)
Usage data is directional. It doesn’t tell you what action to take, it tells you that there might be an action to take.
This is absolutely true, of course. The fact that few people use a feature does not necessarily mean that the feature is useless. I’m not advocating mindlessly removing all features that get little use. However, I do think that low usage is a very strong indicator of an unnecessary feature. After all, if the feature were truly useful, a sizable number of your users would likely figure out how to use it even if it was implemented poorly.
Further Reading
I want to thank everyone who helped write this article. Pieter Omvlee from Bohemian Coding, Max Steenbergen who provided awesome feedback on an earlier draft, Jason Alderman, Fabien Marry, Thibaut Sailly, Henning Hoefer, and Andreas Hartl.
Loading Articles...
