Hello and welcome! Here at Master of Code Global, as a Conversational AI company, we’ve decided to share our approach to conversational design in this series of articles. Please enjoy and let us know your thoughts!
This is part 2 of a series sharing our approach on how to design a conversational experience. Part 1, Conversational Design #1: Designing Conversational Interactions, looked at the theory behind some of our best practices, and here we take a deep dive into the structure of a conversational design flow chart.
The goal is to present the design in the clearest and most efficient way possible so that stakeholders can focus on what’s important: understanding the the user experience flow. We have found the approach presented here leads to common ground with the client, educating them as to the flow of the interaction without overwhelming in unnecessary detail.
Here’s a simple conversational flow chart or map example – throughout the article, we’ll look at samples from a fictional high school which is going to offer a bot to assist their students and staff with commonly asked questions:
Basic Conversation Flow Chat Diagram Layout
It may seem trivial, but a legend helps viewers get oriented and focus on what matters: understanding the conversational flow.
Without a legend, readers may spend time puzzling over why one box is shaded and another one is clear. Even if it’s just a few extra seconds here and there, it’s a barrier to comprehension which can impact their overall reaction to the design.
The particulars of what shapes you use are of course entirely up to you (although we recommend following industry standards where applicable).
But for clarity and convenience, it is often helpful to embed specific UI choices, sample images and so on directly in the chart. For team members and stakeholders who aren’t as immersed in the project, being able to quickly scan over to see if a shape represents say a Quick Reply button or a “real button” is a big help.
The basic organization is to arrange use cases in vertical flow. Why vertical? Because readers typically have widescreen-format displays, so a horizontal orientation provides more context and makes it easier to pan around when navigating and searching for other flows:
It’s often helpful to arrange flows outward from a central main menu or welcome message. From a usability perspective, this helps your reader stay oriented and avoids the suggestion of a left-to-right sequence of operations or a priority which doesn’t necessarily exist.
Grouping Conversational Flows
If your bot offers different features to different user types or personas, then cluster the flows for each user type separately. Suppose the school in our example plans to offer a bot which both students and teachers use, but only teachers can perform administrative actions. By grouping student flows on the left and teacher flows on the right, we make it easy for the reader to learn how to quickly traverse to an item of interest rather than having to hunt through hundreds of different shapes and various flows looking for it:
Apart from your primary value-driven use cases, also include general-purpose flows such as small-talk and farewell paths that a user can arrive at from other flows, and group these together in another area of the conversation map. Similarly, group error and exception-handling flows in an area of the diagram where they won’t muddle the presentation of the intended user experience:
Labelling Flows and Blocks
The flow charts discussed here are a tool used to show how the requirements of a system will be met.
By the time the conversational map is being laid out, those system requirements should already be documented (as use cases or functional points) and clearly labelled with ID numbers or codes. For example, “Requirement S3: the student can ask the system what is available for lunch in the cafeteria.”
So for accuracy and ease of reference, when labelling each flow, include the ID of the requirement that flow implements. This allows the flow to be referenced from elsewhere in the diagram or during review with the team and stakeholders.
Furthermore, each user-facing or significant block in the diagram should then be given a sub-ID based on the flow it belongs to. For example, rather than having to say “in the 2nd box down from the top of flow 3…” it’s more concise and less error-prone to be able to say “in box 3.2…”.
Even more importantly – while it’s not incorrect to represent every possible transition with a connector arrow, it begins to obscure the salient features of the user experience when 90% of boxes on the diagram have arrows back to the main menu. Including ID’s throughout affords a much more concise and manageable way to do this, called a “goto”:
Borrowed from the world of computer programming, a goto keeps things clean and efficient by “jumping” to a reusable item rather than introducing redundancy and noise by replicating it (or the connections to it) over and over again. This is made possible by including ID’s in the flow and block labels.
Regarding these ID labels in the diagram – if the system requirement IDs they are based on are guaranteed not to change, then simply reuse those IDs. But in practice, it’s usually safer to create new IDs for the diagram. When a business analyst changes “system requirement 4.3” to “4.4”, it’s easy to do a find and replace in a word processor or watch as numbered lists automatically update as elements are inserted and removed. But it’s hard to do that accurately in the flow chart – while some diagramming tools do offer a “find and replace” feature, depending on the numbering scheme used, there can be ripple effects where you are forced to manually update many dependent block IDs throughout the diagram.
At best, it’s unproductive to have to re-label the diagram every time requirements are updated; at worst, the flow breaks when this is missed and block IDs aren’t updated correctly, and this may not be caught until it manifests as illogical system behavior in QA or even deployment!
If possible, it’s convenient to hyperlink the use case or requirement from the flow.
Most modern toolsets allow clickable links and hotspots within the diagram, so take advantage of that and make it easy for everyone to get back to the requirements which drove the design choices in a flow, just by clicking on it.
While NLP dialogue is typically captured in a separate artifact, it’s helpful to show sample dialogue which would bring a user to a given flow. This helps orient the reader to what the user is trying to accomplish and sets a good foundation for understanding why the flow is a good match for the intent. Under the testing stage, make sure you identify all issues and aware of all troubleshooting chatbot conversation flows examples.
Download our Chatbot Analysis Framework!
Summary
It’s easy to drag shapes around in a diagramming tool, but an important part of Conversation Design is to afford stakeholders every opportunity to easily understand the design. The diagram will often be reviewed by a combination of clients, developers, and leadership. This means it’s likely that a given reader will be lacking familiarity with either Conversational AI solutions (in the case of leadership and subject matter experts) or the business domain (in the case of the development team.) The flow diagram is a bridge between these worlds, so it’s important to structure it in such a way that reduces friction, promotes shared understanding, and ultimately helps ensure the best decisions get made for the eventual system.
To that end, we looked above at Conversation Design best practices for basic diagram layout, the grouping of flows, and labeling flows and blocks for ease of reference. In the next part of this series, we’ll build out some flows for an example bot using the best practices described above and in part 1.
