Conversation Design Patterns for Chatbots

Watch The Event Again

Event Q&A

How do you design for accessibility when working with voice or chat?

Vittorio: Before I dive into it, I think that generally in design, there are two, two areas that are very interesting for research. And one of them is the conversation. One of them is accessibility. So And with that, I want to be humbled because I'm not an expert on accessibility. I look more at conversation design. I think in general, it's, you have to be thoughtful on like, a lot of levels when it comes to accessibility. So for example, for chatbots. I always considered that there. Like, for example, the length of the message. It's very important because it may affect how your users will see if they have, for example, bigger font size and stuff like that. So Like the being concise is actually plus in this case, in terms of accessibility, usually, because you usually have less real estate. And for voice, I feel like there are so many different accessibility cases that I'm, I have trouble, like generalizing. Like, for example, I've seen crazy examples of using voice for accessibility for folks with high impairments. I don't know if I'm saying this right. Which was totally different than other types of impairments that are more related to speech. So like expressing yourself and so having a voice interface that is talking to you and in your conveying that through that. So I think in general are very interesting areas. I don't have a very strong opinion a lot on accessibility, unfortunately.

So what are some of the differences between designing for voice and designing for a chatbot?

Vittorio: Yeah, that's a very good question. So the way that we're looking at it about society is it's kind of the same switch that you will do if you were to switch from a desktop experience to a mobile experience. So a lot of principles are, are common. So like, a lot of usability principles that you learned on the desktop, like the bottom, the bottom on the bottom right corner and stuff like that, as they apply, but you just have less real estate on mobile, and it's the same invoice like you have less real estate like you cannot have messages that long. The attention span is shorter. And so it's kind of like the mobile of conversation interface. But you don't have a screen most of the time, right? So you have fewer cues, but the rest of the conversation design principles apply. So it's very interesting. It's kind of like the constraint is actually guiding you more towards, you know, just relying on the general principle rather than some stuff that you can get away more when you have more real estate.

So when your application targets a broader user base, and what are some considerations when working on the repair paths? When you have some audience who are non-English speakers, you know how it is really frustrating when you're a non-native speaker and you ask something, and then the device just doesn't get to you because you have a strong accent. How do you or you even have any ideas around how to work with that?

Vittorio: First of all, I have no idea about that because my accent is clean. that happened to me a couple of times, of course. I think it's generally so I think it's a very interesting question. And I think it goes even deeper than that. So what I've seen is that even for you know, native speakers that express different accents, then the, you know, the natural language processing may not work in the same way. So that's a general issue, I think, not an issue but like something that to take into consideration when you're designing you will try you may try to change your design in order to stimulate from the user's words that are easier to understand. And more of like plain words instead of just going for convoluted long words. And basically, the crazy thing of conversation design is, if you change, a question is worded, you will basically get different answers or Even just with the same structure, changing the personality of your bot will get different answers. So you know, that's into consideration, then I think the second thought I have about this is, even if your bot is speaking the same language, you may need a different bot if you're going after different cultural contexts. So for example, if you're building a bot in English, for the US market, you will probably need to redesign it for India, or you will probably need to adjust it for the UK. And the reason is that the contacts than the unwritten rules are different. And so what we're seeing, especially from the, you know, the bigger folks in the industry who have the firepower to do that at scale, they're basically rewriting a lot of interactions to match this expectation.

How do you define the trigger or the threshold for transferring from the bot conversation to a real person in support? Like, what is the trigger for when the human needs to come into the conversation?

Vittorio: So I think there are two parts and I think in the answer, so the first one is, you have use-case considerations first. So what we in our experience Like, the more they use cases sharply defined, and the more they use cases following those ideas that were mentioned before, where it's, it's really fitting a conversational experience, then the best. And so usually that means though, that since you're making a decision, you're leaving out other use cases. And so in that case, the best thing is like you acknowledge that there's a different intent and then you escalate to like, Okay, I think you want to talk about this, but I'm still not ready you want to talk with a human. And so in that way, you can focus your firepower on the use case where that you can really automate that is more compelling. And then the second threshold I would say is what we have seen together they multi-level repair paths. So if you build a system where the consecutive times that a user in the bot does not understand each other, they may trigger a human. The downside to that is that people react to The system that you build. And so you may end up with folks that just want to talk with a human, that just will piss off the bot voluntarily just to escalate proposal flow that is gonna, that is gonna screw your stats. So, so my other advice is if you don't force people not to talk with a human if you see that they really want to talk with a human because that will actually give you more data about what people are available to do on the bot at least in that moment of time. 

So you said you have to be kind of not looking at what the engineers do, but are you not losing in what you are designing? If you are not aware of the specific of the platforms?

Vittorio: Yeah, absolutely does and I think I gave you the wrong impression there. So because of most of it, you can see all the different devices you can design for different devices at the same time. So it's into consideration. I didn't show it in this presentation because I was trying to be general. But that's not, I probably gave you the wrong impression there. So we're not essentially dissociating from that actually, it's more than that, like the unbought society you can find, not only voice, like on voice flow, but you can find any platform like IVR or WhatsApp or, and so it's always tied to the device and the experience, but at the same time, the rest of the tool is the same, so that you can get, you know, you can get very good at designing once or twice, you need to relearn it every time you switch. And that's kind of daunting. I think, for a designer's point of view, you want to, you know, get very good at Photoshop, you want to get very good at sketch-like there's some level of professionalization there if that makes sense.  

So it sounds like, there's some variation between platforms. But are there any specific like core tools like in terms of the infrastructure, and programming languages and of core necessities to build a chatbot? 

Vittorio: So like, what is the infrastructure when you're building a chatbot, regardless of the final channel that it's deployed to? Right? Yeah. There's a lot of infrastructures there. I think the ecosystem was great. The way I'm looking at it, it's like you're gonna have a stack in the same way that you have a stack for visual apps. And so the way that I'm looking at it, it's like okay, you design with bots society, then your engineers will pick a dialogue manager, which for example, like dialog flow or rasa, and then you will attach like a machine learning algorithm or engine. So, you can decouple it or you can use again like what Google is giving you or rasa built-in one which is a tensor flow. And then attached to that you will have the channels so then you can attach, say, okay, messenger, as a delivery system, or you can have like the Google system like this. So you have this kind of like, stack that you can change as blocks. But it's more or less, this is the structure. This would mean like some sort of flowchart to be clearer.

Rasa is an open-source framework. And basically, it's like you instead of, say, using Deluxe or from Google, or say, Louis, from Microsoft, or those cloud options, you take this open-source, alternative, and then you run it on your servers. And so you have complete control of the code and your data. 

Do you have any suggestions for methodologies or approaches that are in product development a little bit earlier in the process? So when we're still doing discovery research, and we want to validate product concepts faster, with less investment into design and development, to understand that they're desirable to our users.

Vittorio: What I'm saying is like in that phrase, what I find very useful is to do two things. So the first thing is you just talk with users. And you can pretend to be a bot. Or you can just be very clear that this is like an experiment that you're running kind of like you would do in a sprint, the design sprint with a prototype, right? Like if you were doing a graphical user interface sprint, you would come up with a prototype on envision or something and it's not like you would say, this is a complete app, you would be straightforward, and you would say that's a prototype. So what's the prototype on this level for a design sprint I think with bot society, you can get there but because it's you're freer to just, like drag and drop a message around and come up with anything. But also we have seen users just pretending to be bots and trying to have conversations and asking questions. And for example, for this lat feeling idea that can get very powerful because you can ask open-ended questions, and then you see what people say. And then you kind of like, they find it's down to your slot feeling kind of more structured thing. Once Yes, you know, once you start designing, and then you define it more. So yeah, just to complete so I feel like a mix of just being scrappy and trying, trying like IRL or through a chat to being a bot and then switching to a prototype solution like bot society in that initial phase may be useful.