This might sound really strange…. but failing does not necessarily mean that you have a problem!
As some of you are aware, creating flawless software is a difficult and long process. Mistakes are common and your users will undoubtedly have some sort of bad experience somewhere along the way. No software is perfect! So if it is unavoidable, what do you need to do about it!? Well, preparation is key!
To turn your fail into a success you need to have a couple of things:
- Lower the bar: If your users expect you to do great the fall will be bigger. The lower you are, the lower the fall.
- Humility: If you fail let your users understand that you are merely human and will fix it as fast as humanly possible.
- Transparency: Let your user know what is going wrong. Information is key to understanding.
- Elegance: Nothing says FAIL like a default error message or a completely warped interface. Solve your errors as elegant as possible.
- Feedback: Nothing is as frustrating as a bug that keeps returning and is not fixed. Let the user submit bugs and keep them in the loop!
“The bigger they are the harder they fall” is the saying. And this is more then true for errors and bugs. The biggest profit you can make on the damage control department is to lower the expectancy in the first place. Develop your application in such a way that it does not have to succeed in everything. Sometimes you can have an error as long as the core of your product is solid and works like it should.
The old Google mail BETA is in my opinion a good example of lowered expectation. At first not everything worked perfectly. But just sending a mail, searching in it and having a absolutely giant inbox were always working fine. I’ve seen contact auto-completion fail, adding stars and labels, I’ve seen adding dates to email fail… but I never had a problem with it… It was BETA! Just that simple word below the logo made everything right. And now even when it’s gone in Gmail it is still working by adding new features first to the “labs” section. The “labs” label on a feature tricks the user into thinking that the features are far from done. This is not true and a lot of them should already be released features. The “lab” just allows for more errors with less frustration.
It might not sound like much, but a bit of humility will go a long way. Just showing that you are not perfect and therefore cannot produce a perfect product will make your users more understanding when something does go wrong. Showing big ego is never good when trying to release a product. Keeping it down to earth will allow you to have a miss-hit once in a while without your users breathing down your neck.
To much humility is also not really good. You still need some arrogance to sell your product. So, in a way, it is all about balance. Well actually this will probably come down to a fight between the one that is doing marketing and the QA department that want to do pre-emptive damage control. There are success stories that showed a lot of ball’s during development. But you are more likely to have some damage from this then having a major advantage (unless you are the greatest of course).
Information is the key to the understanding of your users. If your users can see what is going wrong they can understand that you are doing everything to prevent it. Telling your users that the page they were looking for does not exist with a 404 message will tell the user that a dead link occurred somewhere. Although this is the most annoying error you could get if your just browsing, it tells you exactly what happened and is acceptable if it does not happen structurally.
Transparency is not only important in error messaging but also in validation, success and progress messaging. It is always a good idea to let your users know what is going on in your system. This will give the users confidence to do things in your system as they have an idea what is going on.
Falling in an elegant way is always better then just falling face first on the floor. Elegance will soften the blow to the user as they encounter an error. Don’t use the standard error pages as they are purely build from a technical perspective. Use comedy, complete information, escape possibilities or just sheer beauty to help your user to get into a better situation with the least amount of stress. You might even distract and entertain your users for just a second before redirecting them back to their tracks. Just have some fun with it!
Just a few examples on how to spice up your 404 page from: “The Best of the Worst 404 Errors“
All right, so we failed, what’s next? Errors created by users (just mistyping/hacking of the url) are not something that users need and want to communicate about. It is the persistent bastard of a bug that people find really annoying. Here is where a lot of systems fail to catch the biggest gain, communication about the failing.
Let your users participate in the resolution process. Users can report bugs and errors and are kept in the loop about the progress of that issue. This does bring some extra work to your development team as they have to maintain it, but the advantage is huge! Imagine that all your active users are doing a bit of QA for you… for free. That should be a managers dream!
A system like UserVoice is very useful as it comes to user feedback. It allows users to easily see if issues have already been filed and the user can rate if that issue is actually important to him/her. UserVoice also allows for users to see the progress of an issue and leaves room for other thoughts and ideas to be shared with you.
So you have the issues and your fixing them, what’s next?
You will need to communicate about what you did. Not only to the people who gave you the feedback but also to everyone else that did not report anything. Creating a separate section for updates might be a good idea when you are using this approach.
In general what you need to keep in mind that feedback needs to be easily accessible and that you keep giving feedback to the people that are helping you out.
When everything else fails…
You’re doing everything right, you did the best you could but your still failing. There is only one way out! keep trying, keep communicating, keep users in the process and make the best of it hoping that the users will stick with you as they will see you struggling.