- Remove
- How not to do it
- Focus on whats core
- Kill lame features
- What if the user...?
- But our customers want it
- Solutions, not processes
- When features dont matter
- Will it hurt?
- Prioritizing features
- Load
- Decisions
- Distractions
- Smart defaults
- Options and preferences
- When one option is too many
- Errors
- Visual clutter
- Removing words
- Simplifying sentences
- 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. David Jarvis, Head of Online at TUI Ski, recalls that one of the websites he manages used to have 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 think should be 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).
So the question is never, “Why should we get rid of it?” It is always, “Why should we keep it?”
Hanging on to features “because getting rid of them would be a waste” may be holding you back.
)