Slack 如何重构通知系统

分享到

背景：通知不只是“消息太多”

对 Slack 这样的协作工具来说，通知是团队保持同步的关键机制。但如果设计不够克制，通知也会迅速变成负担。

Slack 在这次重构中的目标，是让用户更轻松地保持知情，同时减少困惑与噪音。团队并不只是改了一层通知设置界面，而是重新设计了通知在不同客户端、不同设置之间的行为逻辑。

Slack 发现，通知负担是许多团队都会遇到的问题。用户加入的频道越多，越容易感到通知行为令人困惑、难以控制。

内部数据也显示，通知相关问题是客户体验工单的前三大驱动因素之一。用户经常不知道如何理解或控制自己的通知设置。

真正的问题并不只是通知数量太多，而是旧系统多年演进后形成了复杂且不一致的架构。

1. 多套相互冲突的心智模型

桌面端和移动端各自有不同的偏好设置系统，选项和行为并不一致。例如，移动端的 “nothing” 与桌面端的 “Off” 含义不同。用户很难预测修改某个设置后会发生什么。

2. “通知什么”和“如何通知”被隐藏耦合

旧系统中，用户想减少推送通知，往往也会牺牲应用内的可见性。也就是说，用户无法单独控制“我想看到什么”和“我希望通过什么方式收到”。

3. 不同客户端状态不一致

设置无法可靠同步。用户可能在桌面端配置了通知，却发现移动端表现完全不同，导致困惑和重复配置。

4. 高级用户能力分散

高级通知控制散落在多个菜单中，缺乏清晰层级。例如移动端的 “badge all unreads” 等功能较难发现，也没有一个统一位置帮助用户理解所有通知选项。

这些问题共同导致用户觉得通知“吵”：不仅因为通知频繁，也因为他们无法确信自己真的能控制通知。

Slack 这次重构的重点，是把通知行为在全平台上统一起来，并用更清晰的选项替代历史遗留逻辑。

主要改动包括：

这意味着，过去的“四套范式”被收敛为一个统一模型，用户只需要理解少数清晰选项。

从用户角度看，新的通知设置更简单。但在实现层面，这次重构涉及大量跨团队协作，包括产品、设计、前端、后端和移动端工程团队。

项目中有许多深入技术讨论，其中不少讨论超过 100 条回复。Slack 将主要技术挑战归纳为三类：

Slack 重新构建了通知偏好的解释方式。

旧的 “Off” 设置在新模型中会被平滑迁移为 “Mentions”，同时关闭推送。这个变化听起来简单，但需要后端和前端紧密配合。

出于向后兼容和可回滚的考虑，团队认为直接在数据库层面把用户从 “off” 迁移到 “mentions” 风险过高。因此，他们采用了“读取时策略”：

团队引入了新的 desktop_push_enabled 偏好项，并让它成为控制桌面端推送是否开启的唯一依据。由于该偏好过去不存在，团队可以根据用户此前是否设置为 “off” 来进行回填，避免打断现有体验。

在新模型中，“off” 会在读取时表现为 “mentions + 关闭推送”。这样，应用内通知和活动在所有客户端上保持一致，而推送通知仍然可以在桌面端和移动端分别定制。

这次重构的一个重要原则，是把两个问题拆开：

旧系统把这两者混在一起，导致用户为了减少推送，不得不影响应用内提醒。新系统则将频道活动、应用内可见性和推送渠道进一步分离，让控制更符合直觉。

Slack 的这次通知重构说明，复杂系统中的“噪音”不一定只来自信息量本身，也可能来自不一致的模型、隐藏耦合和跨端状态漂移。

当一个功能多年演进后，简单地优化界面往往不够。真正能降低用户负担的，可能是重新梳理底层模型：

对协作软件、消息系统和多端产品来说，这类重构的价值并不只在于减少通知数量，而在于让用户重新获得可预测性和控制感。