One of the main challenges of conversation design still remains the capacity to describe conversational AI designs in an understandable, concrete manner – to project managers, developers, future users and stakeholders.
Until about a year ago, my conversation design stack was pretty much a combination of several non-conversational-specific and a few rare truly conversational prototyping tools. Much like a lot of other conversation designers, as it turns out :
That was until I joined GreenShootLabs as a consultant, and they introduced me to their open-source tool: OpenDialog.
Curtains open, the crowd goes wild, glitter confetti everywhere, fireworks go off… the one tool we’ve all been waiting for!
Vivid imagination set aside, in reality, OpenDialog checked a lot of boxes for me when it came to designing dynamic conversations.
Before diving into the specifics of what OpenDialog allows you to accomplish when it comes to conversational applications – it’s important to note that OpenDialog is not just a tool but first and foremost a different way of thinking about them.
Conversations to be had, embedded in the user experience.
OpenDialog has a conversation-centred approach to conversation design. As we mention in our manifesto: Conversational applications have a purpose, an overall goal we want to help users accomplish. Building on this idea, OpenDialog defines these goals as a scenario.
For each goal, a digital product sets out to accomplish, including conversational applications, users go through a journey. Identifying key moments in the user journey that can benefit from a conversational approach, OpenDialog embraces the concepts of conversations to be had. At a component level, these are translated into conversations.
Conversations are then split into specific Scenes. Scenes focus on even smaller aspects of a conversation. They are different stages of a single conversation.
Finally, Turns capture single exchanges. A conversational turn consists of the user and the application exchanging Intents.
Sample of our Conversational Canvas Library – .pdf files accessible for private beta members
This modular approach also means that you can use OpenDialog to easily set your overall conversational information architecture first, and then map different messages to that architecture – depending on conditions you can set (more on that later).
It also allows you to start thinking about your very own conversational design system with reusable components throughout your scenario, or across scenarios.
OpenDialog currently supports duplicating messages but will soon also allow you to re-use all conversational components more easily.
OpenDialog approaches conversation design as the design of conversational applications: an exchange of information between two agents. Both agents, human and machine, are considered equal partners in the conversation.
As a conversation designer, you can, therefore, model the dialogue between these two agents from both points of view.
Concretely this means that it is not necessarily the conversational application that drives the conversation, or the other way around. No need to choose between a bot-driven or a user-driven conversational model. You can have both within one and the same conversational application.
Intent overview in OpenDialog’s Conversation Designer – allowing users to set participants to an intent
Thanks to transitions between elements, this also means that you can easily make your conversational application more proactive.
In a lead conversion scenario, for example, this allows you to tailor the conversational flow and its messages to where users are in their purchasing journey and whether or not you want to notify them proactively.
360° degree context-handling
Remember that very dynamic condition-based flow you designed but were told wasn’t currently possible with the state of NLU-tools? Ever wished for multi-turn context holding on your terms?
OpenDialog uses the notion of attributes you can store in and retrieve from context – reusable and configurable at all levels of the conversation. As a conversation designer, you can determine what type of information leads to a certain conversational flow and its related messages.
Context exists on all levels; at the conversation design level, at the message level – split into different context domains; attached to a user, to a session, to a scenario or to the global context.
It can’t get much more modular than that! OpenDialog comes with a set of preset attributes, but you can easily configure some of your own (with the help of a developer friend – or not).
Is it a tree, a forest or some foreign unknown plant in the form of a template?
Puns aside, a lot of the time conversation design is stuck with the difficult-to-scale flowchart structures, a multitude of them or relying on quick-fix tools using templates.
Can you make that quicker, please? Can you also make it more modular, and context-rich? And reusable?
Admittedly, there is more to that conversation design wishlist…
As mentioned before, OpenDialog takes a modular and semantic approach to conversation design, making it a perfect system for designing free-flow conversations, guided when needed, and dynamic when appropriate.
As a conversation designer, you no longer need to choose between guided flows and truly dialectic conversational flows. You can have both within the same application, at separate moments in your scenario.
Let’s think about that lead conversion use case again. When capturing the customers’ needs at the beginning of the user journey – you might want to let the user freely explore, discover your products and chat more openly with your application. However, further down the purchasing journey, you might want to keep them on track in a more guided conversation to secure conversion.
OpenDialog’s modular approach allows you to do just that, using transitions, conditioned conversational components, and component behaviour.
Contextual messages at scale
Did I mention context-rich messages? After OpenDialog’s modular approach, this is probably one of my most favourite things!
Gone are the days when the only thing you could do is enter a user_name in a message (rest assured – you still can), or have a different message only for those users that logged in for the first time versus a returning user (you still can too)…
Think messages based on anything you have stored in the different contexts we talked about earlier. OpenDialog allows you to easily set conditions on messages, without the headache of figuring out how to accomplish it.
How about a personalized message for VIP customers? Yes, it can be done!
Or users that have signed up to your subscription program? Not an issue!
Enough with the fangirling already… surely there are things OpenDialog is not capable of doing? Did I mention it has API Integrations? Also setting up NLU at the intent level, as in you could have a different one for each intent (or not)? Let me think, surely there must be something…
You are probably thinking that to take advantage of all of this you will need to learn some complex new-fangled conversation language. Not quite, OpenDialog has a visual interface including a powerful designer and manageable message editor and an intuitive integration module.
Hopefully, this post got you a tad bit curious about what we’re up to at OpenDialog. We’d value your feedback and invite you to sign up for our private Beta.