Conversational UI Design and Prototyping with Bottery

Remember last year when everyone was super excited about conversational UI and chatbots? Maybe you were like me and thought “ooh that sounds interesting but no-one actually needs me to design one now… 😦” Well, guess what. 2017 is almost over and I finally had the chance to work on the UX for a chatbot. I mean, I had made fun silly chatbots which spouted random nonsense using markov chains generated from the text of a long running work chat channel. Which was fun. But it didn’t exactly require any “design”.

So this new chatbot is for a client that has a really good use-case and idea. The bot is in early stages of life, but it is available in the slack directory now, and it’s is really buzzword friendly (“machine learning!”, “gamification!”, “computer vision!”). Anyway, it’s actually cool but I needed some way to analyze and improve the UX. There’s a lot of different things to think about, so let’s break down what I’ve done so far.

1. Use the thing

Install it, interact with it, understand why it’s cool, what’s ugly, what’s just half-baked. Also use other competing bots on your same platform so you can see how other people have solved particular problems. The Slack API offers some interesting extras like slash commands, buttons, and dialogs. Know how those work, skim the technical documentation so you understand the limits.

2. User journey maps

Think about the real-world context of a user who is going to interact with the bot’s primary function. Where are they? Are they on their phone? What’s the Job to Be Done? What is their emotional state? What external distractions and competing motivations will you have to deal with during the interaction? Graph it out. Ask questions through documentation.

I found it useful to break down this type of interaction into 4 phases.

  • Desire
  • Initiation
  • Follow-through
  • Satisfaction


This gives you the chance to think about the “happy path” and also see where exactly are the places the user might “exit” the journey too early.

3. Pixels and Vectors

I know this is where designers usually start, but you can now start drawing up wireframes and designs in sketch (or Affinity Designer or Adobe XD) for specific interactions that bring the user out of the chat user interface for things like payment, upgrades, account registration. I like to draw flow lines from buttons to next screens. Creating an invision prototype isn’t a bad idea even though you can’t really type anything into your fake slack windows.


Mocking up the slack windows is important to really give your brain some context and to be aware of how visually jarring it might be for a user to have to transition out of the chat interface to a web-browser and back.

4. Actual Interactive Programming!

This is where it all get’s interesting. Go download bottery from GitHub. Google provides it as an open-source project. It’s a little technical but basically you need to follow the instructions in the readme. They walk you through creating a simple “kitten” bot. The code is all in javascript, so I hope you’re comfortable with that. Remember to provide all those commas otherwise nothing works!!!

It’s a lot like designing a text-adventure actually. Entrances, exits, storing variables. Technically you’re defining a “finite state machine”.

Tip: One other thing the readme doesn’t say is that you need to run the bottery app from a local webserver. Which is super easy if you have node installed. You can open a terminal and type npm install -g http-server then, change to the directory where you downloaded or cloned bottery and run http-server -o.

I started to realize that it was actually useful to go through the practice of writing each prompt and state of the bot. Using it in a real interface makes you understand the tone, makes you think about grammer in a whole new way. It’s personal and conversational, so you have to think about tone in a totally different way than we are accustomed to when writing web micro-content. I decided to make my bot a little funny and sarcastic like K-2SO from Rogue One. This happens naturally as you start trying out all the different paths. You see the need for unique states that respond to the user’s data in very specific ways. English grammar is hard and writing english grammer that is adaptable to even a few variable is surprisingly difficult.

Understanding the different variables you are capturing from the user and writing out consistent vocabulary words for different random injections in the script is important to this phase of design.

We need to think about what we are saying to the user, is it getting stale and boring quickly? The randomness of having the bot pick different words for different ideas during each conversation offers a little bit of delight in each interaction.

chatform bottery