- 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
Features that trigger errors
When I was working for an online bank, the manager in charge of savings accounts asked me to add a feature that would allow customers to divide their savings accounts into “pots” that they could name (“holiday,” “gas bill,” and so on). This would help customers to become more diligent savers by seeing what they were saving toward.
When I started to design the process, things quickly became complicated. For instance, when a customer added money into a savings account, they would need to add the money and then move it into a pot—two steps instead of one. When someone else added money into that account they might not know about the pots, so the money would need to go in another “general” pot in the account.
It became even more complex when transferring money from the account. The customer had to specify which pot the money should come from. And if the customer transferred too much money from that pot, they might be denied, even if there was enough money in the rest of the account.
When a feature is supposed to work one way but contains lots of exceptions to the rule, it sets off an alarm in my head. Those exceptions lead to confusion and errors.
So I went back to the problem we were trying to address: helping customers remember why they were saving.
I realized that if we allowed customers to name their savings accounts, we’d have a similar effect to naming pots. If customers wanted another pot, they could open another account. We could even start them off with two or three accounts and suggest names for them. Compared to the cost of implementing, explaining, and supporting the pot feature, naming accounts was quick and cheap to implement. And it was far easier for customers to understand.
If you design by trying to make a process work, you’ll often find yourself drawn into creating features to handle exceptions, problems, and details. If you want to remove all this complexity, then step back, focus on the customers’ goals, and ask yourself, “Is there another way to solve this problem?”
)
