Shockingly obvious news alert, those constant incremental improvements your web app releases come at a cost. Unless you have an incredibly well architected application that lets you run different code bases on different servers simultaneously, gracefully moves people away from servers that are about to be updated, and beautifully transitions people’s sessions from one code base to another, you’re going to run into downtime. Even if your downtime is only a few minutes long , you run the risk of breaking someone’s session, introducing bugs, interrupting workflows, losing data, and generally annoying your customers.
The benefits of frequent releases definitely outway the costs. But if you choose to ignore the frustrations you’re introducing into people’s lives you’re just being mean. You’re not mean. You run an awesome web app and you’re pretty great.
The 5 Questions
When your customers experience interruptions while using your application, be they due to bugs, downtime, or just poor design, the following five questions questions spring into their mind:
- What just happened?
- Why did it happen?
- When will it be fixed?
- How can I work around it?
- Where can I vent?
You can’t completely mitigate the frustration that the interruption just caused. However, by answering these five questions will get you much of the way there.
Answers Through A Design Pattern
The downtime message below is my current favorite way of answering the five questions I’ve outline above.
1. What just happened?
The washed out screenshot (A), the specific explanation of the disabled functionality (D), and the downtime message in general answer this question. In addition, the screenshot provides visual context and helps orient people.
2. Why did this happen?
The specific explanation of what's going on (C) answers this question. Make sure to emphasize the efforts your company is putting forth on your customer's behalf. People generally respond positively when they know you're just trying to make their lives a little bit better.
3. When will it be fixed?
A clear indicator of what functionality is disabled and a countdown to the expected uptime (D) answers this question. This is the most important part of the message. It will single handedly stem a flood of support requests because people will know that their issue already being addressed.
4. How can I work around it?
A list of ways to work around the disabled functionality, or if none exist, a list of what else people can use (E) answers this question. For example, if your website is completely unavailable you would list your mobile application.
5. Where can I vent?
Links to your support system (F) answer this question. If you don't provide your customers a medium to complain they will find one on their own, which will make it much more difficult to track and follow up on the complaints. Worse still your customers are likely to complain in a public forum, reinforce each other's negative feedback, and tarnish your company's image. Ideally the feedback medium you provide will be private, trackable, and actionable, You want to use your energy to focus on responding to individual customers, not to a swarm of negativity.
I recommend adding an apology (B) and an adorable doodle (G). Apologizing is the first step to being forgiven and the doodle adds levity and generally makes everyone happier.
That’s it. You’re a screenshot, some careful copy, and a few links away from being just a little bit better.
This may seem like a lot of work for what is basically a temporary problem. However, since downtime is a recurring issue, not addressing it will gradually erode your customer’s goodwill. As an added benefit, the downtime messages can double up as failsafes when a bug is inevitably found on your site. Instead of dealing with a flood of error messages, support calls, and general wonkiness, just take the misbehaving part of your site down. The downtime messages will keep your customers at bay for a while, letting you focus on fixing the bug and releasing a patch.