很多产品把通知当成“提醒用户回来”的工具。任务完成发一条评论发一条活动发一条系统更新发一条久了用户就开始忽略甚至直接关闭通知。好的通知不是越多越好而是在正确的时间把用户真正需要知道的信息用合适的渠道发出去。通知设计的核心不是“我想告诉用户什么”而是“用户现在需要根据这条信息做什么”。对早期产品来说通知系统不需要复杂但必须有规则。没有规则的通知很快会变成噪音。通知必须服务一个用户动作每一条通知都应该对应一个用户动作。用户收到后是查看结果、处理异常、继续任务、确认订单、回复消息还是回到产品完成下一步如果一条通知没有明确动作它很可能不该发。比如“你的数据已更新”太模糊用户不知道要做什么“你的竞品监控发现 3 个价格变化点击查看差异”就更清楚。通知不是广播。它应该帮助用户在某个时间点做决定。没有行动目标的通知只是在消耗用户注意力。设计通知时可以先写一句话用户收到这条通知后应该做什么如果写不出来就先不要发。按重要性分级不同通知的重要性不同不能用同一种方式发送。最高优先级是安全和支付类通知比如登录异常、密码修改、支付失败、订阅即将到期、退款完成。这类通知通常应该通过邮件发送必要时也可以站内提醒。第二类是任务结果类通知比如报告生成完成、文件处理完成、监控发现变化、自动化执行失败。这类通知和用户价值直接相关应该及时发送。第三类是协作类通知比如有人评论、邀请你加入项目、分配任务、提到你。它们需要及时但也容易打扰应该允许用户配置。第四类是营销和运营通知比如产品更新、活动、教程、召回。这类通知必须克制并提供退订或关闭方式。优先级决定渠道、频率和是否允许关闭。不要把营销通知伪装成系统通知。选择合适的通知渠道常见通知渠道有站内通知、邮件、浏览器推送、短信、Webhook、Slack 或企业微信等第三方渠道。不是所有通知都适合所有渠道。站内通知适合用户在线时查看的消息比如评论、任务状态、系统公告。邮件适合用户离线也必须知道的信息比如支付、安全、任务完成。浏览器推送适合即时性强但用户授权成本高的场景。短信适合高紧急、高价值场景但成本高、打扰强。早期产品通常只需要站内通知加邮件。站内通知记录消息邮件负责关键离线提醒。等用户有明确需求再接浏览器推送、Slack、Webhook 等。通知渠道越多管理越复杂。不要为了显得完整而过早铺渠道。频率控制比发送更重要通知系统最容易出问题的地方是频率失控。一个任务失败重试 5 次发 5 封邮件一个监控对象频繁变化一小时发 20 条通知一个用户被多人评论收件箱爆炸。你需要做频率控制和合并。比如同类通知 10 分钟内合并一次高频监控每天汇总失败重试只在第一次和最终失败时通知协作消息只提醒未读摘要。通知频率要站在用户角度设计。用户需要知道变化但不需要被每一个系统事件打断。早期可以先用简单规则同一用户、同一类型、同一资源在短时间内只发一次。这个规则能避免很多噪音。通知内容要包含上下文和下一步很多通知写得很短但短到没有用。比如“任务失败”“有新消息”“报告完成”。用户看到后还得点进去才知道发生了什么。好的通知至少包含三件事发生了什么和用户有什么关系下一步可以做什么。比如“你的《竞品分析报告》生成失败原因是目标网站无法访问。你可以更换链接后重试。”这比“任务失败”有用得多。通知内容不要太长但要提供足够上下文。尤其是邮件通知用户可能在离开产品很久后才看到。标题、摘要、按钮、支持入口都要清楚。给用户控制权用户不喜欢通知失控。一个成熟的通知系统应该允许用户控制哪些通知要接收、通过什么渠道接收、多久汇总一次。早期产品不一定要做完整通知设置页但至少要让营销邮件可退订让非关键通知可关闭让关键通知保持可靠。不要让用户为了关闭运营消息而错过安全或支付通知。通知偏好可以从简单开始事务邮件不可关闭产品更新可退订协作通知可选择邮件或站内监控通知可设置频率。给用户控制权不是降低触达能力而是保护长期信任。一个最小通知系统结构第一版通知系统可以这样设计通知事件 - task.completed - task.failed - payment.failed - subscription.renewing - security.login_alert - comment.mentioned 通知字段 - user_id - type - resource_id - title - content - channel - status - read_at - sent_at - created_at 基础能力 - 站内通知列表 - 邮件关键通知 - 已读 / 未读状态 - 频率限制 - 同类消息合并 - 营销通知退订这个结构足够支撑早期产品。后面如果用户需要可以再增加浏览器推送、Webhook、Slack 通知、通知模板和偏好设置。总结消息通知设计的目标不是把所有事件都告诉用户而是在用户需要行动时给出清楚提醒。通知要有动作目标、重要性分级、合适渠道、频率控制、上下文和用户控制权。早期产品先做好少量关键通知比发很多低质量通知更重要。通知一旦变成噪音用户会用关闭和忽略来惩罚你。作业列出你的产品中最重要的 5 类通知事件。为每类通知写出用户收到后应该做的动作。按安全、任务、协作、营销给通知分级。设计同类通知在短时间内的合并规则。标出哪些通知必须可关闭哪些必须保持发送。下一节课API 文档怎么写好的 API 文档不是列参数而是让开发者尽快完成第一次成功调用。原文链接消息通知设计 | Harries Blog™