2014年8月19日上午11:46，Slack的首席执行官Stewart Butterfield创建了一个名为#feat-rxns的新频道，并邀请Slack团队的一些成员加入对话。这个频道的目的是在Slack中建立两个新功能。**表情反馈和Threads**。3年多以后回过头来看，这两个功能被合并到一个项目中可能听起来很奇怪，但当时听起来这两个功能都没有大到足以支撑一个以上的频道。它们都围绕着同一个想法：对信息做出反应，用文字或表情符号。
这就是设计Threads的故事，我们低估了它的复杂性。这也是对Slack设计过程的深入探讨。
Threads 是我们要求最多的功能之一，但我们很早就意识到，"在Slack中拥有thread "可能意味着很多不同的东西。我们日常使用的大部分工具都以 threaded 对话为核心。Facebook、Twitter、Reddit、YouTube（当然还有电子邮件）。然而，它们各自有不同的方式来处理这一功能。
当时，Facebook的帖子每条都只有一条长长的评论线，按日期排序。在Twitter上，任何一条推文都可以有众多的直接回复，这些回复也可以有回复无穷无尽。Reddit，对待回复及其可见性也略有不同。那么，哪种方法才是适合我们的呢？
在所有这些不同的系统中，我们想先了解人们是如何理解 threads 在 Slack 中的意义。当时，Slack还不到一年的时间，如果快速迭代一些东西看到用户反馈，那是很有意义的。但Slack在没有threads的情况下运行得相当好，所以我们决定花时间去琢磨一个能给人们使用Slack的方式带来最大价值的模式。
在Slack，我们非常自豪的一点是，对于我们构建的每一个功能，我们都会在自己身上试用，然后再向公众开放。我们鼓励每个人提供关于新功能的反馈，无论你是公司里的谁。**通常情况下，最有价值的反馈来自于不知道这个功能是什么的人，因为他们会以最坦诚和最真实的方式体验这个功能。**这个系统也为设计团队提供了一点回旋余地：如果我们对某件事情没有把握，我们就尽最大努力去做，看看效果如何。
这个过程对于Threads来说是至关重要的，如果没有看到真实的人如何使用它，就不可能验证我们的任何设计决定。我们在内部发布了6个主要版本的Threads，每次都能得到宝贵的反馈。每一次的发布都是必要的，以便了解什么是无效的，什么是有效的。
我们决定基于与Twitter相同的模型开始对Threads的第一次探索，因为它看起来是最灵活的解决方案。设计遵循了以下规则。
这是我们心中的一个例证。
有了这个系统，你可以在频道中同时发生多个对话。我们喜欢第一种方法，因为对话被保留在频道中，并且回复与普通消息的规则相同：它们会将频道标记为未读，而提及会触发频道上的提醒。我们需要做的就是确保回复有明确的标签，这样就不会降低正常的阅读体验。
第一个版本的主要问题是，当你打开一个 thread 时，你会遇到 "展开"的效果。因为我们是上下推开消息来显示 thread 的，所以在关闭线程时很容易失去之前所在的位置 —— 尤其是当你阅读线程时总是会滚动一下，而关闭 thread 会让你处在频道中一个完全不同的位置。这对我们来说太过混乱，以至于无法判断这个功能的其他部分，所以这个方案算是黄了，我们需要继续探索。