Thoughts on building bots and buildings
This question came from a recent Q&A at Slack:
Q: Every week it seems like a new article is published saying that bots are the future, or that bots are dead. How does Slack respond to the constant media fluctuations without constantly changing course?
For the answer, let me tell you about a time I embarrassed myself in front of Slack leadership. In June of 2015 I had just joined Slack as a PM on the Integrations team, and all ten of us held an offsite at our Vancouver office to imagine the future of Slack’s platform.
To help prove the value of the early platform quickly, all ~80 Slack apps that existed at that time had been built by us, and there was no real self-service option available. At the offsite, we discussed existing problems like this and brainstormed a bunch of potential improvements we could make.
We came back from the offsite excited about the future of our platform. I put together a deck illustrating our grand vision for a world in which every app on Slack is a bot, and how those bots would be defined and made available to our customers. I pitched it, and asked for feedback.
Our CEO Stewart’s emphatic answer was: no. Bots were not the future — at least, not the only future, and definitely not a basket that he wanted to put all of our platform eggs into.
Many tools already connected with Slack but didn’t need an anthropomorphic identity to get the job done. Document and file apps don’t need to talk to you in order to expand your links or let you create docs from Slack. Workflow apps (like employee approval, task management, or project management apps) should be as invisible as possible to get the job done.
Yes, some apps would want to represent themselves as bots (and some of our most successful ones do, like Howdy, Polly, and Hubot), but we didn’t want to limit ourselves to this particular metaphor for the entire platform. We didn’t know what the future of human-to-software apps would look like and wanted to leave it as open and flexible as possible.
Fast forward two years, and the nuance of this distinction is still rippling out into the messaging platform community. Slack has an App Directory, not a Bot Directory. Instead of making everything a bot, we built tools to simplify bot development (like the Events API) but also tools to simplify app user experience within Slack channels (like buttons and menus and more coming soon). We love bots, but think the real value is in how software integrates with human conversations — whether or not it has a robot face.
The rest of this post will attempt to unpack that distinction.
Software and architecture
In the history of software, we’ve spent most of our time bending over backwards to accommodate software’s ways of thinking. Command-line tools, query languages like SQL, and even tools like spreadsheets, CRMs, and project management apps have required humans to learn the language and interaction patterns of computers.
This spectrum shares some similarities with another domain of engineering: architecture. Take the beautiful Southern Bell Telephone Company building, in Atlanta, Georgia:
Look inside and you’ll see a very logical and mapping of task and human.
It’s possible to map different architectural styles, and office floor plans, to a spectrum as well:
Telephone switchboard operators, production lines in factories, and cubicle workers in offices all benefit from a certain human + architecture harmony. The computer-friendly and factory-friendly options are highly structured, organized, and designed for optimal efficiency. There’s no denying that this harmony leads to higher productivity in some cases.
It’s a testament to our flexibility as humans that we can contort ourselves into this highly organized software and architecture in the name of clarity and efficiency. It was even our idea! The price of this harmony is not zero, however. In order for everything to fit together in this shape, the human element must be compromised and we lose some of the messy magic that makes our brains and spirits so creative, inventive, and happy.
Efforts to make work spaces more human friendly, like open floor plans and remote work, are arguably still a bit less predictable in their effectiveness — some people hate them, others love them. Sometimes they work in harmony, sometimes they explode in discord.
Is it possible to have human + software + architecture harmony on the human-friendly side of the spectrum? Is there some way to harness the benefits of alignment of humans and tools while also encouraging our messy, creative, collaborative sides to express themselves as well? It will take iteration and new inventive software and architectural designs to bring efficiency and harmony to the right side of the spectrum.
Let’s look back at how architecture has addressed this. As our understanding of architecture has evolved, we’ve identified other points at which human + architecture harmony can be achieved. Consider the architectural trend of homes built to complement and enhance the natural landscape: organic architecture. Frank Lloyd Wright’s Fallingwater is a famous example:
Notice that instead of trying to avoid the rocky terrain and slippery streams, it sits perched on top of the waterfall. There, it benefits and becomes stronger by its proximity to the very things that would be considered insurmountable problems to other styles of architecture.
The philosophy of organic architecture has a lot of parallels to human-friendly software design. Human + software harmony has begun to tentatively explore a similar direction. Just as diverse terrain in nature challenges architecture to meet it where it is, the messy world of human communication has challenged software.
Human-friendly software
The hype and hope of bots is that they might be our ride to a more human-friendly software world. By being more casual and easily integrated into conversations, it doesn’t seem like a huge stretch. But like open workspaces and remote work, we still have some kinks to work out.
Communication is one of our most fundamental human needs. Slack is attempting to live as close to the messy source of communication as possible — right on top of the waterfall, even — and provide the foundation for others to also build on it in a meaningful way.
What does that mean, practically speaking, for people and businesses building on messaging platforms like Slack?
Here are some tips for creating a user experience that integrates with, rather than disrupts, your customers’ natural flow of work.
1. Introductions and onboarding
Onboarding matters. At many companies, it’s a good practice to take newly hired people out to lunch with the team to help ease the transition before diving into work. Similarly, when introducing a new Slack app to a team, borrow from conventions around how new humans are introduced to a team: find a buddy who can help introduce you to the right channels and people at the right time.
💡 One idea: encourage your app’s installer (they’re your champion) to create a new channel and invite people to test the app in a friendly, low-pressure, and non-disruptive setting.
Let’s pretend you just installed Ideabot, which is an app that lets you save and vote on ideas from within Slack, and that you’ve already had a chance to learn what it does and how it works. Then the app says:
🤖: Now that you get the gist of how I work, can I recommend a good way to introduce me to a small set of people on your team for testing purposes?
[Yes please!] [No thanks]🤖: Here’s what I recommend. Create a new channel,
#ideabot-test, invite me to it (type/invite @ideabot), paste the message I’ve shared in there (edit it however you like of course), and invite 3–5 people who you think would be interested in getting better at making accurate guesses. Intro message: Hello! This is a channel for testing this new app, @ideabot, that I think you’ll find useful. To save a new idea, just type/idea [your idea]. Then type/idea Test Ideabotto save the idea (and invite me to the channel if I’m not already in there).In the new #ideabot-test channel:
Buster invited Ideabot, Liza, and Zach to this channel.
😃: Hello! This is a channel for testing this new app, @ideabot, that I think you’ll find useful. To save a new idea, just type
/idea [your idea].😃: /idea Test Ideabot to see if it’s useful for us.
🤖: 💡 You saved your first idea, Buster! Here it is: …
Letting your installer do the work of creating the channels, cutting and pasting the messages, etc, is not an accident. It lets them customize it and speak in their own voice, which is a voice that people on the team trust more than a brand-new app.
2. Private vs public conversations
Think about the different ways we interact in one-on-one settings and in groups. In settings like direct messages, you can personalize your communication to the preferences of an individual (consider their time zone, language preferences, preferred styles of communication).
In DM:
🤖: Would you like me to send you a digest of activity on new ideas?
[Once a day at 9am] [No thanks]
On the other hand, in group settings like public channels, be courteous about when you interrupt the flow of the conversation, and make sure your messages have enough context for everyone in the channel to understand why you’re there and what you’re doing.
When a person initiates an action with your app in a public or group Slack channel, consider working with them individually (perhaps with ephemeral messages, which are only visible to that user) to ask clarifying questions or to preview your response before posting publicly to everyone in the channel.
In a public channel:
😃: /idea Fitbit for dogs
🤖 (Only visible to you): I saved your idea: Fitbit for dogs.
[Edit] [Share in channel]
When you do post in a public channel, post the minimum amount of context needed.
🤖: 💡 Buster saved a new idea and wanted to share it here: Fitbit for dogs.
[Upvote] [Learn more]
Coming back to the architecture metaphor, apps participating in conversations are more like services making house calls and working on site with customers, rather than asking them to drive out to your headquarters to get work done.
So when should you ask a user to drive out to your headquarters / click a link to your website to complete a task? We like to ask: would the task take under 2 minutes, and benefit from happening in the context of the conversation?
If so, the benefit of doing it in Slack and saving them a context switch might make sense. If, on the other hand, the task is a bit slower, like editing a video file, running a sprint planning meeting, creating a new ad campaign, or prioritizing a list of projects for the next quarter, perhaps switching context to your app or website is worthwhile.
The same goes for when the customer is in your product and they want complete a task that involves sharing something or requesting an approval or choice from someone in Slack. Minimize context switching wherever your customer is, and everything will be more pleasant.
To bot or not to bot
Rather than debating whether bots are all hype, or how bots will or won’t change how software works over the next 5–10 years, think about what’s going to be the same in 10 years.
❤️ Communication will still be at the heart of how we work.
🌍 We’ll be in a world even more interconnected with the software we use to do that work.
🤔 People and companies that find ways to best focus individual and collective attention, make good decisions quickly, and avoid needless context switching will continue to have an advantage in life and business.
🏆 Software that helps give teams these superpowers will benefit from living right in the conversations people are having, and in the spaces they work (whether that’s Slack, other products, or physical space).
In 10 years, we’ll probably still be discussing if bots are the future or all hype. Until then, let’s focus on making human-friendly software.
