Before we start working in any application we need to have clear objectives and minimum specs or requirements.

In the world of software development, we already use standards and tools: User stories, jobs to be done or classic specs are just examples of tools to put all the involved parts on the same page as to what needs to be done. Once they are clear, tickets are added to Jira, and development tools are used to ensure continuous integration and delivery and proper QA.

In the world of conversational interfaces, we need to modify a lot of these standards to fit our use cases and we inevitably must create new ones.

There are three basic processes to cover:

  1. Defining the goals of the bot and the basic conversational flow.
  2. Programming the basic conversational flow.
  3. Analyzing and improving the bot.

In this post, we will cover tools that contribute to the first step: the definition and design of the conversational flow.

For this purpose, we have developed two internal tools: the conversational canvas and the conversational user personas canvas. On top of this, we use different industry standards and made up conventions for the definition of the scripts.

Conversational Canvas

We use a template called conversational canvas because we believe it helps bring everyone on the same page. It forces the team involved to make explicit some project necessities (like integrations) that too many times are shadowed by the fun part: dialogue writing.

The conversational canvas is inspired by the business model canvas. The main value proposition is the center of the tool, and users and services (e.g. internal databases or external apps that need to be integrated with the bot) are the two main blocks that define the remaining canvas.

Conversational User Personas

The conversational user persona template is inspired by regular user persona templates. The difference is that the conversational user persona template includes specific information about the devices they own and the way they speak and write.


We use the same template we designed for the user personas to define the character behind the conversation. Naming the agent, giving it demographic info and desires and motivations, and adding information about the way the agent speaks helps a lot when defining the personality and “staying in character” while writing dialogues. If your company has any sort of corporate communication guidelines they must be considered while working on the character.


Once we know what we are building and for whom, we need to map the different steps of the conversation. This is a high-level map that does not get into the details of how things are said. BPMN (Business Process Modelling Notation) is a good tool, as since it is a standard it has the following advantages:

  1. BPMN diagrams can be understood by most business and technical people.
  2. BPMN elements are available in a lot of tools, such as MS Visio, Google Slides…

Now that the high-level conversation is mapped, it’s time to define dialogues.

Conversational Notation

There may be a standard for conversation writing, but I found that this simple approach works for me and has a bonus: I can use this convention in ANY tool, even on a whiteboard.

Start lines said by the bot with a plus sign (+) and lines said by the human with a minus sign (-). Words between [square brackets] represent images, {words} {in} {curly} {brackes} are elements of a gallery and (simple) (brackets) are buttons shown in the conversation. This is how all these elements look like together:

We write different small segments of the conversation in this way. We find this helpful when defining the general tone of the conversation and the use of navigation elements.


Pin It on Pinterest

Share This