Designers and developers need to work together to make sure your chatbot is still nice to your users, even when the worst happens.
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, handling technical errors well is going to be critical. So let’s take a very high level look at what we need to do…
1. First things first, 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.
I know not everyone has the fun of working both on bot design and bot development like I do, so if you aren’t the developer, go ahead and wheel them to a whiteboard and ask them to sketch it out and help you do this. Getting the error handling lined up with the correct user experience is going to take both software development and design skills.
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 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. Give your users a helpful version of the error
Since you have 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 an 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 they are clear on what options they have.
- Some, but not all, of your services are down
In some cases you will have only partially lost functionality. Give your 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?
Never leave the user feeling like they are helpless or you just don’t care.
4. Write it down, make sure everyone on the team is aware
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.
There are a lot of established patterns for this already, so I’m not going to go into them here because there are lots of other articles, books and examples out there. Many of you may be experienced with these and already doing then — however I know a lot of people getting into bot development are also new to software development.
A lot of errors can be mitigated or avoided with some thoughtful design.
6. Add monitoring. And look at 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.
If your chatbot wasn’t working right this moment, would you know?
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.
Wait, there’s more!
I know there are a lots of articles on how easy it is to build a chatbot (an hour! 10 mins!), 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 (and this article is actually the third in a series— the other two are detailed below). A simple baby bot may be quick and easy, but a proper grown up bot is going to take some work.
A simple baby bot may be quick and easy, but a proper grown up bot is going to take some work.
Here’s where you will find the other parts of this series:
- Voice Recognition Errors: The UX of not making your users shout at your chatbot
- Conversational Errors: Helping Your Baby Bot Learn To Chat Like A Grown Up Bot
If you found this article useful or interesting, please 👏 below, I really appreciate it. You can also follow me here, or on twitter @virtualgill.
Good UX when your chatbot is having a very bad day was originally published in Chatbots Magazine on Medium, where people are continuing the conversation by highlighting and responding to this story.
Source: Chatbots Magazine