How Slack overcame the design challenges of making threaded conversations, including notifications, inline vs. broken-out threads, and more
Harry McCracken / Fast Company :
Context & Ripple Effects
Slack's January 2017 launch of threaded messages — conversations attached to specific messages and surfaced in a desktop 'flex pane' sidebar (the all-platform rollout) — was the end point of a hard design argument about whether chat should fragment into sub-conversations or stay one stream. Fast Company's piece walks through the decisions that got it shipped: notification behavior, and inline replies versus broken-out threads.
The choice mattered commercially within months: by June, Todoist's developers had launched Twist, a rival that treats threading not as an opt-in feature but as the entire organizing principle for asynchronous team communication (Twist's debut).
First-order effects
- Every Slack user on desktop, web, and mobile gains a second reading surface — the flex pane — so teams must now decide which discussions belong in-channel versus in-thread, changing day-to-day message etiquette immediately.
Second-order effects
- Twist's launch validates threading as a wedge against Slack rather than a feature copy, forcing the conversation-as-stream model to defend itself; competitors can now position 'calmer' async workflows directly against Slack's firehose.
Third-order effects
- Threading becomes load-bearing infrastructure rather than a nicety — Slack's later redesigns keep reworking thread response paths (the 2020 navigation overhaul refined ways to respond to threads and mentions), and the 2023 power-user redesign (its biggest-ever redesign) shows the product still being reshaped around managing threaded activity at scale.
The trend: Team chat is evolving from a single real-time stream toward structured, asynchronous conversation trees, with each vendor's threading model defining its identity in the collaboration market.