Flag

We stand with Ukraine and our team members from Ukraine. Here are ways you can help

Home ›› Internal Company Systems and Intranets ›› Oh Hi There, Bot

Oh Hi There, Bot

by Vijay Sundaram
8 min read
Share this post on
Tweet
Share
Post
Share
Email
Print

Save

When designing your own Slack bot, you need to keep three UX considerations in mind: discovery, onboarding, and basic interaction.

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.

post authorVijay Sundaram

Vijay Sundaram, Hey there! I'm Vijay Sundaram, founder of Polka Dot Labs. We're a strategy, design and development studio focused on emerging technologies and new ventures. We're based in San Francisco and always up for opportunities to collaborate. Don't be shy about saying hi.

Tweet
Share
Post
Share
Email
Print

Related Articles

Discover the future of user interfaces with aiOS, an AI-powered operating system that promises seamless, intuitive experiences by integrating dynamic interfaces, interoperable apps, and context-aware functionality. Could this be the next big thing in tech?

Article by Kshitij Agrawal
The Next Big AI-UX Trend—It’s not Conversational UI
  • The article explores the concept of an AI-powered operating system (aiOS), emphasizing dynamic interfaces, interoperable apps, context-aware functionality, and the idea that all interactions can serve as inputs and outputs.
  • It envisions a future where AI simplifies user experiences by seamlessly integrating apps and data, making interactions more intuitive and efficient.
  • The article suggests that aiOS could revolutionize how we interact with technology, bringing a more cohesive and intelligent user experience.
Share:The Next Big AI-UX Trend—It’s not Conversational UI
5 min read

Discover how Flux.1, with its groundbreaking 12 billion parameters, sets a new benchmark in AI image generation. This article explores its advancements over Midjourney and Dall-E 3, showcasing its unmatched detail and prompt accuracy. Don’t miss out on seeing how this latest model redefines what’s possible in digital artistry!

Article by Jim Clyde Monge
Flux.1 is a Mind-Blowing Open-Weights AI Image Generator with 12B Parameters
  • This article examines Flux.1’s 12 billion parameters and its advancements over Midjourney and Dall-E 3. Highlights its superior image detail and prompt adherence.
  • The piece explores the shift of developers from Stability AI to Black Forest Labs and how this led to Flux.1. Analyzes the innovation impact.
  • It compares Flux.1 with Midjourney V6, Dall-E 3, and SD3 Ultra, focusing on visual quality, prompt coherence, and diversity.
  • The guide explains how to access Flux.1 via Replicate, HuggingFace, and Fal. Covers the different models—Pro, Dev, Schnell—and their uses.
  • The article investigates Flux.1’s capabilities in generating photorealistic and artistic images with examples of its realism and detailed rendering.
Share:Flux.1 is a Mind-Blowing Open-Weights AI Image Generator with 12B Parameters
5 min read

Is true consciousness in computers a possibility, or merely a fantasy? The article delves into the philosophical and scientific debates surrounding the nature of consciousness and its potential in AI. Explore why modern neuroscience and AI fall short of creating genuine awareness, the limits of current technology, and the profound philosophical questions that challenge our understanding of mind and machine. Discover why the pursuit of conscious machines might be more about myth than reality.

Article by Peter D'Autry
Why Computers Can’t Be Conscious
  • The article examines why computers, despite advancements, cannot achieve consciousness like humans. It challenges the assumption that mimicking human behavior equates to genuine consciousness.
  • It critiques the reductionist approach of equating neural activity with consciousness and argues that the “hard problem” of consciousness remains unsolved. The piece also discusses the limitations of both neuroscience and AI in addressing this problem.
  • The article disputes the notion that increasing complexity in AI will lead to consciousness, highlighting that understanding and experience cannot be solely derived from computational processes.
  • It emphasizes the importance of physical interaction and the lived experience in consciousness, arguing that AI lacks the embodied context necessary for genuine understanding and consciousness.
Share:Why Computers Can’t Be Conscious
18 min read

Tell us about you. Enroll in the course.

    This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and