Among the many magical things we do here at H-FARM Innovation, we create digital assistants (also known as conversational agents, voice assistants, etc.). What are they? Digital assistants are agents capable of matching brands with their audience in an automated, innovative way, using advanced language processing technology. You can find more about that on Sophia Dialog, our proprietary platform with which we create digital assistants, following this link.
Some complex dynamics lie underneath these kinds of projects, going from the design of a conversation flow to its eventual implementation. When the flow becomes “important”, as we will clarify below, optimizing the work of designers and developers becomes truly challenging, and we are often faced with the eternal problem of digital projects — which is precisely to let designers and developers work together peacefully. Who designs a product (i.e. the designer) usually has a different perspective and priorities than the developer who actually builds it. And so, translating an idea into a viable product can be genuinely hard.
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:
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:
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:
