Designing a chatbot for Slack — Lessons learned
Designing Conversational UX is Hard!
Moodz is a french startup developing a virtual personal assistant helping professionals evolving in intense environments, managing multiple projects or dealing with ever changing deadlines and priorities to better organize their day. Our objective in the coming years is to solve organizational complexity at work, helping people to be more effective and less stressed, while improving corporate collaboration.
Choosing Slack to build a first Beta version was far from being obvious for us. But as we hesitated a lot between a mobile, web or desktop version, the idea of developing our service around a conversational UX emerged and quickly convinced the team.
It seemed to us that it was the most natural way to interact with a virtual assistant. What’s more, the idea of designing a single conversational experience that could be accessible on mobile, desktop and web at the same time (and from day one!) was very attractive. Finally we also thought that designing conversational interfaces would be much easier than designing a more “conventional” mobile or web application… It occurs that we were a bit wrong on this one! Designing a bot and thinking a conversational UX is maybe even harder than for a conventional UX, because of the newness of this field and the scarcity of existing resources, frameworks and good practices! In this post I will discuss these difficulties and share some of the lessons we have learnt while designing our first bot on Slack.
Look for inspiration
The first thing we did before even starting to design any interface was to install a couple of popular Slack bots.
As we discovered the different integrations of these services, we were kind of disappointed: the UX and conversational workflows of most of these bots were hard to understand. A lot of them used slash commands (“/+action)” to execute actions but we didn’t have enough guidance to know when to use them and what they did. In some cases it even seemed to use that the experience and features were very limited.
Despite this first disappointment, we kept looking for new bot experiences and finally found a few of them that were providing a really nice and clean UX (like Troops and Front for example), using the right mix between buttons, text, attachments, NLP (Natural Language Processing), user feedback.
Being able to study the UX implemented in these bots (whether well designed or not) has been really helpful and provided us with plenty of ideas on what to do and what to avoid for our own assistant.
Choose your weapons: slash commands, NLP, attachments and buttons
The second thing we did was to read the full Slack documentation in order to understand what were the different options and tools we would have in terms of UX. At that time, the basic elements we had at our disposal were limited to slash commands, attachments, buttons and of course text messages. A few weeks later, Slack introduced message menus, that we quickly added to our UX design options, as they provided powerful new possibilities.
While very tempting and easy to implement when you have a developer background, it seemed to us that developing a UX based on slash commands would not be intuitive enough for our users. Indeed, slash commands can be very powerful when the “language” and “grammar” of the commands have been learnt by the user, but the learning curve can be long and hard as the user would have to remember not only your commands but also all the different commands from all the different services integrated with Slack… Relying on such UX for a personal assistant didn’t seem scalable for us. This is why we decided from the beginning to think the UX without using slash commands…
Instead of the traditional slash commands, we chose to use some NLP algorithms to drive the conversation with our users (in our case, we used Spacy Libraries). But here again, the performances of today’s most performing NLP libraries were not efficient enough to rely entirely on them. Even though we limited the use of NLP to a few number of predefined use cases, NLP can fail and NLP will fail. This is why it seemed very important to us to integrate the notion of fault-tolerance to our UX, i.e. being able to add a validation step whenever we are not sure about what our user is asking AND making it super easy for the user to validate or modify what has been processed by the algorithms. The interest of implementing a fault-tolerant UX is to limit the frustration of the user, as well as to be able to get the required data to train and improve the NLP algorithms more easily (because you already have the request, NLP interpretation and end result).
Finally, we decided to integrate buttons whenever needed to perform simple actions or to ease the validation / edition of some elements. While willing to favour language and natural discussion as much as we could, we just had to admit that buttons are sometimes much more efficient to perform some well defined actions and of course are costing much less in terms of development. For example, when displaying a list of attachments that can be edited, adding an edit button on each attachment that will trigger an edition flow for this specific attachment is much more performant than trying to use language.
Finding the right balance between buttons and NLP seems to be the key to a fluid conversational UX, enabling a fast learning curve for the user, while being very efficient and flexible.
Workflows are king
As we started to explore the different features to implement in our MVP, we realized very quickly that when designing a conversational UX, discussion workflows (the different exchanges between the user and the bot in order to achieve a specific action) are a very serious topic that need to be addressed separately and in great details to provide a consistent experience to the users.
Indeed, contrarily to more conventional UX interface, centered around screen design, the design of new features for conversational interfaces is all about workflow consistency and how to link what has been said/done to what will follow. For example, if a user makes the following request “Remind me to take 2h to finalize the presentation for investors”, moodz will ask for more precisions about the deadline of this reminder. On the contrary, if a deadline is already in the request “before next Friday”, moodz will trigger an algorithm to check if this request can match with the user’s calendar and will provide him with a different answer. And finally if moodz is not sure about an information in this sentence (duration, task name,…) he will ask for a validation from the user.
After having tried different tools and techniques to design actionable UX we finally settled with the following three step “methodology” for our own design process. We first list the main characteristics of the feature we want to develop (1), we then develop a first version of the discussion workflows (2), finally we design the actual Slack UX (3).
Step 1: List the feature main characteristics
During the first step of our methodology, the goal is to better evaluate the different characteristics of the feature we want to develop. We do this by running through the following questions:
What are the requests that the user can make to trigger the beginning of the workflow ?
The idea here is to think about the different types of request that the user could make to moodz in order to achieve a specific action. Integrating feedback and ideas coming directly from your early users will expand request variety. Ex of requests for our meeting feature include sentences such as: organize a 1h meeting with @Gwen before the end of the week to review the UX workflow / set up a quick debrief call next week with @Vincent and @Mike to discuss about new features, book a meeting with @Hugues and @Gaëtan next monday or tuesday, …
What are the characteristics of the action(s) that we want to enable for the user with this feature?
The goal is to better define the boundaries of the feature. For example talking about meeting organization in moods, we wanted to enable the users to organize one-shot (vs recurrent), internal meetings (vs external), in 1:1 or 1:X, that could be physical or virtual and with anyone within the company (even if the person is not a moodz or Slack user)
What information do we need to launch the action and how do we deal with partial request?
Once we have better defined the characteristics of the feature we want to implement, we then list all the information required for us to actually execute this action. For example, to plan a meeting we would need information about the meeting’s duration, title, attendees, location, and deadline. While listing all this information, we also differentiate the elements depending on whether they are mandatory to execute the action, or not. This distinction between the different type of information is important as it enables us to streamline the discussion workflow with the user.
What are the main states that we will have to go through to finalize the action?
For example for our meeting feature, the goal is to organize a meeting with different people and the states that we will go through are the following :
- Meeting information to be completed (if we are missing compulsory information)
- Slot to be validated (we ask the user to validate a slot suggestion)
- Meeting to be enriched (we enable the user to enrich the meeting, with rooms, notes, …)
- Invitations to be sent
What are the additional actions involved by this particular feature?
This last question aims at defining the later interactions a user can have with this action, based on external or internal trigger. For example in our meeting organization feature, we asked ourselves how to deal with people refusing the invitation. Do we just notify the user that someone has refused the invitation? Or do we offer the user a one-click-postpone option with the notification? If we choose the second option, we need to think specifically about the workflow of this particular action… We then summarize the results of this first step on a slide, that we later use to design the workflows and make sure that we don’t forget anything.
Step 2: Developing a first version of the discussion workflow
Once the first step is validated, we start working on the feature’s workflow. To do so, we inspire ourselves from classical graphical modeling languages dedicated to workflow design (such as UML for example), that we tweak and simplify to fit our needs. The goal is to model the complete discussion workflow of a specific feature and of our bot, in order to identify potential bottlenecks or synergies between different parts of the workflow, and to make sure that every path is leading to a satisfying and coherent final result.
Below is an example of what an UX workflow map looks like for moodz on a specific feature:
Step 3: Designing the actual Slack interface
After having designed the discussion workflows we finally design the actual Slack interface for each element of the workflow, using text messages, attachments and buttons. Below is an example of a UX workflow maps, populated with the actual discussion cards:
We start with simple mockups and iterate multiple times until reaching a cohesive and simple visual experience for each element:
Keep it clean
Finally, I would like share a good practice learnt while developing the first version of moodz and that is about keeping your discussion space as clean as possible for the user.
Indeed, one the main problems when working with discussion workflows is that the conversation space can quickly become crowded with “discussion legacy”: useless and past information, remaining from previous actions. This is especially true when you need to display a list of items, when you use rich attachment pieces or when you want to execute a complex action requiring multiple inputs from the user.
We still encounter some difficulties dealing with discussion legacy but we try to avoid the main pitfalls with the two following tricks:
- When the user has finished an action, we systematically delete the useless information, linked with the execution of the previous action and replace it with a summary or “feedback toast”
We are also heavily using the attachment update feature to create nested workflows within an attachment in order to limit the number of information that we add to the discussion. Using nested workflows can complexify the design of your bot, but it is also a very good way to enable a user to achieve a multi-step action while not losing context.
This is it for this article, I hope that this feedback has been useful for you and will help you to better conceptualize and design your conversational UX. We are continuously looking to improve our methodology and practices, in order to enable moodz to perform even more complex tasks and workflows, while keeping it dead simple for our users. So don’t hesitate to comment and share your experience directly on the article or send a mail at mael@getmoodz.com, I will be glad to discuss with you on this topic.
