Having worked through the technical details of building a baseline Slack bot, I’ve turned my attention to the end user experience. In this post I want to reflect on a few foundational UX considerations: discovery (finding the bot), onboarding (learning the bot) and basic interaction (engaging the bot). I’ll share both questions and possibilities in each area, with a bias towards simpler and actionable ideas. Hopefully these thoughts are helpful to both bot creators and platform owners like Slack.

Discovery

The first question that comes up is how do users discover the bot? This is partly a marketing and distribution question about how the bot is discovered and added to the team in the first place, which is addressed by efforts like the Slack App Directory and the “Add to Slack” button. But it’s also a product and user experience question, especially once the bot is added to the team. At this point, the user who added the bot knows it’s there, but no one else necessarily does. So what’s a bot to do? How do the other team members find out it exists?

• Spam ‘em. A natural instinct is to message everyone from the bot to let them know it’s there. After all, the bot does have access to everyone’s handle for a DM or even an email. And everyone loves bots, right? Right! Wrong. Don’t do it. It’s going to annoy some or all of the team, and also create a (hopefully temporary) painful existence for the user who added the bot. I have to imagine platforms will eventually limit or block access to an entire team’s contact info anyway, so it’s not a long-term solution.
• Tell ’em. The bot shouldn’t broadcast its presence to the team but the user who added it can, either explicitly via word of mouth, or implicitly by inviting it to channels. (There may even be controversial approaches to motivate users to do so…but let’s not go there right now. When a bot is invited and joins a channel, Slack automatically sends out a message to its members (e.g. “[bot] joined #[channel] by invitation by @[user]”), which is helpful. For example, XOXCO’s bot Howdy does one better, tracking when it joins and sending an introductory greeting to everyone (see image). The main limitation with all these is that they’re one-time messages that can be easily missed in an active stream.

Tell ’em

• Show ‘em. A more organic approach is targeting bot use cases that inherently involve groups of users, exposing them to the bot’s existence through day-to-day usage. For example, a “standup” bot queries, gathers, and reports status updates amongst agile team members. Alternative, a user can query an “analytics” bot to generate inline charts for a group discussion. These are bot equivalents to organically viral apps, like photo sharing. The challenge here is not every use case fits this profile, so there still needs to be an alternative means of discovery for those bots.

Show ’em

• In-app user list. Slack surfaces the team directory, including bot users, under “Direct Messages” in the side panel. The simple act of seeing the bot pop up there could prompt users to either ask other team members about it or open the DM thread to interact with it directly. This mechanism is less reliable for larger teams or restricted accounts where the team member list is too long, or hidden altogether. Slack could improve this by highlighting new/popular/etc. bots in the side panel to give them a little exposure, or go one step further and create dedicated shelf space along the lines of a “Bots” section. (Of course, this exposure has to be weighed carefully against overloading the Slack interface, etc.)

In-app user list

• In-app global bot directory. An intriguing longer-term possibility is for Slack to create a global bot directory where users can discover and interact with bots even before adding them to the team. Bots could be built with the logical equivalent of a “logged out experience” to demonstrate value to users without any access to team info. And all this could take place directly in-app via something like the dedicated “Bots” section described above. (I’m the first to admit this stuff is way more complicated to execute than to blog about, but my point is there’s exciting potential to discover, try and add bots directly within the app.)

Onboarding

The next question that comes up after users discover a bot on their team is how do users learn to use the bot? There’s a familiar pathway to onboard users who add the bot from a website or the Slack App Directory, but all the other team members don’t necessarily need to visit those places before using the bot. This is a good thing, but then how do these users learn what the bot does, how to use it, and ultimately get value out of it directly from the app?

Is “interaction” even the right frame as bots become autonomous or invisible?

• Bot self-intro. A simple, straightforward approach is for the bot to introduce itself via DM the first time it’s greeted by a user. The bot’s intro includes an overview of what it does, how it works, and requests for any user-specific information, preferences, and other context it needs. This is kind of like a first-time app walkthrough and only occurs once (unless the user wants to redo it). The nice side effect is that this intro is now always available for reference at the top of the DM thread with the bot.
• Bot DM header. Speaking of the DM thread with the bot…the header region at the top of a DM could be ideal space for basic onboarding information. Slack could enable 3rd party bots to customize the header, as it already kind of does for Slackbot. Bot DM threads could then double as a sort of “bot landing page” that provides a basic description and onboarding information. Now, a user would only need to open a DM, rather than figure out if or how to interact with the bot, to get started. This, combined with the in-app bot discovery ideas from earlier, could remove a lot of friction in browsing, learning about and adopting bots.

Bot DM header

• Bot profile. More complex onboarding processes could benefit from detailed tutorials, documentation, settings, etc. These are all things that are pretty poorly served by a DM or commandline interface. Slack could provide bots with a richer GUI-based in-app interface to support these (and other scenarios) by through the bot user profile view/app pane.

Bot profile

Interaction

Now this is where things get really interesting. How do people interact and engage with bots? What makes interactions with bots productive and meaningful? What’s this hip “conversational UI” thing? Is “interaction” even the right frame as bots become autonomous or invisible? These are obviously *huge* questions that’ll take a lot more exploration (and posts) to cover. For now I’ll just touch on a more primitive but essential question for bot interaction: how does the bot acknowledge and reply to a user?

The atomic interaction here is the user sending the bot a message and receiving a reply. In some cases the bot needs time to reply (e.g. it’s doing a heavy processing job or waiting on other slow humans to complete a workflow). In other cases, a bot can reply instantly but may still choose to wait, since replying too fast doesn’t always feel right. This is actually a bit like interactions on mobile, where it’s good form to animate view transitions, and unlike the traditional web, where it’s good form to load pages instantly.

So either way, the same questions arise: How does the bot acknowledge receiving the user’s message? How does it communicate status about what it’s doing? What are, effectively, the bot analogies to pressed state buttons and loading indicators from mobile and web? There are already smart patterns emerging from bot designers and developers:

• ‘Bot is typing.’ A bot can indicate that it “is typing” through the Slack chat interface. This does a good job instilling the feeling that the bot is active and responsive, just like fellow human team members who “are typing”. The bot can use this to both acknowledge a user’s message and indicate working status. Though the metaphor may break down if the bot needs more than a short burst of time. At that point, a more expressive approach like emoji reactions or plain old replies could better communicate what’s going on, how long it’ll take, etc. rather than seeming to be “typing” indefinitely.

‘Bot is typing’

• Emoji reactions. Some wonderfully clever bot interactions take advantage of Slack’s support for attaching emojis to specific messages. Bots can use these to communicate both expressively (emojis powerfully convey feelings and other non-verbal communication) and responsively (instant emoji reactions feel less jarring than an instant text replies), all without text. Emoji reactions and bots are totally made for each other! Here are a couple of my favorite examples in action:

Emoji reactions

React with robot_face after ambiently processing message (e.g. saving link):

React with thinking_face and remove before replying (credit: Wilhelm Klopp):

• Old-fashioned replies. Last but not least is keeping it simple and relying on replies. Perhaps people will come to expect and want bots to reply as quickly as possible, in which case good old fashioned replies may suffice (e.g. “I’m on it” to acknowledge, “Give me a few” to indicate working status, “ok done” to confirm completion). It’s not hard to imagine that forcing the user to wait when there’s no substantive reason could hurt more than help. A great example is Google search, which in a sense is a commandline bot insanely optimized for instant responses.

This is a special time for bot creators and platform owners like Slack (and, most importantly, bot users). This ecosystem is just starting to explore new technology and user experience frontiers, and has years, if not decades, of work ahead. This post only scratches the surface of bot-based experiences—I’ll push deeper in future posts, tracking the progress of my own project(s) as well as the bot ecosystem overall. In the meantime, as always, feel free to reach out with feedback, questions, ideas, or opportunities to collaborate!

Thanks to Jennifer McCormick.

Image courtesy of Vijay Sundaram.