With the proliferation of new AI solutions for business, especially when talking about chatbots, workbots and RPA, a new kind of UX design has been brought to the fore. It’s called conversational UX and it requires a combination of strategic thinking and a little artistic flair in the words department. With the promise of the no-collar workforce growing to as much as 50% of global employees within the next 5 to 10 years, teaching AI to hold a decent conversation is the next major frontier for the practice of user experience. In the recent past, we have been testing our mettle when it comes to conversational interface and what we’ve discovered is that just like any other type of UX, developing bot conversations is anything but a straight line. Which brings us to our starting point…
When mapping out what makes a good (and realistic) conversation, we quickly became aware that almost all conversations are not linear. It’s not as easy as just writing up a dialogue with standard responses. Why? Well, because a conversation is not only a string of words and ordered messaging. It is also about behaviour. Specifically the behaviour of your chatbot system. You need to take into consideration when and how your bot pauses for a user’s response, how it requests retries in a user’s response and how you instruct your bot to handle unknown topics.
The linear nature of a chat User interface
Talking about templates and structure. The user interface pattern of all conversational tools today presents a linear conversation as a list of messages, mine on the right, and the other ‘person’s’ on the left. It flows like a ‘river’ and actually does not support the discovery of the ‘what is coming’ and ‘what is possible’, i.e. the tree-like conversation map we referred to earlier. This is why we believe a non-conversational form will help build a better user experience for the user.
With the conversational form, questions can be adapted to previous answers making responses shorter and arguably more ‘natural’. Natural human-to-human conversation conventions are not always better for human-computer interaction. Therefore, error and correction handling in the conversational interface requires special attention to detail.
Not just a chit chat
All the chatbots we’ve designed and built were created to do something beyond just responding to a user’s questions or remarks. There were a multitude of functions they were programmed to do: from collecting user input for event registration to processing internal requests, to asking for a particular user response in a quiz or alternatively forwarding an unanswered question to a human.
Our goal in almost all of our projects was to build a chatbot-with-a-job. This meant that when we were building our conversation map we needed to truly understand and construct a dialogue that would ultimately ensure that the bot could do its job effectively. These kinds of conversation maps have a tree-like structure and if you ask some of the experts out there, they’ll claim that a bot built like this is not a real chatbot. We disagree entirely. For the user, the interface is the system, so if it looks like a real chat and there is a robot behind the chat, it is a chatbot!
It takes a village to write a bot
When creating a chatbot we’ve learnt that there are many differences between a professional copywriter, a UX designer and subject matter experts, and how they might go about writing a bot conversation:
- Copywriters: write dialogue like they are writing a screenplay, it’s story focused providing character and substance.
- Subject matter experts: work in a Question/Answer format, using thetree structure as a cascade in Excel, frequently this is very detailed and may need to be cut down but it is very important in providing context.
- UX designers: will create a happy flow prototype using UI prototype tools and developing the conversation visually with boxes and arrows.
- Bot developers: focus on the logic and prefer to work directly in bot frameworks like Google DialogFlow, IBM Watson, Wit.ai or Microsoft LUIS.
- Back-end developers: focus on the business logic that goes beyond the conversational logic of the bot.
Every one of these roles is important for great bot building so our advice…work as a team. Your subject matter expert will provide the correct information, while the UX (conversational) designer will take care of flow and behaviour, ultimately making a proposal for organising content in a user-friendly way. Your copywriter will refine the tone and voice of the bot to ensure it is on brand and has ‘personality’. Finally, by involving your bot and back-end developers early in the process you’ll be aware of both the limitations and capabilities of the technology that will be used.
Not just a standard UX designer
Adopting this process is very similar to how you might create and structure non-conversational interfaces but it has one key difference and that is the core role of your conversational designer.
They’re a little different to your standard UX designer. Typically they’ll be a language major, most typically English, with the ability to understand how chatbots work or UX designers who understand the rules of human conversation and are able to translate this to chatbot conventions.
Test before you build
Rapid prototyping tools from paper-prototyping to advanced high-fidelity prototyping tools like Framer or Principle allow designers to create a prototype to test with users before implementation. For a chatbot it should be no different — you just need to adapt a bit. While there are a couple of bot specialised prototyping tools like Botmock or Botsociety, using more familiar tools like Axure can also work well for linear conversations. However, for an open conversational chatbot where a user can ask anything, we recommend using the Wizard-of-Oz technique where you have a real person pretending to be a bot. This helps with forming a flow that follows the logic of human conversation. A paper prototype with the Wizard-of-Oz technique can also work for simple flows.
Why even write conversational scripts if you already have a knowledge database or FAQ list?
Dumping a knowledge database of content from your website or brochure into your chatbot and expecting that it will be able to ‘learn’ and then develop its own conversation is a fool’s errand. Modern bots, even the ones that use Artificial Intelligence driven Natural Language Processing (NLP) are not capable of creating a conversation out of a knowledge database. It’s as simple as that.
This means you will need to predict all the topics a user will ask your bot about (these are called ‘intents’ in chatbot jargon), then write all the phrases and their synonyms people might use to formulate their intent (called ‘utterances’) and write a response for your chatbot that could be just one message or a multi-step scenario. You’ll also need to define the rules for your chatbot furthering the conversation. These parameters are what make up a conversation and also explain why just dumping a knowledge database on your bot will not teach it how to speak.
In the real world
In the end, it is still a bit of a guessing game. As you develop your conversation you’ll try to intuit what people might say to your bot, but in reality, you will get unexpected responses from users. Most of the work for user-driven dialogue happens after launch. Be sure you have a conversational designer-friendly system that allows you to monitor the conversations, which includes the ability to add and make corrections to scenarios in your dialogue. These monitoring systems are quite rare and it’s why we decided to invest into our own product, TUR.ai. This venture into the AI world has seen us building not only a system for content creation but also functionality that allows for monitoring and adapting dialogues. We call this ‘learning’ in the chatbot world.
When approaching a bot build, as with any other product build, good UX will be one of the biggest determiners of success. Making it central to the project will help inform all the other players in your team. Your UX conversational designer should be the cog in the machine that holds everything together and keeps your project ticking over. Invest time (and money) in the right team and installing the right processes and you’ll end up with a chabot that does its job effectively.