- 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
Solutions, not processes
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 towards.
When I started to design the process, things quickly became complicated. For instance, when a customer added money into a savings account, he would need to add the money, and then move it into a pot—two steps instead of one. When someone else added money into the account they might not know about the pots and 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.
This kind of feature—one that leads to a flood of exceptions and details—always sets my alarm bells ringing.
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 focusing on process, 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?”
)