Writing the Script: Conversation Mapping
Industry Problems
Amongst teams most focused on designing conversations with chatbots and game designers, there appears to be little agreement on how to design conversational structures and dialogue. Some teams have no intended meta-structure to the dialogue, utilizing non-linear approaches (Chin and Collinsworth, 2016). These methods, though, can very difficult for outsiders or non-developers to fully understand. Other teams use spreadsheets that indicate triggers for a particular dialogue paired with visual decision trees (see figure below) (Lee, Jan 8 2016, video call). These complex decision trees illustrate the relationship pieces of dialogue have with each other, with directional lines indicating possible paths to other nodes of dialogue based on a user’s action. All of these bespoke methods are often internally developed to serve the particular team’s needs, such as communicating requirements to developers, or providing a tool for copywriters to input dialog. The commonality is that they are all digitally created. Aside from being digital, there lacks a generalizable method for writing conversations that can work industry wide and that is accessible for experts and new teammates alike.
The last, perhaps most concrete problem in designing conversations is detailing what is said and when it is said. The previous methods help to iterate conversations towards greater understanding (Improv) and help teams collectively develop the personality of the chatbot (Bot Persona). What is left is for teams to be able to script the conversations. When implementing a conversational structure, I am compelled to highlight how designers must account for all of the possible paths a conversation can take. The previous help in shaping the context of a conversation and reducing the scope a conversation can take. The overarching task in writing a conversation then is detailing planned conversational paths for the core activities of a chatbot (the Do section of a Bot Persona) as well as how to handle unexpected conversations that users may have with the chatbot. By crafting dialogue carefully, designers can further limit the possible permutations a conversation can cover.
Goal for the Method
A method that best helps in scripting dialogue is one that helps transition teams from a point of empathy to implementing the design. At this point in the design process, teams used empathetic approaches to develop stronger hypotheses of the right kinds of conversations to have and how they might be handled. To move towards design, conversations are made concrete to plainly illustrate the conversational structure of a chatbot. Additionally, as teams build out conversational paths, they will be adding more information and detail. This can include capturing increasingly complex paths users can take, programmatic conditions that determine outcomes and additional algorithms and content systems required to make a conversation possible. An effective design method should be flexible enough to increase in its fidelity of information as teams approach higher conversational functionality. Lastly, teams need a “shared understanding” for what each other is thinking and why (Patton, 2014). To achieve the needs of writing conversations in teams, I propose adopting a physical prototyping method for scripting conversational structure and dialogue.
Challenges for the Method
A constant problem in the design community is incredible gravitation towards creating the highest fidelity prototype of a product as soon as possible (Wellings, 2009). In designing conversations, there is a similar allure because the barrier to creation is so low. In developing chatbots, teams may jump straight into the code and quickly start typing conversations before mapping out their dialogue.
This is not a significant problem in fairly short conversations that may involve three lines of dialogue. The difficulty is that conversational possibilities quickly get out of hand, but must still be designed for. Imagine a standard path with an ATM cash machine: you are asked to enter your debit card, to enter PIN code, select a language, choose the account type your money should be withdrawn from, enter the amount desired, if the surcharge is acceptable, receive your money and finally your credit card. The difficulty in maintaining this structure enters when considering numerable alternate paths at each juncture, how later choices may be affected, handling validation of certain choices, personalization, and the numerous errors that can be encountered for every choice. Moreover, different team members and stakeholders may have conflicting assumptions on how each situation ought to be handled (Snyder, 2012). In scripting conversations for their possible complicated structures, therefore, it is necessary to prototype the entire conversation to achieve consensus for what works.
Prototyping serves as a process for “learning what does and doesn’t work” as well as a “common vehicle for feedback” helping teams work together (Wildman and Durrant, 2013). In the prototyping process, designers “make quite strategic choices in determining the fidelity of a particular prototype for a particular step in a particular project” to focus on the problem at hand (Wellings, 2009). In the case of scripting dialogue, the fidelity that teams need is something that illustrates the high-level structure of the conversation, places where particular dialogue occurs in the conversation, and write what dialogue is said. Lastly, teams need to specify technical components to make each interaction work. Another way of looking at this is allowing teams to tell the entire detailed story of the experience and what is required to make it happen.
Inspiration for the Method: User Story Mapping
User story mapping is an incredible method developed by Jeff Patton, a highly collaborative and scalable method that “keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product” (Patton, 2014). In one paragraph, Patton clearly illustrates how the method works.
“Building a map is dead simple. Working together with others, I’ll tell the story of a product, writing each big step the users take in the story on sticky notes in a left-to-right flow. Then, we’ll go back and talk about the details of each step, and write those details down on sticky notes and place them vertically under each step. The result is a simple grid-like structure that tells a story from left to right, and breaks it into details from top to bottom. It’s fun and fast.” (Patton, 2014)
Even with clear guidance, user story maps become surprisingly complex. They require teams to be mindful of the process ensuring effective collaboration as well as contextual understanding in order to adapt the method appropriately. In understanding this process in a little more detail, I am able explain how this method can be adapted to scripting conversations.
Components of the User Story Mapping Method
To illustrate the user experience, team members simply write the core ‘story’ of what a user does with a service. Each part of the story is written on individual post-it notes and is organized in chronological order from left to right. What is formed is a coherent narrative of what people will experience when using the service. Post-it Notes are important component because as the team builds the story, post-it notes move around. Some are later added earlier in the story, others become smaller components of a bigger piece and are moved below the main story line. After the entire story is told, then the team goes back and looks for holes in the story that need to be filled. More post-it notes are added, some are moved. This continues until the team feels the story has been fully captured.
Once the story is completed, the team goes to the beginning and, beneath each part of the story, adds necessary details to make each respective part work. These details are the service’s functions, features and components such as images, forms, and databases.
Finally, the team prioritizes. Every project has some kind of time, energy and money constraint. Therefore, it’s important to triage what is absolutely necessary for the service to achieve it’s goal. Priorities are broken up into several release cycles. First, teams prioritize which specific parts of the overall story are core to what user’s need and to the goals of the service. Then details are prioritized based on what is achievable. There is a little more finesse and strategy for determining prioritization with user story mapping, but this is sufficient for our understanding of the method. After the entire process is completed, teams are left with a shared agreement on the overall vision of the service and what will be achieved first.
Conversation Mapping
User story mapping is an incredible method that could successfully meet the needs of Conversation Mapping. I am adopting the word mapping instead of “scripting” to emphasize how pieces of dialogue can “hold information… either intrinsically or [extrinsically] by virtue of their position” when spatially organized into flows and patterns (Gray, 2010). In order to successfully map conversation, two modifications to are required to the user story mapping method. One is what to write on the post-it notes. The other is how to capture the branching paths that conversations can take. These modifications are perhaps particular to the design and programing of dialogue for chatbots.
In user story mapping, each post-it note represents an individual plot-point of the larger user experience. In conversation, identifying singular moments ignores that at least two people are participating in a conversation. Let’s imagine generic dialogue without looking into the logic and implicature that people make in cooperative conversation (Grice, 1975): while participant A is saying something, participant B is hearing. Then, the roles reverse, participant A is hearing while participant B is hearing. In cooperative conversation, there are more than statements – individuals also ask things of each other to gain more information. Back to our conversation, participant A says something, and participant B can ask something, or say then ask something. Without interaction between the participants and the exchange of information, there would be no progression in the larger conversation. Viewing dialogue in this detail, we can understand how exchange is what constitutes a complete moment of a user’s story. Simply, we can describe a single part of a story as collection components as Hearing something, Saying and/or Asking something. To make this practical in the mapping exercise, each component is listed on individual own post-it notes.
In the user story mapping method, teams are working with just one user’s story. In scripting dialogue, I similarly suggest designers adopt the perspective of just one participant’s perspective of the conversation, however adopting the perspective of the chatbot. Bringing back the previous example, participant A best represents the user and participant B best represents the perspective of the chatbot. This structure strategically orients designers to shape all of their dialogue into a user-centric position by default, as chatbots will always responsive to what users are saying.
The development community around chatbot design has also arrived at a similar perspective. BotKit is a widely popular open-source framework for people to build conversational chatbots for messaging applications, initially for the program Slack, but also for Twitter, SMS Texting, and many more. Ben Brown, lead for BotKit, was inspired by Grice’s Principles to build the code semantically to reflect how humans cooperatively communicate (Betaworks, 2015). The labels Brown chose for the primary functions for BotKit as “Hear”, “Reply”, and “Ask” (Brown, 2015).
These functions translate directly to conversation mapping by providing a mechanism for designers to add detail to dialogue components. In programing, a function is something that encapsulates a task (Germain, 2008). For an extremely simplified example, in the function hear(“I want a banana”), the function is called hear and the task of the function is listen for the phrase “I want a banana". The task does not need to be text, but can also be a conditional statement. For example, in the function hear(“banana”, “apple”), the function listens for either word “banana” or “apple”. Knowing the requirements allows us to build a more inclusive method.
Teams may detail the intention for the function in each component. For example, there are many variations of “hello” that a chatbot can Hear, but can Say the same dialogue in response. On a conversation map, the post-it note for this Hears component could be written “Hear Variations of Hello”. Instantly, the team knows that, when building this “Hear Hello” component later, the team needs to write a list of variations for this function that all trigger the same Say response. Incredibly complex functions and processes can be integrated on one post-it note by simply listing its intent. Both the components of conversation technological requirements to building conversations and are now wonderfully aligned. Therefore, it is pertinent that conversation mapping incorporates these three components of dialogue so whole teams can equally participate.
The challenge in illustrating branching conversations is their nonlinearity, considering the possible outcomes that could be taken. The primary horizontal axis for user story maps, however, is a linear timeline. When users are given the opportunity to make decisions in a conversation, teams need to be able to design what happens for all outcomes. This is the core of designing conversational structure, planning how a conversation resolves all or particular goals. To successfully map conversation, teams need to be able to illustrate these particular paths clearly. User flow diagrams are a popular tool designers use to map possible outcomes a user can take (Singer, 2009). A simplified user flow diagram is a flowchart comprising of decisions that users makes and the possible outcomes for the choice. Choices can also be conditions that the user meets. By chaining decisions and outcomes, designers are able to communicate all of the choices a user may make and what happens next. The final diagram helps teams understand all of the different states that need to be created.
To modify user story mapping, I suggest teams organize their post-it notes to reflect the branch in conversation, just like in a user flow diagram. In user story mapping, we add story components left-to-right. However, there is a particular order in placing that may significantly helps the process. In User Flow Diagrams, everything begins with the choice or condition. For conversation mapping, the choice or condition is represented by the Hear dialog component. Recall how Hear reflects a user action, something the user stated to the chatbot. For every Hear, we add a Say. If there is a branch in the conversation, an Ask is appended. The three together form one point in the story. To indicate a branch, possible Hear’s are stacked vertically, to the right of the originating Ask. Then the process continues until the conversation is complete.
I am anticipating that there are some conversation paths that would be difficult to visualize the manner I illustrate above. In particular, looping paths or massive and complex conversations would both be difficult to construct. I am less concerned with looping paths. I expect that most situations can be handled by drawing the path with a marker or having additional coded post-it notes indicating where to jump to. For massive and complex conversations, parts of the story may need to be representational rather than fully depicted. For example, above you can revisit Large’s user flow of how the bot handles credit cards. This is a lot to capture, particularly the rest of the flow was included too. Earlier, I discussed how teams need to prototype their conversation in order to achieve consensus for what works. The fidelity and detail that conversation map depicts should simply reflect the shared understanding of the team.
Plan for Leading the Conversation Mapping Method
In workshops, I begin by having teams write, picked from the Do section of their Bot Personas, a sentence that a user may say on one colored post-it note. Then the teams write something their chatbot may say in response on another colored post-it note. With these examples, I teach teams how the user’s sentence is something that the chatbot can Hear, while the other is what the chatbot Says. Then, all participants are encouraged to open their bot’s configuration code and add the contents of their post it notes into their respective spaces in the code. After everyone’s chatbots are appropriately responding, I introduce Ask and how to structure conversations with multiple outcomes. On a wall, I verbally talk through a simple conversation while illustrating how teams can map their dialogue. Next, teams map out their own conversations, working with each other to see if particular lines of dialogue fit their Bot Personas. Finishing up the section, teams enter their conversation maps into their bot’s configuration code and experiment with the interactions as users would.
Assumptions and Testing Criteria
This method will be successful if teams feel confident and capable to map conversations collaboratively, then quickly be able to transfer these designs into effective chatbots. Conversation mapping is trying to address the problem of teams not often having experience structuring conversations, particularly non-linear conversations, in such a literal way before. Because they lack experience with this mindset, this method intends to help give structure to their prototyping process in identifying what needs to be said and when it needs to be said. I am assuming that teams need a method to help make team’s ideas of their conversations concrete and that, from not completely understanding each other’s thinking, there might be conflict in resolving the best step forward. I am also assuming that, because they are inexperienced writing non-linear conversations and the programing structure, this physical and structured method can help transition teams from design to code.
To address these concerns in a workshop environment, I have collaborated with two programmers to simplify the programing as much as possible. We created a semantic programing framework that colloquially and visually looks similar conversation mapping. This helps even the most novice programmers enter conversation maps into functional code.
Bibliography
Betaworks (2015) Notifications summit: Session 8. Available at: http://techcrunch.com/2015/10/21/notifications-summit-session-8/ (Accessed: 4 February 2016).
Brown, B. (2015) Building blocks for building Bots — why not?. Available at: https://medium.com/why-not/building-blocks-for-building-bots-b053b0d7e2e#.t7wzrj72i (Accessed: 4 February 2016).
Chin, J. and Collinsworth, B. (2016) ‘Interview with Joanna Chin and Bryan Collinsworth’. Interview with 21 January.
Germain, J. (2008) Programming – Topics. Available at: http://www.cs.utah.edu/~germain/PPS/Topics/ (Accessed: 4 February 2016).
Gray, D., Brown, S. and Macanufo, J. (2010) Gamestorming: A playbook for innovators, rulebreakers, and changemakers. United States: O’Reilly Media, Inc, USA.
Grice, P. (1975) ‘Logic and Conversation’, in Cole, P. and Morgan, J. (eds.) Syntax and Semantics 3: Speech Acts. New York: Academic Press, pp. 41–58.
Patton, J. (2014) User story mapping: Discover the whole story, build the right product. United States: O’Reilly Media.
Singer, R. (2009) A shorthand for designing UI flows. Available at: https://signalvnoise.com/posts/1926-a-shorthand-for-designing-ui-flows (Accessed: 4 February 2016).
Snyder, C. (2012) Using paper prototypes to manage risk. Available at: http://www.uie.com/articles/prototyping_risk/ (Accessed: 4 February 2016).
Wellings, P. (2009) Beyond prototype fidelity: Environmental and social fidelity. Available at: http://adaptivepath.org/ideas/beyond-prototype-fidelity-environmental-and-social-fidelity/ (Accessed: 4 February 2016).
Wildman, G. and Durrant, N. (2013) The politics of Prototyping. United Kingdom: Lulu Com.
Last updated
