- What not to cut
- Find what’s core
- Kill lame features
- What if the user…?
- But our customers want it
- Features that trigger errors
- Errors
- When features don’t matter
- Will it hurt?
- Prioritizing features
- Load
- Decisions
- Distractions
- Smart defaults
- Options and preferences
- When one option is too many
- Visual clutter
- Removing words
- Simplifying sentences
- Conversation
- Cutting time
- Removing too much
- You can do it
- Focus
This chapter is from the book
This chapter is from the book
This chapter is from the book
Kill lame features
It’s often a good idea to get rid of poorly implemented features. While he was Head of Online at TUI Ski, David Jarvis recalls that one of the websites he managed had features that let users filter search results and create shortlists. He says:
Neither was implemented particularly well. Although both filtering and shortlisting are features we thought should have been part of the functionality, and although we’d got something that was kind of working, we felt we were giving people a half-baked experience. We took the features off the UK site and our conversion rate went up.
One objection to removing half-baked features or content is that the time and effort that has gone into creating them will be wasted. No matter how poor the item, if it’s been paid for, no one wants to get rid of what they have. In the words of Jack Moffett, “Broken gets fixed. Shoddy lasts forever.”
Economists call this the “sunk costs fallacy.” In reality, the cost of creating the feature can’t be recovered, so the only way to judge the feature is on how much good it is doing and how much more it will cost to keep.
Features and content always place a mental load on users (“Do I look at this or not?”) and always cost something to maintain (someone will have to keep the content up to date or make sure the feature still works).
In other words, features always have a price to you and your users. They should add value. If they’re broken, deliver half of the answer, or duplicate functionality from elsewhere, then that value is diminished.
The question is never, “Why should we get rid of it?” It is always, “Why should we keep it?”
One reason to keep something: I’d take a poorly implemented safety feature over no safety feature. But fixing shoddy safety features should be a high priority.
Hanging on to features “because getting rid of them would be a waste” may be holding you back.
We tend to keep things, even when we know they’re broken.
