It’s not hard to identify things that should not happen when people use the software we build:
- We should not lose customer data.
- We should not lose customer effort (i.e. half-written emails, file drafts).
- We should not share customer data in ways other than what the customer agreed was okay.
- We should not require customers to go through extensive learning to complete a task.
- We should not unexpectedly take away feature functionality or service levels.
- We should not allow customers to accidentally make decisions that will be irreversible and permanently impact their data/assets/experience.
You might think, if your software does not violate any of these guidelines, that you’re okay.
Unfortunately, it’s not enough to play by the letter of the law. You will be judged by your customers’ perceptions of their experience.
Let’s say your web application’s main screen was starting to look very cluttered. You’re worried that this will make it harder to use, so you decide that to build a feature that will archive all data that the customer hasn’t used in a month. The data is still there — you’ve just hidden it behind a link-click. Great idea, right? In alignment with principle #1 — you are not losing customer data.
You release — and customer A logs in to your app. Things have changed… wait, where is my data from the last year?! Customer A is freaked out. He’s not sure he has that info backed up anywhere else.
Is he going to calmly and methodically check the screen for a link that says “Archived Data”? No. He’s going to panic, send customer support an anxious email, and send out angry tweets. Is he going to feel reassured when customer support tells him his data isn’t lost, it’s just behind the Archived Data link? No. Now he feels a little dumb, still frustrated, and residually angry at you.
Think of your “don’ts” as TWO requirements
1) Don’t do it.
2) Make sure your customers KNOW you aren’t doing it.
Some of these you probably already do:
- Asking for a customer’s email address? Explicitly state that “we will never share your email address with third-parties or marketers.”
- Removing a feature but planning to let customers export their old data first? Explicitly state that, in bold, with a clear link to export.
- Need customers to add more data? Explicitly state how much they have to type and estimate how long it will take.
- Changing the UI to hide less-commonly-used items? Explicitly add a “some features have moved, read more here” banner in the place where those features used to be.
- Allowing users to make an irreversible change? Explicitly state the consequences AND add friction so that it’s harder for someone to make a mistake with one click*.
* When I worked on financial apps,”power user” types would frequently complain about the need to re-enter their routing number on a payment or transfer screen. It’s a 9-digit number, and not one that anyone has memorized, so it IS a pain to type in. It is ALSO a situation where an error can lead to very bad consequences (if you are transferring money to make sure your mortgage payment doesn’t bounce, and you enter the wrong routing number, the transfer will fail, your check will bounce…) The two re-entry boxes are annoying; they are also a signal that “hey, you need to slow down, read these numbers carefully, and try hard to not make a mistake.”
This is all a very long-winded way of saying that you should think of customer-facing changes as Murphy’s Law. If anything CAN be perceived poorly, IT WILL. So get a second (or third) pair of eyes, and put on your pessimist hat, and try to catch as many of those bad-perception possibilities as you can — it will save you time and goodwill in the future.