Exciting Times!
Just like with any emerging technology, as the conversation design field grows in maturity, diverging views emerge when it comes to the initial approaches, tools, and artefacts that have dominated the ecosystem so far. Each alternative inevitably invites debate, as new ideas are pitted against the prevailing ones, and their benefits and disadvantages weighed. This is a good thing! It means the field is growing, opening up to new possibilities – broadening the scope of what was once possible to new ways of thinking. These are exciting times!
One such debate is around the utility of flow-based diagramming for conversation design. The thread on Kane Simms’ recent LinkedIn post has a wealth of different insights into how different subject matter experts think about flows and flow diagrams. In this article, I’ll explore what exactly are ‘flows’, ‘flow charts’, ‘diagrams’ and ‘maps’ and how they fit into the process of creating sophisticated conversational applications.
So: flow or no-flow? Neither and both would be my answer. It depends on what you consider to be a ‘flow’ in the first place and in which context.
This is not a flow
Do flow charts flow well?
Before we start diving into the discussion of flows versus no-flows, we must clarify exactly what we are talking about.
A conversation is an informal talk involving a small group of people or only two, exchanging information, sentiments, observations, opinions, or ideas.
For this article, we’ll extend this definition to include conversations between a human and a machine.
A flow is a smooth, uninterrupted movement or progress.
A flow chart is a diagram that shows the connections between the different stages of a process or parts of a system.
If we stick to these standard definitions, we could conclude that a ‘conversational flow’ is the successful outcome of the conversational experience design, whereas a ‘conversational flow chart’ would show the connections between the different stages of that experience.
Flow charts are, therefore, what we call in the design world ‘design artefacts’. The role of a design artefact is to enable designers to frame their thinking around the problem they are trying to solve and support and communicate directions of thought to other audiences like stakeholders, developers, etc.
They do a great job showing the connection between different stages of a conversational experience, thanks to connecting lines or other visualization techniques such as comments and annotations. We can also use them to showcase a possible ‘flow’ amongst many.
As they currently exist in most tools, the problem with these flow charts is that they are primarily represented in a linear fashion, reducing the opportunity for conversation designers to think about the conversational experience in a non-linear fashion.
If we want to use flow charts to represent our design intents, it might be worth exploring other more non-linear models, like the one below.
This is also a flow chart
Design artefacts should serve the audience they are intended to communicate towards. When it comes to showcasing early design decisions, are flowcharts or GSheets the best way to demonstrate a conversational experience? If that is the preferred presentation model in the company you are working for/with, they might be.
I, for one, still believe that the best way of showcasing the benefit of a conversational experience and its expected outcomes is actually having the conversation. In my experience, sample dialogues played out are the most powerful way of giving a stakeholder audience insights into what to expect from the conversational experience you are designing. From table-reads to audio prototypes, these are the most efficient and straightforward representations of ‘flow’.
Unfortunately, and this is not proper to conversation design, it is easy to fall into the trap of thinking that the artefact is, in fact, the design. It is not – design artefacts are there to communicate design intent. They are a means to bring others into the conversation about the conversational experience; they are not meant to be a representation of the full conversational experience in and of itself.
Therefore, flow charts in any shape, way, or form can be valuable tools to clearly visualize what the conversational application will be doing functionally and demonstrate its reasoning.
Some tools in the conversation design space do an excellent job at creating a conversation design artefact, be it flowchart-based or end-experience based: Botmock, Botsociety, Voiceflow, etc.
Flows in the eye of the beholder
When you look at the conversational experience from a user’s perspective, the desired outcome is indeed ‘flow’ – uninterrupted conversational progress for the user from the beginning of their conversational journey to the accomplishment of the conversation they meant to have.
Let’s unpack this a bit further.
Are conversational flow and the happy path the same thing?
Let me preempt this by saying that after having audited a plethora of existing live chatbots and users’ interactions with them, I believe that there is no such thing as a happy path. There are, however, users and their desired paths throughout a conversational experience. Designing conversational flows is the process of setting up the framework for users to be able to progress in an uninterrupted manner through the conversational experience, using the paths they desire to solve their problem, answer their questions, etc.
Mapping conversational flows as part of the design process, therefore, is drawing a map of those possible paths of uninterrupted progress – all while being conscious of the fact that it is near impossible to predict the extent to which these will coincide with the user’s reality (even though user research upfront will hopefully have helped you a good way along). Furthermore, we should not forget that users have different conversational styles and expectations. As an example, a neuro-diverse audience will be less likely to want to have multi-turn long-winded conversations and might prefer a very fast-tracked-to-the-point conversation.
In his talk on ‘Product Strategy for Your Best Customers‘, Elad Shani makes this very relevant point. Some users prefer Google Maps as they just want to get from point A to point B regardless of how they get there. Others prefer Waze as they want to get from point A to B using the fastest possible route, avoiding any pitfalls along the way. The same is true for conversational experiences. Some users may want to have a very extensive conversation about a specific topic before engaging in any transaction, while others just want to get to the point immediately.
So, are there no patterns then?
No matter how unique we’d like to think each of us is, conversations in given settings do have identifiable patterns. In his deeply researched book ‘Studies in Conversational UX’, Robert J. Moore clearly identifies conversation types and styles and introduces reusable UX patterns of common conversational activities.
Further research in the conversational analysis field has identified many possible patterns throughout the conversational context. I highly recommend reading ‘Talk’ by Elizabeth Stokoe for a deeper understanding of the field and its insights.
Patterns, in essence, are maps of how conversations unfold in a given context for a given sequence.
Linear paths, however, fail to capture patterns, as these patterns have multiple possible pathways. Also, although most users might adhere to a similar pattern, users can take shortcuts throughout a pattern depending on the user context.
Let’s look at a welcome conversation: new users will tend to take the more extended pathway through exploring the ins and outs of what is possible with the conversational application, whereas seasoned users will likely get straight to the point and ask their questions.
Content anyone?
To make things even more interesting, we also need to consider the content available on the conversational application or business side. When developing enterprise chatbots, for example, the amount of content that is available to use in the conversational application can be simply overwhelming.
It quickly becomes apparent that you need a system that allows you to map conversations and content in context.
Nothing new under the sun
Information Architecture
For any seasoned interaction designer, navigation design, information architecture and network diagramming are key disciplines to map the user experience and content in context. As conversation designers, there is a lot we can take away from these disciplines and how they translate into conversation design when moving from design artefacts that showcase the experience to the actual complete design of a conversational application.
Information architecture, in particular, is fascinating. Indeed, one might tend to think about ‘conversational flows’ as linear paths from A to Z, with some alternative approaches for error repair – for example. In which case, ‘information architecture’ seems overkill as the information is shared on a ‘need to know’-basis. On the other hand, pure NLU experiences might leave the impression that no information architecture is needed as supposedly all information is at the same level, available ‘on demand’.
Yet, never has information architecture been more critical than when it comes to making sure a user gets to experience uninterrupted conversational progress. When a user lands in an on-demand experience, how will they know what they can demand? Should they be able to request anything at any time? Is some information more apparent than others from a business perspective and from a users perspective?
Rather than a linear path forward, we should consider different possible ‘conversations to be had’ around a high-level use-case. Thinking in terms of conversations to be had, as well as the context of use, and users, allows for a more dynamic conversational model and subsequent experience. This is the design approach at the core of OpenDialog.
Conversational spaces
In his book, Making Conversation, where he deconstructs human conversations, Fred Dust describes conversations as an exchange between participants in a set space in a given context, with a set of pre-agreed rules.
Designing conversations for Fred Dust means setting up the space to have conversations and clearly defining its rules.
The same is true for conversational applications. They are, in essence, a space within a context where conversations take place. Therefore, designing conversations can be seen as setting up the space and the rules, within the context, for the human-machine interaction within which different conversational paths can unfold.
Mapping out the conversational space
An interesting way of setting up the space for conversations to take place is creating a conversational map. Conversational maps as design represent the overall conversations to be had and dive into the context within which a conversational engine would consider these conversations.
These conversations to be had are based semantically on the conversational user journey and mapped out further based on the available content on the business side.
The advantage of conversational maps is that they are easily scalable into the actual design of the experience. They set up the semantic space to tie NLU components together.
As a conversation designer, you might or might not be responsible for mapping out and training the intents on the NLU side. That is a debate for another day…
Conversational maps enable conversation designers to set up the framework for the conversation down to the intent level. This makes for an excellent foundation for collaboration with NLU experts and developers.
In short
My goal for this article was to clarify the terms flow, flow chart and showcase how they fit into the process of creating conversational applications.
Users engaging with a conversational application enter into an interaction with a machine that has a specific knowledge set to have one or a set of desired conversations.
Conversations, in essence, have patterns yet remain unpredictable as to which pattern will be followed by the user and in which context.
Flow charts are design artefacts that can showcase possible conversational paths or patterns yet are not to be considered as the full extent of the conversation design.
Conversation designers can not predict the full extent of possible interactions, despite extensive user research.
Flows should be considered not as predetermined paths from a conversational application perspective but rather from a user’s perspective as the ideal outcome of the conversational experience, enabling a continual progression of the conversation for that given user in their given context.
Considering conversation design as setting up the space for different conversational flows to unfold is a more sustainable approach.
Setting up a conversational map can lean heavily on information architecture, closely intertwining user’s conversational journeys with available content on the business side – therefore allowing conversations to flow freely within a set conversational map.
