How Do Designers and Developers Work Together on a Conversational Product?
Hundreds of questions were submitted by attendees of Botmock’s AMA about Techniques for Conversational Design and Development. Five industry experts with backgrounds in conversation design answered as many as we could in a live roundtable discussion. To register for future (free!) AMA sessions and watch the full recording of this session, you can do so here.
The following conversation design experts joined us to answer your questions:
Maaike Groenewege, Conversation designer & coach @ Convocat
Amanda Stevens, Director of Conversation Design @ Master of Code Global
Sarah Storm, Head of Ideation & Conversation Design @ BOOM Integrated
Anna Mackenzie, Software Developer @ Myplanet
Brenda Martins, Conversational Designer @ LogMeIn
We covered the following topics:
As a developer, from a very early stage in the design, I work closely with the conversation designers to make sure that they are not expecting impossible things. The approach is also dependent on the available tools. For example, there’s a difference between building a custom voice experience where I’m working for a big client that has an NLP system, and I have to integrate with the NLP and build a voice experience from the ground up, versus building an action for Google or a skill for Alexa. So yes, the conversation designer must be aware of all constraints from the beginning and be aware of which restrictions or limitations should be considered during the design stage.
I think that once development is underway, successful design is based on a good back and forth. I also feel like I can’t ask someone to build if I haven’t given them a map. The first phases of design are really important, so early paper testing and role-playing are key. I also like to start prototyping as soon as possible. For example, I work on a platform that allows me to plug things in and prototype immediately, so it helps me design as I move forward. With that said though, I have to have a roadmap, I have to know my happy path, and I have to have some semblance of where I expect to require error handling. Another element that we like to define in detail beforehand is persona. We usually need a really strong fun persona so this has to be part of the equation from early on. Make sure you know where you are headed before starting to plug technical stuff in.
I always design first and then develop. Otherwise, it’s really hard to keep track of the flow of the conversational design. Right now I’m developing a bot in a tool that requires no coding, but it still gets squirrely if I don’t know what the flow or map is. So having that design to fall back on is super helpful.
I like to take an Agile development or design sprint approach, which is very popular in software development. I start with a common refinement session where we identify the use case and dive into both the business and technical requirements, limitations, and constraints. With that said, I do find that when I am working on more of a conversational content bot, I tend to make my own plan. Still, even then, I feel it is important to define a solid model upfront and define the entities that we are going to use, and how they relate to each other. A bit of domain mapping is also helpful. It helps to define the scope of the domain that your bot is going to handle. I would like to emphasize that all of these steps are better done alongside the entire team so that all the different perspectives can be studied.
A bit of domain mapping is also important. It helps to define the scope of the domain that your bot is going to handle.
This depends on what you’re being asked to do. I find it useful to have working knowledge of at least one programming language, even if it’s just so that it is easier to talk to the dev team in their language. Also, it is a matter of courtesy to the dev team that when you’re asking them to build you something, you know the level of difficulty of what you are asking them to do. You don’t want to ask them to take you to the moon without knowing what that entails. It is important to know a programming language; any language will help you understand the scope of what you’re asking.
Having design and development being integrated at the beginning and having an overall understanding of how it all works under the hood prevents you from asking the developer to do something impossible and, in consequence, forcing you to have to go back and rework.
In addition to that, you have to know the arena that you’re working on. So what can I do in Alexa? What can I do on Google? What can I do in Cortana? It is important to know each assistant’s limitations just so you have an idea of what is possible.
If you’re just building a basic skill, you can use a no-code tool. Sometimes that is what a client wants. Because it’s their first time they’re dipping their toes into voice and they just want to get an idea of how their users would interact with their brand.
I have no coding experience and I wish I did. If I did, I’m certain things would be much easier. Thankfully, we have a great publishing partner and I do have a game design partner who tends to handle more of the dev side of things. Personally, the language that I found most helpful was all of my playwriting skills and all the with technique things that I learned in school for theater. But I can’t necessarily speak to a dev right off the bat in terms that will make development sense. So it’s helpful to know programming languages. If you are like me and your skills are sort of softer, there’s still room to participate in this space regardless of your coding skills.
If you are like me and your skills are sort of softer, there’s still room to participate in this space regardless of your coding skills.
I think that the most important thing to understand is the logic behind conversational design. I don’t think you need to be able to program in a programming language, but you need to be able to come up with a common language not only to talk to your dev but also to design a logical flow for your chatbot. So as soon as you start working with something like entities, you are already entering the mind of a programmer in the sense that you’re using the same kind of logical thinking that’s necessary to make this work. In that sense, that chatbox is an application that you’re designing rather than just a piece of content. We have to trust that our analytical skills and our language skills know how to ask the appropriate questions; which is something that content creators, designers, and theater people are much better at. So — knowing programming languages? Not necessarily. It’s nice though. I mean, it’s fun, just try it and have a laugh.
There is this great prototyping tool that supports my language (Dutch) as well; It’s called Botmock, I recommend that one 😊. I also like to work with a flowchart and spreadsheet combination and there are several tools that I use. I tend to use mind mapping tools for the upfront modeling that I want to do. For example, when I define entities, I like to make little taxonomies out of them with categories and values, and for that, a mind mapping tool gives you the structure and the freedom at the same time. Same goes for domain modeling when you want to have a high level overview of the topics that are relevant to your domain.
I don’t know if I’m allowed to mention names but I’ll do it anyway. My favorite tools are XMind for mind mapping, Lucidchart for flow charting, and Google Sheets or Excel for spreadsheet. Since I write and design in Dutch, SSML is a tool that I use a lot too. This tool helps me get the pronunciation of my Google Assistant right. Since common Dutch names and words tend to get mispronounced quite often, I have to SSML my way around them. It is a lot of fun.
There are two tools that I like to use. One is Miro Board which is very good for visualizing how the conversational flows are going to go and it is usually what a designer will hand me. In terms of prototyping I like Voice Flow; they keep releasing new features that continue to make it amazing for prototyping and developing. That’s one that I would check out.
I thought conversational design was all about UX and copywriting. My understanding was: build out those user journey flows, your bot persona, your flowcharts or conversation maps, do the testing, and you’re done. But, I didn’t imagine that I would have to do so much research and data analysis. In the last two years at this role, there have been so many instances where clients have come to us wanting a conversational solution and already have the use cases in mind, but once we start looking at data, we find out the solution they are looking for might not be the best way to move forward. Also, sometimes the current state in an automated solution might just be as efficient as is and might not need any adjustment. Data analysis is imperative, it answers questions like: are people currently talking about this use case today? If they are not, why are they going to talk to a bot about it? Before starting any conversational build, we must study the data and make sure that it supports and validates the use case that we’re designing for.
There have been so many instances where clients have come to us and because they want a conversational solution they have the use cases in mind, but once we start looking at data we find out that the solution they are looking for might not be the best way to move forward.
To stay updated and register for future (free!) AMA sessions, you can do so here.
The Botmock team is excited that more of our community members are involved than ever before. 🤗
This article is an expansion of the first topic covered in Botmock’s recent AMA about becoming a conversation designer. You can also read recaps of the other two sections, The foundations of conversation design and Companies are investing in conversation designers.