- 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
Will it hurt?
Once a feature has been released, someone, somewhere will eventually use it. If users like it, they will change their behavior to take advantage of it. People become addicted to their favorite features, and they will be irritated when one is taken away, no matter how trivial the change.
But some addictions are easier to break than others. What matters most to your users is this: is your design best at solving their big problems? If it is, they will stick with you, even when they’re inconvenienced by your changes.
Judging how much the removal of a feature will affect users is a delicate business. Simply asking people, “Would you like us to remove this feature?” always delivers a resounding “No!” No one likes the thought of getting less. Even people who never have and never will use the feature will want to keep it. The idea of features is often more appealing than the reality.
Instead, begin by assessing how close it is to the users’ core goal.
If you’re designing a mobile application to help salespeople organize their leads, removing a feature that changes the background color won’t hurt: it’s not a core task.
But if the feature is closer to the core of the application, things are a little harder.
Watching people use mock-ups is the best way to find out what really matters and to understand how they will respond.
Trying to please all users all the time is an impossible task. Aim to delight your target audience for their core tasks and hope to please them for the secondary tasks.
)