Conversational Design is a Dead End Approach

The vast majority of Chatbot vendors require you to "design a conversation." The AI of the system try to recognise the intent of the user, and bring the user into the scripted conversation where appropriate. It's an approach that requires Conversational Designers. This role both anticipates user behavior, but also writes the interactive dialogue to help the user. I believe this approach is fundamentally flawed, as it creates exponentially more work as complexity increases.

Take a simple conversation like "Booking an appointment for your car service". To design it in the traditional way we need the following: a way to identify the intent, what garage the user wants and what time that want. In Conversational Designer speak, we have one intent and two slots we have to fill out. Sounds simple, right?

Well, the happy case conversation is indeed simple. The conversation might go something like this:

Bot:  "How may I help you?"
User: "I need an appointment for car service?"
Bot:  "At what garage do you want your car serviced?"
User: "Downtown"
Bot:  "At what time do you want your car serviced?"
User: "Next Tuesday"
Bot:  "Next Tuesday at 8am?"
User: Yes        

How many conversations actually goes like this though? Let's look at each line, and see how the user might throw spanners into the mix. Instead of "I need an appointment for car service?", they might say:

• "My car is damaged"
• "I need to get my car fixed, but can you tow it?"
• "Can I come in with my car now?"
• "Do you have any appointments at any garage tomorrow?"

In order for a traditional system to handle the conversation, this is now separate dialogue trees. The first one can fit the happy case, but the second has an additional question that implies that the car needs to be towed to the garage. The third one implies that it's urgent and they need to come in immediately. The forth, says that location does not matter, but I need it tomorrow.

That's just the intent recognition though. What about the question "At what garage do you want your car serviced?":

• "I live at (address), the garage closest to me will be fine"
• "I live at (address), and I work at (address), wherever is close to either will be fine"
• "The garage that has an appointment free for tomorrow morning"
• "My winter tyres are at (location), if you can change them at the same time then there... if not, any location is ok"
• "I don't care"
• "One located going out of town eastbound so I can drop it on my way to work"

And this is just scratching the surface. Each one involves a much more detailed understanding of what is being said, than a simple mapping to the scripted conversation. Each one requires a number of API calls, and logical deduction of what is explicit... and what is implicit, in the statements made. In most cases, all these will be labelled "edge cases", and put to the side.

Now comes the question about time... a domain so complex that there are separate AI systems out there specifically designed to understand it. Just writing a date has an extensive number of international standards just to define it. What might the user do to the question, "At what time do you want your car serviced?"

• "Next week is fine?"
• "Any time in the morning next week"
• "Tuesday or Wednesday before Noon"
• "Just before closing on Friday"
• "Any day as long as you can get it finished by 10am"

You can see how this is now becoming increasingly complex, right?

The approach of conversational design requires me, as the Conversational Designer, to anticipate what the user is going to say - and then specifically writing dialogue to handle the things I anticipate. A simple scheduling of a car service appointment, through this article, has grown from the happy case of 1 intent and 2 slots... to multiple intents and a complex tangle of dialogue paths that will take days to craft.

Then comes the fact that you need a description of why you want the appointment, the license plate of the car, their insurance company and policy... and now you have a huge and complex dialogue.

And not only a huge and complex dialogue - a huge and complex dialogue that will be very hard to change and debug, because the number of paths. Dialogue systems requiring Dialogue Design of this kind deals with that by saying, "well, you force the user into the path so we can deal with it". Effectively, they are designing a glorified chat/voice command line system - or a voice enabled self-service system. A slightly more advanced version of the "press 1 to..." IVRs of the part. It doesn't perform the work of an agent.

No matter how good you craft the dialogue. How much you tweak the words used and the personality. You will never escape the fact that the dialogue is forcing the user to follow certain steps. You will never be able to package the limitations of the underlying technology in a glossy wrapping paper.

Designing Conversations like this is not sustainable.

What if I told you there were another way? A dialogue management system based on telling the Agent how the world looks. A system that deals with all of the above permutations? ...while everything the system needs to know fits on a single screen? ...and you don't have to script any dialogue at all?

Would you believe me that such a system exist? And it's not the unexplainable, non-transparent, hallucinating, confidently incorrect, privacy and compliance breaking insert-LLM-flavor-of-the-month-here. Although we use LLMs for what they are good at as part of our "magic trick".

I look at such a system every day. I'm on a mission to rid the world of conversational designers - and the practice of conversational design. It's not necessary. It's not sustainable. And it doesn't create good experiences at all.

Follow me to learn more over the coming months as I will be able to reveal more.