This is a guest post from the Product team working on the newly released Threads feature.
If you use Slack to work with your team, you might notice a new feature — Threads. You can use Threads to reply to messages, organize discussions, and manage the many conversations that happen in Slack. As one of our most requested features, Threads has been in development for some time, and I wanted to share a little bit about our design process and what we learned.
What are we trying to solve?
At Slack, every product kickoff begins with this question. For Threads, it seemed simple at first: channels can get chaotic when a variety of discussions happen at the same time. We saw threading mainly as a way to provide context, i.e. how can we group conversations in a busy channel, so it’s clear which message someone is replying to?
On paper, our early designs felt good. We built the first prototype in late 2015, and a few versions later, we turned threading on for our own team, Slack Corp.
It was promising at first: everyone started connecting messages in hopes of making conversations easier to follow. And yet, while we’d succeeded in providing context, we didn’t quite get the clarity we’d expected. In practice, Threads made busy channels harder to read, not easier.
With our first version of Threads, we realized two of our initial assumptions were wrong:
- It wasn’t clear when to start a thread.
Because replies appeared in channels, just like regular messages, it wasn’t obvious when to start a thread or post a regular message. Our team did both interchangeably, resulting in a mix of linked and unlinked messages that made it difficult to manage discussions. - Noisy channels weren’t any easier to follow.
We thought linking messages together would streamline conversation. In practice, Threads encouraged people to talk over each other, making channels harder to read.
Imagine a team meeting with a set agenda. The group may discuss a variety of topics, covering one at a time. Now, imagine a meeting where half the room is moving from one topic to the next, while the other half is still discussing the prior topic — both at full volume.
By displaying all replies in the channel, we had inadvertently encouraged additional noise without solving for the problem we set out to address.
Back to the drawing board
By this point, Threads had become so disruptive that we turned the feature off for our team. But when we pulled the plug, something unexpected happened — people complained. Our team had adapted to an imperfect solution and found ways to use Threads to improve how they worked together.
- Engineers grouped discussions around bug reports.
- Customer Experience agents connected customer questions with answers from internal experts.
- Public Relations staff collected press coverage around each public announcement.
- Busy executives responded to older messages when they had a moment to catch up.
As we talked to these groups, a few patterns started to emerge:
- Threads work well in channels with frequent small requests. In these cases, cross-talk was inevitable but conversations were too short-lived to warrant new channels.
- Threads enable people to update important topics posted earlier in channel. Since messages were connected, they formed a chronological record-keeping archive for press clippings, policy updates, and FAQs.
- Similarly, Threads worked well when people needed to chime in after a conversation moved on. Belated replies were easier to follow when linked to the original discussion.
- Threads also encouraged discussions where people might have otherwise shied away from posting in channel, i.e. feedback or questions that may not be relevant to everyone. This, in turn, surfaced insights and helped others stay informed.
These learnings feel obvious in hindsight, but they point to a common problem in product design: some features seem so straightforward that you never actually solve the underlying customer problem. Our initial version of Threads sought to help people reply to each other. But as we iterated, we realized that Threads could help people manage and organize conversations, so that they could work more efficiently in Slack.
Armed with these insights, we knew we were on the right track.
Craftsmanship means taking risks
We arrived at the version of Threads you see today by making a controversial change: we took replies out of channels. You can still start a thread from any message, but now that discussion happens without cluttering the channel. With this change, people came to understand that starting a thread meant starting a separate discussion, and went back to posting normal messages for most conversations.
It wasn’t all rainbows, though. Some people still preferred to see every message, and felt anxious about missing updates. To address this, we made a few important tweaks:
- Anyone can follow a thread, and if you’re @-mentioned (or wrote the original message), you’ll follow the thread automatically.
- All the threads you follow are included in a new view called “All Threads”, which lights up whenever new replies are added.
- You can choose to share a message in a thread to everyone in the channel. When you do, your message appears in the channel along with the original message, and links to the entire thread. This way, people who weren’t involved can see key updates or decisions that might impact them.
The end of the beginning
Message threading is one of the most challenging features we’ve built at Slack, partly because it’s rooted in contradiction: we want to declutter and organize our channels, but we also want to stay up to date on everything. Untangling this knot has been a two year journey, and we appreciate everyone’s patience.
But shipping Threads is not the end of this journey. Like everything we build, there are many improvements we’ll need to make in the months and years ahead. Some of this is already in the works, but many ideas will come from you, so please let us know what you think by tweeting us @SlackHQ or typing /feedback in Slack. And if you like tackling challenges like this, we’re always looking for people to help us make Slack even better.
