Visual Dialog Crew: design, prototyping, and debugging, in one click

Despite this, a group inside Innovation has decided to take on the challenge to try and rethink the digital assistant design workflow to make it snappier and more efficient for both our customers and us. How?
The Visual Dialog Crew, made up of three developers (Raffaella, Riccardo, Edoardo), two designers (Carlo, Mirko), and two jack-of-all-trades figures (Francesca, Michele), is ready to tell you all about it!

To design any kind of conversational agent, the first thing that needs to be sketched out is its dialog flow. Said flow is made of two main ingredients:

• a series of nodes, or states, which represent the points in the dialog flow in which the user can find themselves.
• a series of arrows, or events, that tell us where to go and define in which state the user will end up.

Imagine this flow of nodes and arrows a bit like a game with various cells in which one can jump from one to the other. Each cell is a piece of the conversation, and depending on the given questions and answers, you move in one direction or the other. The cell you end up in will depend on the choices made up until that moment.

The job of a conversational designer is to map out all of the dialog states — or every possible cell in the game, if you will — and events, and thus the process that starts with the user’s request and ends with the fulfillment of their needs. The designer then needs to pass the project on to the developer, who will make sure that their ideas are translated into the software’s language, for it to interpret them and handle the various user interactions. So far, this process has been mostly handled with diagrams, similar to the one seen in the picture above.

All of this works as long as the dialog itself is relatively simple, like in a small conversation. A more complex, non-linear flow, however, is another story.

Every time a node or an arrow is added, the underlying code gets more complex, to the point where the flow and the code both become extremely convoluted. Moreover, despite this might be acceptable when the code first gets built, imagine what it would mean to come back to it after a few months and change even just a single arrow in that flow: modifying the design structure would not be enough, as it would become paramount to check that the code still runs correctly. This is usually when friction between designers and developers arises. So what tool can we use to optimize this part of the process?

Our Crew’s proposal is Visual Dialog. Visual Dialog is a web application prototype that allows conversational designers to create dialog flows using a graphical interface based on the simple, intuitive use of finite-state machines, which are already logically tied to the dialog-handling code. The system is then tasked to check that the generated elements of the flow always be accurate and in tune with the code’s logic, making the work of developers much more manageable.

Great UX + automated logic = visual dialog!

When accessing the platform, the conversational designer has two primary tools to build the graph that summarizes the conversational flow — i.e. the states and the events, as we mentioned. States can have different functions that the designer allocates using colors: for instance, a color used for states that give out information; one for those asking the user for data; and another for states that need to interact with external services to retrieve information or execute tasks. It is also possible for each state to add a description or a comment that can help the design process.

Events, on the other hand, are defined within some transitions, i.e. the arrows that link one state to the other. States and transitions are always tweakable, open to comments, or deletable at any point. To make them “active” and functioning, defining some mandatory, univocal properties, such as a name and a type, is necessary. If the designer forgets to fill these information fields, the dashboard will display an error message.

So Visual Dialog is not just a board with which it’s possible to design a flow: the blocs and the arrows are themselves part of the functioning logic and the code, whose consistency is constantly verified to be ready for implementation.

In conclusion, Visual Dialog allows to:

• design dialog flows with a GUI, without writing code;
• easily prototype a conversational assistant, complete with all of its main functionalities;
• verify its functioning logic;
• save and export what has been created to implement it right away.

What we have done so far as a Crew is, of course, but a tiny piece of all the work we are planning. Over the next months, we want to actually develop the dashboard to build both our and your projects in the best way possible. In particular, we’d like to:

• develop a prototype with all of the necessary components needed to create automated dialogs;
• integrate it inside of our platform for the creation of digital assistants (Sophia Dialog) to make it accessible via the back office;
• link the various dashboard elements to the underlying code, to make sure that whenever a change is made to the conversational flow, the code itself changes too.