Designing UX for chatbot failure
We all like to think that technology, especially technology we didn't build ourselves, will always be available and working. Sadly, all technology is capable of failure. If you are selling something, or providing a service people depend on, determining how you handle technical errors is critical. This blog aims at walking you through a high level look at some key considerations you should think about when designing UX for chatbot failure.
1. Work out what can go wrong
Go ahead and grab your chatbot's architectural or process flow diagram so you can mark every possible failure point. Calling out to an external service? Possible failure point. Saving to a database? Possible failure point. Hosted on a cloud provider? Lots of possible failure points.
Getting the error handling lined up with the correct user experience is going to take both software development and design skills.
2. Protect your users from the ugly truth
It may be the truth that somewhere down the line the error you are getting is "HTTP 500: Internal Server Error", but your users will not thank you for being that upfront with them, and this response is unlikely to be in line with the tone and personality your chatbot normally uses.
To be able to stop ugly exception text from getting back to your users, errors need to be handled correctly in your code. Make sure this is considered at every point in your system that a failure can occur.
3. Provide users a helpful version of the error
Since you've made a list of all the possible failure points, go through each one and work out what information the user would need in that case, and after that craft it into the tone and style your chatbot normally uses.
Here are some examples of the information you might want to give to your user:
A critical service is down
Be clear with your users that just trying again right away isn't likely to work. Do you have a service level agreement on how quickly you need to respond and get things back up? If so, could you use that to give the users a possible timeline for when they might try again?A database is down and you can't save any information
Ok, your users are going to be unhappy here. Be really apologetic — your user has spent time and effort here, and now won't get what they need. Make sure they know that their transaction has not gone through at all. Think about what is possible for you to do — can you direct them to another channel? Or better still, could you salvage some of the data and send it to someone who could call them? Make sure users understand what options they have.Some, but not all, of your services are down
In some cases you will have only partially lost functionality. Provide users what you can, and be clear on what is missing. Be aware that they could be a returning user that expected to get this functionality, or a new user that doesn't yet know you have that functionality and so may assume you don't if you don't mention it. Tailor the message if you can.Something is wrong just for this user
There is always going to be that one weird case, where everything is working for everyone else, but not for this user. It's likely that trying again later won't work any better for them. Let them log an issue with you (or tell them you already logged it for them) and either direct them to another channel or tell them you will get back to them.
There are of course lots of other things that can go wrong — in all cases remember to include information on how to log an issue or contact you. Never leave the user feeling like they are helpless or you just don't care. Also make sure you know what messages line up with what errors — if your user reported a specific one would you immediately know what it was?
4. Create an Error Style Guide
Make sure to document acceptable error messages for the different scenarios in your style guide (or wherever you keep information on your personality and tone). If you have a team, make sure everyone is aware and uses it. In your normal flows, conversational user experience will be very much in everyone's mind — in the error scenarios it would be very easy for the developer to just throw in something quick and not really consider the conversational design. Then you end up with your normally professional and polite chatbot saying something like "I am broken, I must be fixed" (that may be real example).
5. Developers, Get Your House in Order
A lot of errors can be mitigated or avoided with some thoughtful design. Do you have proper failover in place? Do you have backups? A lot of this will depend on the criticality of your system, as cost will be a factor too, but don't forget to take this into account when designing your code.
It's also important to identify where you can toggle off functionality when things go wrong, and inform your users as soon as possible in the flow, rather than after they have already spent time and effort interacting with your chatbot.
6. Set Up Monitoring and Analyze it
If your chatbot wasn't working right this moment, would you know? Don't wait for your customers to start complaining — how many will you have lost before some do? And if you don't have proper error messages in place they may not even be aware how to contact you. Make sure you have some sort of monitoring in place for your critical systems, and make sure it is alerting you as soon as possible if things are not working.
7. Keep Learning
You aren't going to get all of these right the first time. Keep an eye on your system, listen to your users, and update and change things as you learn more.
There are a lots of articles on how easy it is to build a chatbot claiming you can build one in under an hour, even 10 minutes; and while that is true, building a chatbot is not the same as building a good chatbot. Good user experience in error handling is only a small part of what it takes to build a good chatbot. A simple baby bot may be quick and easy, but a proper grown-up bot is going to take some work. Designers and developers need to work together to make sure your chatbot is still nice to your users, even when the worst happens.
