|The conversation design toolkit is a series of tips and ideas
for creating more natural, conversational chatbots. Click here to download the tips as a 3 page PDF checklist (free).
Have you seen the movie “See no evil hear no evil”?
Then you probably know the line “Because he is deaf, not stupid”.
Give users credit
On a related note, you want to avoid doing this:
But save the guidance for those who need it
Well, other than the fact that you now know I have an excellent ability to generate pointless movie scene analogies, there is another takeaway from this article.
Since you control the chatbot medium to a large extent (including your response if there is no answer from the user), you can use this to your advantage. Allow the user to drive a conversation forward without being verbose. If the user needs help, you can always provide it.
Those who are already using API.AI know that the first method is better for the programmer, and the second method is better for the user. That would be another takeaway from this article. Don’t create your conversation script based on what is easiest for the programmer. To the extent possible, create it based on what is best for the user*.
How to identify the problem in your agent
The fastest way is to use the technique proposed by Mark Twain.
“As to the Adjective: when in doubt, strike it out.”
Look at every sentence beyond the first one in a text response. If you can remove it without affecting the meaning, and it makes the message less complex, remove it and add it back into the fallback response.
A second clue to look for is if your agent asks a question, and instead of allowing the user to answer the question, it goes on to provide an explanation for how the question can be answered.
*Up to a limit. This is still a software program, and it cannot actually replicate a human in their ability to have a conversation.
So where do you draw the line? That’s a good question and it has no easy answer. Sit down and discuss with your API.AI programmer and get the list of choices in increasing order of programming difficulty, look at your time/resource budget, and decide accordingly.