The Unexpected Design Challenge Behind Slack’s New Threaded Conversations

For years, Slack has known that people wanted discussions to appear in clusters. It just wanted to do it right rather than do it quickly.

The Unexpected Design Challenge Behind Slack’s New Threaded Conversations
Slack’s Vancouver office [Photo: Andrew Latreille, courtesy of Slack]

At first blush, threaded conversations sound like one of the most thoroughly mundane features a messaging app could introduce.


After all, the idea of neatly bundling up a specific message and its replies in one place–rather than weaving them willy-nilly with unrelated items–has been around since the days of dial-up bulletin boards. In one form or another, it’s present in Facebook, Twitter, Gmail, and innumerable other places where people communicate with each other.

But when Slack‘s users started asking for threaded conversations, the company behind the hit workplace collaboration tool soon concluded that the capability wasn’t something it could whip up in a jiffy. It did, however, begin to noodle around with the idea–and try different approaches. And, eventually, to use a prototype version internally while continuing to polish it up for public consumption.

In all, that unhurried exploration has taken nearly two years and around six significant iterations of the prototype, during which Slack usage has grown eightfold to 4 million daily active users. Now the company is finally rolling out threaded conversations–which it logically calls Threads–to every team, including both paying customers and those who use the freebie version.

Threads aren’t just a major new Slack feature. They’re also a case study in how its designers approach product development. The company has never operated under the guiding principle that Mark Zuckerberg once famously summed up as “move fast and break things.” Instead, it has thrived in part because it aspires to offer tools that feel fully baked from the get-go. Its fit and finish resemble those of the slickest consumer apps, in a world in which many business-centric tools still don’t feel like they were designed for use by human beings.

Even by Slack standards, threaded conversations got extra TLC, because their impact is so great and so many people had been asking for them for so long. “Threads are so close to the heart of what Slack is that they might be an escalated case,” says Joshua Goldenberg, head of design.

What Slack ended up building bears only so much resemblance to threading as it appears in other products. “It kind of seems like this is a solved problem,” said April Underwood, Slack’s VP of product, at a press briefing about the new feature. “But not in the context of work.”

How Slack’s new Threads feature works

Inside or Outside?

One of the most fundamental questions Slack faced about threaded conversations was where to put them. The most obvious answer was to stick them in-line with all the other items in a channel. So that’s where the company started. By late 2015, it had a functional prototype; after some additional refinement, it started using this version in-house in its own everyday work.

By putting this rough draft through its paces, Slack discovered that putting threaded conversations inside a channel didn’t so much eliminate clutter as reshuffle it. People didn’t always remember that responses should be part of a thread, which turned channels into a mishmash of threaded and unthreaded discussions. The company’s designers also concluded that one possible approach to tidying things up–showing threads in collapsed form and allowing users to expand them–would cause conscientious employees to obsessively expand conversations to see what was in them.

A prototype version of Threads, with replies appearing in-line

“We could have brought this product to market maybe even a year ago, if in-line was okay,” said Paul Rosania, Slack’s core product lead, at the media briefing. Instead, the company turned off the prototype it was using and began the search for a way to wrangle threads that actually helped reduce cacophony.

The answer turned out to be putting threads alongside the main river of channel messages, in the section along the right-hand edge of the Slack interface—officially called the “flex pane”—that is also home to elements such as search results. When people start responding to a message, thereby spawning a thread, the channel displays a counter of how many replies there are, along with thumbnail images of folks who have chimed in. If you click to expand a thread, it opens up in the flex pane, providing a degree of separation from the main conversation in the channel.

Another design decision the company made in the interest of keeping conversations from getting tangled: The replies in a thread can’t spawn further levels of threaded discussion. “A thread can only hang off a single message, and that’s the entirety of its depth,” says Goldenberg.

Just Enough Notifications

Once Slack had relocated Threads to the flex pane, its designers had other critical decisions left to make. One was how to handle notifications so that people who cared about a thread could keep tabs, and those who didn’t could ignore it. Anyone who posts a message that results in a thread gets notifications about replies, as does anyone who is @-mentioned in the resulting conversation. Other users can choose to receive notifications by following individual threads.


“View All Threads,” a new view accessible from the left-hand channel sidebar, lets people see all the threads they’re following in one place—similar to how Slack already lets you view all the unread messages in all your channels. “It’s an extra layer of making sure that you don’t have to go diving for things within a channel,” Goldenberg says.

At one point during development of Threads, Slack pondered whether to let users cut off a thread by declaring it to be closed–an option that’s available on many message boards that support threading, and is often used to perform tasks such as declaring a tech-support query to have been answered.

In the end, letting people close threads “seemed a little bit too heavyweight,” says Goldenberg. “A little too prescriptive for casual use.”

But even if Slack’s designers didn’t want to encourage anyone to shut down a conversation in process, they did think that some threads would wind down in ways that mattered to people who weren’t part of the discussion. “Sometimes there will be a critical decision that everyone needs to see,” says Goldenberg. The result: Threads offers a check box that lets you post a reply back to the channel as well as the thread. Select it, and the service puts a summary in the channel showing the original message and the most recent one.


That summary is important because the act of putting threads in the flex pane is, in part, a statement that Slack doesn’t expect people to try to keep up with all of them from top to bottom. “We’re moving away from the idea that everyone needs to see everything all the time in a channel,” Goldenberg explains.

Going Public

As it worked on Threads, Slack did some user research and exposed the feature to some of its own partners, such as its PR firm, that spent time inside its internal Slack channels. But the main thing that informed development of Threads was the experience of using it in prototype form and thinking about feedback that the company gets from Slack users–both specific feature requests and more open-ended pleas for new ways to get stuff done and combat information overload.

“We are really immersed in the problems our customers are trying to solve,” Rosania said at the media briefing. “That gives us some clarity about where to go.”

“It can be easy to build something that people request,” added Christina Holsberry Janzer, Slack’s group manager for user research. “But what’s really important is to build what they need.” The lengthy development process for Threads was about trying to accomplish that as thoughtfully as possible. But as the feature reaches millions of users in the days to come, it won’t take long at all until the company knows if it has succeeded.

About the author

Harry McCracken is the technology editor for Fast Company, based in San Francisco. In past lives, he was editor at large for Time magazine, founder and editor of Technologizer, and editor of PC World.