In an earlier post, I described the conventions that I use for designing conversation flowcharts.
In this post, I will be suggesting some improvements based on some additional experience I have gained since I wrote that article.
Using an ellipse for representing a context
I have started using the Ellipse shape rather than the Diamond for representing contexts.
There are a couple of reasons for this.
1 The Ellipse naturally saves vertical space
Take a look at the flowchart below. The right and left branches are identical flows and ask the user the same set of questions. If you compare these two flows side by side, it is quite clear that there is a significant space savings when using an ellipse.
2 The Diamond shape becomes vertically larger when you have a longer context name
In addition, the Diamond shape also takes up additional vertical space when you use a long context name.
In the flowchart below, you see that the longest context name when expressed as an ellipse is still the same vertical size as the shortest context name expressed as a Diamond. In fact, the nice property of the ellipse is that it remains vertically the same size no matter what the length of the context name is.
We don't want to use context names which are too long, for other reasons. But we shouldn't be unnecessarily constraining ourselves just to be able to draw the flowchart.
Use border colors to represent intent type
Since we haven't been using the border colors feature of XMind at all, I have started using them to represent different intent types.
For example, a red border color around an intent may signify a fallback intent.
While a green border color around an intent may signify end of conversation.
The "end of conversation" intent doesn't make a lot of sense in all kinds of Dialogflow agents. After all, the user does always have the choice to write another message and continue the conversation.
However, it is very relevant for a Google Assistant app you have deployed on say your Google Home. In such an agent, the conversation actually audibly ends and the control returns to the Google Home's default voice. You cannot "continue" the conversation at that point without re-invoking your Assistant app and starting over.
Use angle brackets to specify dynamic user input
In the flowchart above, I write User: <provides first name> to signify that the user has provided a first name. The angle brackets here (< and >) indicate that those aren't the exact words the user types in, but it is the human interpretation of what is going on. It doesn't matter exactly what first name the user wrote, the important thing here is to capture the user's message succinctly inside the flowchart.
In fact, in some cases the actual process can be really involved. For example, in my previous post, I have the following node in my flowchart:
When you go and read that post, you will see that this actually means Dialogflow maps the user's phrase to a specific intent, but also under the hood you will be then sending the captured input to the webhook for validation.
Using a flowchart can greatly speed up the process of building out your agent prototype. At the same time the important thing is to codify some standards within your own team and it isn't necessary that you need to follow the exact conventions I am suggesting here. They can however be reasonable default choices for you to get started.
At the same time, as you can see, I have changed my mind on the conventions and provided my reasons for it. In a similar way, you should use some consistent conventions for your flowcharts, but you can and should just use the ones that best suit your particular use case.