B端产品的消息系统设计

作者杨堃——《决胜B端》作者/B端产品专家

资深咨询顾问，中国科学院大学MBA特聘企业导师并开设产品经理课程。担任多家上市公司、SaaS独角兽公司数字化转型顾问、产品顾问，服务过的客户包括华为、京东、宝洁等企业，“36kr”专栏作家。曾任职百度、慢酷科技等互联网科技公司，对企业数字化转型、应用架构设计、业务中台建设、CRM建设、数据仓库与BI建设均有丰富经验。

本文来自作者正在写作的新书《决胜体验设计》（暂定名）第8章“微交互与设计范式”第3节的内容。

▼

 8.3 消息系统设计 

8.3.1 什么是消息系统

不论是C端产品，还是B端产品，消息通知都是必备模块，承担向用户传递信息的重任。我们在之前章节介绍过，国内软件产品有时候会区分消息模块和公告模块，而国外软件产品并没有公告模块，只具备消息模块（或者一些替代性方案，例如邮件、弹屏通知等）。对于非OA和门户类产品，我建议统一采用消息模块，不要另外设计公告模块，避免增加用户的认知负担。

消息系统和反馈系统并不相同，反馈系统是针对用户行为的响应，而消息系统是用户被动接受信息；反馈系统的反馈信息转瞬即逝，而消息是可追溯的。

一条消息包括以下四个核心要素，分别是推送人、推送对象、推送内容、推送渠道，如图8-30。

图8-30  消息推送的四个要素

推送人是消息的发起方，包括：

• 系统触发：任务完成通知、任务出错通知、业务报表已生成、待办事项提醒、某个用户行为发生（例如有人做了评论、更新了数据）等；

• 人工触发：新功能上线通知、用户给你发送了消息、用户在某处at了你等；

推送对象就是消息的接受方，一般是系统用户。

推送内容可以是纯文本，也可以是富文本。

推送渠道包括站内、站外两类，下一节会详细介绍。

消息系统如果设计不好，会导致糟糕的用户体验，常见的设计问题包括：

• 多个消息组件并存。产品经理本意希望通过不同组件承载不同的消息类型，方便用户理解并使用，然而过了一段时间后，发现这些消息组件被滥用，即便产品经理也说不清楚每类消息组件承载的信息类型和使用场景，从而导致这些功能组件被进一步乱用，给用户造成极大的困惑。

• 消息不分级。消息必须区分优先级，不同优先级的消息要用不同的交互方式、消息渠道发送。如果不做优先级区分，会让用户分不清重点，重要消息北埋没在大量低优先级消息中，让用户错过重点。

• 消息文案不严谨。我见过很多系统推送的消息，在消息头或推送提示中，不描述概要信息，只呈现信息类型，例如，本来可以描述概要“xxx客户访问了yyy”，结果统一推送的是“客户有新的动作，请关注！”，结果用户收到的全是这种没营养的推送，让人恼火。

接下来，我们展开介绍消息系统的五个推送渠道。

8.3.2 消息渠道（1）：站内信（In-APP Notification）

消息系统不仅仅是站内信，而包括多个推送渠道，通过这些推送渠道的组合应用，达到对消息分层、分级，方便用户及时获取正确信息，开展业务工作。典型的消息渠道包括站内信、移动端Push、第三方APP、邮件、短信。

站内信是最基本的消息功能组件，我们常说的消息盒子，就是典型的站内信。

因为站内信是软件自带组件，用户必须打开软件才能使用，如果关闭了软件（不论是Web版本、APP还是桌面客户端），就无法访问站内信。这个特性一方面确保了场景的封闭性：用户在工作状态时才会收到消息通知；但也造成了致命的问题：用户可能会错失重要、关键信息，所以到达率（消息成功推送到达用户并且被看到的比率）属于中等。站内信是必备设计，但消息通知只有站内信是不够的，必须和其他渠道结合使用。

站内信的打开率（用户看到并打开消息的比率）一般为低，用户只会打开感兴趣的消息，忽略其他消息（或是快速把未读消息点一遍消除未读标记，但实际上并不会仔细阅读）。但如果站内信被滥用且没有合理的分类设计，用户面不停产生的大量未读消息，可能最终会弃用该功能。

站内信作为核心消息组件，所有消息都应该通过站内信发送并留存记录，方便用户查阅。

图8-31呈现了两种经典的站内信提示效果。

左图中新消息到达后小铃铛会有角标提示，点击后展开消息盒子，点击后可进入完整版消息盒子。

右图中新消息到达后，会通过磁贴方式弹出，有点像toast，可以设置成自动消失，也可以设置成用户点击关闭，小铃铛旁边同样有角标，点击后进入消息盒子。

图8-31  站内信的新消息提醒样式

8.3.3 消息渠道（2）：移动端Push（Push Notification）

在PC办公场景下， PC版本的系统是一直打开的，用户一般处于沉浸式办公状态。对于核心作业系统，用户主要工作都围绕工作台开展，因此，PC版本的系统，不论是Web架构，还是CS架构的客户端版本，用户都可以有效接收并注意到到站内信通知。

但是在移动办公的状态下，用户并不会长时间打开手机APP，因此需要具备更加侵入式的通知方式，也就是手机操作系统级别的Push能力。苹果系统的推送服务是APNS（Apple Push Notification Service），安卓系统的推送服务是Google的FCM（Firebase Cloud Messaging），产品可以直接对接服务，也可以采用封装了这些服务的第三方工具。

作为操作系统级别的消息通知，用户即便关闭了APP，依然可以收到Push推送，这就保证了消息传递的及时性。但如果Push被滥用，给用户造成过多负担，用户极有可能关闭Push。

APP Push在C端产品非常核心且重要，C端产品的用户激活、唤醒、营销等策略，都需要依靠Push推送做用户召回。C端产品会有专门的运营团队，负责内容推送的策略规划和内容生产。

Push的到达率为中，因为能否成功推送到达，取决于用户的手机终端，以及对推送接受的配置；

Push的打开率为中，如果推送策略合理，例如清晰的摘要文字，合理的推送分组策略，用户还会愿意打开阅读。如果Push被滥用，则和站内信一样，用户会选择忽视甚至关闭推送。

所谓分组策略，是指将将消息按照类型分组折叠，例如采购系统APP，将缺货提醒、交易提醒、互动提醒分类推送并对还未阅读的历史信息做折叠，这会提升用户体验，降低用户的心理负担。

8.3.4 消息渠道（3）：第三方IM

作为乙方独立软件产品的设计人员，对于消息通知可以只考虑自身产品内部场景下的设计和应用；但如果是甲方软件产品的设计人员，就要考虑多系统之间统一的消息系统设计和构建。

在7.2.8小节我们讨论了多工作台情况：在企业中，如果用户需要同时使用几个关键系统，每个系统都有自己的重要消息通知，但是用户不太可能同时打开多个工作台持续关注，为了解决这个问题，需要考虑在企业中将消息和待办抽象、收口进行统一管理，这就需要借用第三方IM的能力。

为了解决上述问题，常见的经典解决办法，是对于重要消息，每个系统除了在各自站内做推送，还需要将消息通过第三方IM的接口，推送到企业IM软件中，例如，SC、和OA和资产系统的消息，都会通过钉钉或者飞书推送给用户，这样保证用户即便没有打开相关的管理系统，也可以收到重要通知。

通过第三方IM推送消息，不单纯是功能问题，还涉及到软件应用架构规划问题，在7.2.8小节已有详细探讨，本节不再赘述。需要注意的是，不是所有系统消息都要通过第三方IM推送消息，建议只将高中优先级消息通过第三方IM推送，避免用户在IM中收到消息过多反而降低效率。

通过第三方IM推送消息，一方面是多系统推送收口的需要，另一方面也可以保证到达率，毕竟员工不一定随时打开业务系统的APP，但手机上都会装企业IM，而所有信息都会在IM中通过Push推送。所以，第三方IM和Push，尽量不要重复推送。

8.3.5 消息渠道（4）：短信/电话

除了第三方IM，重要的消息还可以通过短信的形式发送，确保用户能够及时接受。

在手机刚普及时，短信还是大家日常交流的重要手段之一，时至今日，基本已经无人用短信交流，短信更多用来接受验证码、订阅通知，以及避之不及的垃圾广告。手机收到短信后的效果和Push类似，都是系统级别的弹出提示，并且是独立分组，清晰可见，因此，短信是一种很有效的推送渠道，到达率高，打开率高。

短信的缺点是文字受限，而且一般只推送纯文本，不会夹杂图片，不过可以植入短连接，引导用户跳转到相关为止做进一步操作。短信要更加慎用，建议只有最重要的消息，并且有时效性要求的前提下，采用短信通道，作为最高级别的通知形式。

还有一个更粗暴的提醒方式，就是电话通知，接通后由机器人口播信息；目前某些IM软件就可以对未读消息的用户进行电话轰炸，让人又爱又恨。

不过，电话提醒在某些场景，用户同意的情况下，还是很有用的，比如在线教育，有些家长为了避免错过课程，希望上课前能接收到电话强提醒，从而及时让孩子进入课堂。

8.3.6 消息渠道（5）：邮件

邮件是最传统、经典的消息通知方式，格式自由灵活，信息量大，发送成本低；但是邮件的打开率是这些渠道中最低的，很多用户尝尝忽视系统发送的邮件，资深一些的用户可能会做邮件自动分组设置，但大多数普通用户没有这样的配置习惯，或者只是简单的将某个系统发送的邮件自动转移到一个基本不会打开的文件夹。

邮件在不同企业类型的使用习惯区别非常大，例如外企都比较重视邮件，所有事项要通过邮件沟通存档，使用严谨。而在互联网公司，沟通确认很少使用邮件，而习惯直接用IM，更加高效。

随着办公习惯的改变，邮件的打开率在持续降低，然而虽然如此，有些事项依然需要用邮件来宣导，例如上线通知。不过，大家可以回想一下，自己发出的上线通知，会有多少人打开查阅呢？

虽然邮件的打开率低，但是到达率高，并且可追溯，而且因为格式灵活，还可以用来发送定时报表，例如日报、周报。

8.3.7 五个消息渠道的对比

我们将上述提到的五个消息渠道做一个对比，这里给出的总结仅供大家参考，实际应用要结合自身系统、业务特点设计。

• 到达率：是指信息能够成功发送到目标用户并看到的比率；

• 打开率：是指用户接收到消息后打开阅读的比率；

表8 3  五个消息渠道的对比

8.3.8 如何选择消息渠道

理解了不同消息发送渠道，接下来重要的问题，是不同类型的消息应该使用哪种渠道组合方案来推送。我们将消息分为高、中、低三类优先级，优先级的定义有两个参考要素。

第一个参考要素，是根据消息的重要紧急程度，重要且紧急为高优，不重要且不紧急为低优，其他为中优。

第二个参考要素，是产品经理要测算用户每日、每周收到的不同优先级消息的占比，要确保三类消息的比例在合理的区间范围，试想，如果单纯的按照重要紧急原则设计消息优先级，假设按照当前业务规则80%都是紧急消息，显然也不合理。

那么，用户每天以及每周收到的消息，优先级高、中、低的占比应该是多少比较合理呢？SLDS推荐的比例是20%、50%、30%，即高优消息占20%，中优消息占50%，低优消息占30%，不过SLDS并没有解释原因。

为什么这个比例不是由低到高有序变化的呢？例如10%、30%、60%？我认为，消息系统本质上是用户处理业务的辅助功能组件，不是所有信息都应该用消息系统发送给用户，所以不应该以二八原则的思维，将高中低优先级按照等差或等比变化来设定。

设计推送渠道时有两个参考原则：

• IM与Push二者选其一（避免重复推送打扰）；

• 邮件与站内信必须有一个（留档追溯）；

基于这两个原则，针对不同的消息优先级，我们可以推荐若干个推送渠道组合策略，如表8-4。

表8 4  不同优先级消息的推送渠道组合

8.3.9 消息通知的配置功能设计

在5.2.3小节，我们讲过，软件系统的用户，可以分为新用户、普通用户、专家用户。人机交互的设计目标之一，就是让新用户快速成长为普通用户，保证普通用户的使用体验，如果条件允许，还要提供足够的灵活性，实现专家用户的诉求。

消息系统设计中，产品经理首先应该设计一套标准、默认执行的消息通知规则，方便绝大多数普通用户使用；如果资源允许，也要将消息提醒做成系统配置，允许用户按照习惯配置推送策略。在自研系统中，由于资源有限，用户数量有限，消息通知的规则往往是写死的硬编码逻辑；然而商业软件，就需要提供基本的消息推送自定义配置能力。

图8-32左侧是某知识库软件的用户消息配置后台，用户可以针对不同消息类型设置推送的方式，图8-32右侧是该知识库软件APP版本的Push推送配置。

消息配置功能的一般设计原则如下：

• 短信、站内信、邮件的推送配置，在PC端完成；

• Push推送配置，在移动端完成； 

图8-32  某知识管理软件的消息配置

针对站内信的小铃铛组件，更加精细化的配置，有三种交互类型，7.3.2小节的配图展示了这类精细化的配置设计。

1、 静默提醒：只显示小红点，如图8-33左侧；

2、 仅提醒数量：小铃铛右上角有未读消息的数字角标，如图8-33右侧；

3、 角标+弹出通知：在2的基础上，有新消息时会弹出磁贴（可以自动消失）。

图8-33  小铃铛的静默提醒和数字角标提醒样式

消息通知是B端产品最重要的组件之一，设计得当，可以有效提升用户工作效率，设计缺陷，用户很快就会弃用屏蔽。所有产品经理和设计师，都应该严肃梳理、设计用户消息类型和推送策略。

• CUI到底会不会替代GUI？

• CUI和GUI需要协同么？

• 两者协同的最佳实践是什么？

• CUI形态的AI Agent融入企业应用的最新应用形态是什么？