There was a time in my life before I thought about my child being a cannibal, and there was a time after that.
It was three years ago and my wife and I were at her doctor’s office for a routine checkup during her pregnancy. At one point, her doctor was describing the baby’s growth and I asked a question: “What happens if the mother doesn’t get enough calcium?” It felt to me like a reasonable concern.
The doctor calmly replied, “If that happens, the baby just eats her bones.”
My wife and I thought that was hilarious. (Seriously, who says that?) My next thought though was, “Great design.”
Think about it: The mother’s body somehow knows the baby isn’t getting enough raw materials so it cannibalizes it’s own bone material and sends them to the baby. That’s mind blowing. I challenge anyone to design a better failover solution.
Failure recovery isn’t the sexiest area of product design. Unless you’re working on nuclear reactors or pacemakers or some other product where the consquences of failure are similarly grave, failure recovery features probably aren’t in your product brochure. The fact is though that they’re your customer experience insurance, and they can save perception of your product when things go wrong.
Failure Recovery Design Is Worth the Extra Effort
Usually when we talk about improving product quality we mean reducing the likelihood of failure. Designing the product to handle failures gracefully is part of that too though, and perhaps equally important. External users’ perceptions of software quality are disproportionately affected by even a few bad experiences. Since bugs and unforeseen edge cases are inveitable in software development, it’s wise to plan how to handle them gracefully.
It doesn’t take a full-blown crash or blue screen of death to annoy your users — far less dramatic issues take their toll on user satisfaction too. Make someone refresh the browser page or re-enter data a few times and you’ll see how quickly they sour on a product. That’s all it takes for many users. Everyone’s had smartphones for a while now; their expectations for UX are high. Even for a “high quality” product, preventing those little annoyances can be the difference between them recommending your product or not.
Smoothing out those rough edges takes effort and might slow down new feature delivery a tad, but the good news it’s not rocket science. As much as anything, it’s about treating users courteously when the product screws up.
Be Courteous to Your Users
What do I mean by designing an app to be “courteous?” In a nutshell, it’s anticipating what users need when they encounter things they don’t like. If you need help building your list of what users don’t like, this should get you started:
- Being stuck
- Losing their work
- Not knowing what to do
- Being unsure whether an action completed successfully
- Getting vague or circular error messages
- Having to refresh the browser
- Having to repeatedly find your place on a page because the scroll isn’t sticky
- Not being able to navigate elsewhere during long-running processes
- Lacking an “undo” feature when they need one
- Waiting for objects to re-load over and over because they aren’t cached properly
Anticipating their needs when they encounter these unpleasant states requires putting yourself in your users’ shoes: When the user encounters problem x, what will they need to do next? Whether it’s confirm their transaction completed, reload a form, return home, log a help ticket, or whatever — try to do it without them having to ask. If you can’t automate it, give them a quick prompt that lets them kick it off (or not). Be like the OnStar service that detects the accident and immediately asks if the driver needs help.
Remember, dramatic things like product crashes or deadlocked databases aren’t the only failures to worry about. The more mundane failures matter too – how the app behaves when the users loses internect connectivity, or what happens when a query times out – should be your radar just as much.
Recruit a panel for usability testing or product feedback on UserMuse Here!