消息通知系统设计

29 评论 70576 浏览 1005 收藏 22 分钟

编辑导语:消息通知可以将内容实时送达用户手机页面,但是泛滥的消息通知会引起用户的反感,也违背了这个设计的初衷。如何理解以及设计消息通知,作者作了简单的分享,我们一起来看看吧。

消息通知可以及时地将状态、内容的更新触达到用户,用户则可以根据收到的消息做后续判断。但是如果没有及时将重要消息触达到用户或者滥用消息,则失去了消息通知的初衷。

特别是针对涉及复杂任务流程的产品,消息类型繁杂,难以全面盘点消息类型,消息系统的设计就显得尤为重要。

希望通过这篇文章让各位在设计消息通知系统的时候能够更加全面高效。

一、如何理解消息通知

消息通知需要为产品服务,帮助用户快速获取对应的通知信息。收到一条新回复的提示、工作台展示工作进度、朋友的来电,生活中处处是信息的交换。在 App 和网页应用中最常见的信息交换方式则是消息通知。

消息作为一种信息交换方式,抽象其过程,即为“在达到某一触发条件下,由发送方发送消息给到接收方,接收方可针对此条消息提供反馈”。需要包含以下关键因素:

  1. 消息触发时间与条件(何时什么事):如按周期重复的时间点,或系统状态变更、用户操作结果等;
  2. 消息发送方(谁发现的事):可能是系统、第三方服务商,或者某个用户;
  3. 消息接收方(谁需要知道):即接收方,可能是系统中的全部用户,也可能会根据权限划分推送到某个用户群组,或者是某个特定用户;
  4. 消息触达渠道(怎么找到他):短信、电话、App 内通知等;
  5. 消息通知内容(告诉他什么):短信的文本、电话对话内容、通知消息的文案等消息通知;
  6. 消息操作反馈(他可以干嘛):主要分为只读与操作反馈。只读,即当前消息用户在浏览后不需要做更多的操作,主要以了解为主;操作反馈,即当前消息需要用户浏览,且在浏览后做相应的后续操作。

好的消息系统要满足什么条件:

  1. 全面:通知的消息项要完整全面,用户才能放心地通过消息通知系统了解消息更新内容;
  2. 及时:消息的触达方式要及时有效,在消息相关事件发生后,用户能在第一时间获取到信息并提供操作反馈给到消息发送方;
  3. 高效:能通过合理的消息发送途径、允许用户设置及合并相似信息等方式避免过多消息侵扰用户,让用户能够高效处理消息通知。

二、如何盘点消息通知

设计全面、及时、有效的消息通知系统需要对消息的六个关键因素进行全面盘点,通过分步的方式逐步完成消息通知系统的设计。主要分为以下三步:

  1. 盘点系统中包含的消息项:包含其触发条件、通知来源及通知对象。需要盘点完整消息项从而保证消息系统的完整性;
  2. 确定消息触达渠道:包含各消息项的触达渠道。让所有消息都能触达到用户的同时,能够让重要信息更易触达,保证消息通知的及时性;
  3. 撰写通知内容与操作反馈:包含各消息项的通知内容与操作反馈。让消息内容能够有效地传达给用户,让用户能快速反馈、操作。

盘点的过程,即对消息通知清单的梳理。与产品、研发等团队成员的沟通也将使用该清单。最终目标即完成下方表格的填写:

1. 盘点系统中包含的消息项

当前步骤需要对系统中可能会有的消息项进行完整的盘点。盘点消息项可以通过按消息类型走查方式完成。市场上比较有共识的消息的分类方式主要分为禁止、警告、成功三类。但是在实际设计工作中还需要配合以下的消息分类方式去更完整地盘点消息项:

(1)盘点出的每个消息项都需要补充以下四个关键因素

  1. 触发条件:结合产品核心场景梳理完整。可通过状态图或泳道图查缺补漏(详见下段内容);
  2. 通知来源:可能是某个内部系统,可能是某个用户组,也可能是某个具体用户。用户组的划分需要提前与产品、研发同事沟通完成;
  3. 通知对象:可能是全部用户,也可能是某个用户组或具体用户。由触发条件中的场景决定;
  4. 重要性:需要与团队沟通得出,可使用“高”、“中”、“低”的分类方式。

盘点完成的消息项使用下表进行整理,方便产品、设计、研发之间的沟通。

(2)用流程图或泳道图查缺补漏

对于 ToB 或 ToG 类含有复杂状态转换以及任务流的产品,除了使用分类的方式盘点消息项,还需要对照流程图或泳道图查缺补漏,避免消息类型的遗漏。

如,顾客线上购买商品并收取商品的商品相关状态变化如下图所示,每个状态都可对应着一条消息项:

△线上购物过程中的消息流程图示意

当系统内包含多角色,且角色间流程有交互时,则可以使用泳道图的方式进行梳理。在泳道图中的每一条状态变更线,都对应着一个状态变更提醒。其中角色间交互的线,由于需要角色主动处理方可进入下一流程状态,这条消息一般会成为一条待办消息。

(3)什么类型的消息不要纳入消息通知系统

需要注意的是,虽然通知的完备性很重要,但某些消息在前期梳理时就需要从清单中剔除,包括:

  1. 单纯问候类消息,如“好久不见”等
  2. 不需要用户知道的消息,如系统后台数据更新等

2. 确定消息触达渠道

确定要推送给用户的消息类型后,需要给各消息匹配适合的通知方式。不同的通知方式会有不同的适用场景,可对照下表结合第一步整理的重要性配置消息的触达渠道:

消息触达渠道的配置结果到第一步的表格中:

平衡通知量:

一个好的消息系统需要能有效触达的同时不过分侵扰用户。这就要求我们对系统实际运行中可能会出现的通知量进行预估,并适量调整通知方式,让重要的消息能够更有效及时地触达到用户。

最终调整后的消息数量与提醒强度的关系最好能形成如下图所示金字塔的模式。

△ 提醒强度与消息数量的金字塔关系

(1)合并重复消息

对于出现频率较高,且用户不需及时了解每条消息的消息项,可以通过合并消息的方式减少通知的数量。合并主要有两种方式:合并流程过往节点信息和合并同类消息。

合并流程过往节点消息:对于一些流程类通知,若用户在响应或查看前,流程已经进入到下一阶段,历史节点的信息已经无需了解时,可合并过往流程节点的消息。如淘宝在展示物流时,针对同一订单的物流,仅保留最新的一条。

合并同类信息:对于同类型消息过多,且用户不需要一一查看,只需在用户有需要的时候提供入查看完整内容时,自动合并同类型的消息,减少对用户的打扰。如 Instagram 在展示用户动态信息时,会合并同一天同一类型的消息。

△两种合并消息方式

智能推送:有条件的系统可根据用户行为分析及用户画像,进行智能推送。如基于用户画像按类型推送运营类消息,基于用户接受消息数量,判断是否合并消息推送等。

(4)渠道间消息项的延续与统一

出于信息持续性的考虑,触达渠道之间有部分关联关系在制定消息触达渠道时需要注意,如:

  1. 若系统包含App、web等不同端,相同通知类型的消息要保持统一
  2. badge提示需要在应用内消息通知模块有对应消息提示
  3. push消息的文案需要与应用内消息中心保持一致

3. 撰写通知内容与操作反馈

通知的内容需要满足简明易懂的同时,还要让用户能够快速处理。根据大量经验总结,通知内容的撰写可使用一个通用撰写公式:

在应用撰写公式写内容时,需注意以下要点:

  1. 重点前置:用户触达的第一场景,可能是手机的 push 消息,可能是多个消息的列表。这就要求在撰写文案时要将重要信息前置,如验证码、还款金额、事件提醒名称等。
  2. 敏感信息保护:由于无法确认用户获取信息的场景是否私密。对于金额、个人信息等隐私数据,建议在应用内或其他渠道提供设置项,提供用户自主选择是否在消息通知中包含具体数值。如果要默认显示,需要提前告知用户。
  3. 来源信息露出:在邮件、短信等非产品自有渠道推送消息时,用户可能会不确定消息的来源是否官方,需要包含消息来源信息。
  4. 提供触发时间:当消息的发生时间对用户后续判断、操作有影响时,需要在通知内容中包含消息发生的时间。

除了以上通用注意事项,由于渠道本身的特征差异,还需注意以下渠道相关的要点:

  1. 电话:需要设定客服话术标准,一般需要在会话开始前先告知用户来电是谁、有什么目的。在讲述完通知内容后,还应告知用户如何处理当前信息,如果想了解详细内容该前往哪个渠道了解。
  2. 短信-来源平台:由于通知类短信的发送号码可能会由于服务商设置的问题导致有多个发送号码发送给用户,用户无法根据号码判断发件人身份。故需要在短信最开始说明平台来源,建立品牌认知,避免用户错认为是垃圾短信。
  3. 短信-操作反馈:由于大部分短信为纯文本短信,相关操作反馈需要通过链接或者路径指引的方式提供。若短信包含详情链接,链接最好能设置为保留根域名的短链,如:点击了解详情:cdc.qq.com/d8djei
  4. 邮件:与短信相似会有来源可信度问题,邮件内容需包含品牌元素,同时发件的邮箱地址后缀使用产品官方网站。另外需要注意,某些邮件软件会设置不自动下载图片,邮件重要内容不要使用图片。
  5. push推送(移动端):是消息在移动端的特有触达渠道,由手机系统发送。发送的信息格式会受系统要求有所限制。最新的推送要求可参考相关设计规范文档或接口规范。应用的icon与名称系统会自动补充,撰写文案时不用包含。
  6. 微信公众号(订阅号/服务号):由于微信对订阅号与服务号的消息推送方式会经常变化,需要确认最新的要求并撰写文案,相关链接见链接。

在完成通知内容以及操作反馈的梳理后,对消息梳理表格进行更新,补充相关信息:

自此,消息项的盘点已经完成,后续可基于该表格与产品、研发沟通。当业务出现变更时,也需要对表格内容进行同步更新。

三、如何设计消息中心

消息通知的触达渠道中,电话、短信、push 推送的呈现由系统决定。但是若产品有独立 App,往往需要消息中心去承载全量的消息列表。本章会介绍如何设计消息中心。

不同应用的消息中心处理方式受产品定位、应用框架等因素影响,设计差异化较大。但是可以通过按路径分割去简化设计:消息中心的入口、消息列表的组织方式、消息卡片的样式、消息的设置等几个部分。

1. 消息中心入口

主要有底部 tab、个人中心附近的图标入口、个人中心的菜单项等三种入口形式:

△ 消息中心的三种入口

  1. 底部tab:一般适用于产品核心功能中包含大量用户间通讯,或者希望通过强化消息露出来促进用户上传更多内容。对于重要的消息类型可提供数字 badge 作为未读消息数量的提示;
  2. 顶部图标入口:一般适用于产品消息数量较少,或消息对产品核心场景的影响较少的情况。一般会在首页的顶部,或个人中心页的顶部有一图标作为入口。图标会包含数字 badge 作为未读消息数量的提示;
  3. 个人中心菜单项:一般适用于当产品顶部空间作他用,没有图标入口的位置时使用。

2. 消息列表

从消息中心入口点击后跳转到消息列表。由于消息的即时性,需要按时间维度排列。但是如果产品的消息类型较多,可通过分组合并或者分 tab 的方式提升用户触达消息的效率。

△ 分组合并消息列表

△分 Tab 合并消息列表

对于通知类型复杂的系统,还可使用二级列表的形式对消息进一步分类展示,如微信及支付宝,由于其包含大量第三方服务,消息复杂,均设置了二级消息列表帮助用户分类查找消息。

△ 二级消息列表

3. 消息卡片

消息列表中的卡片有两种样式可选,一般在一级消息列表使用小卡片样式,让用户有更高的浏览效率。大卡片样式则用于二级消息列表,或当前应用的消息数量较少时。

△消息卡片应用示意

4. 消息中心设置

一般位于消息中心列表页右上角,若可设置项较多,则提供设置入口在二级页设置。一些常用的消息设置项如下:

  1. 全部已读:对于消息数量较多,且未读态会影响 badge 的展示时需要提供该设置项。点击后设置列表消息项全部已读。
  2. 发起对话:若系统包含通讯功能,一般会在消息类表页提供发起对话的快捷入口。点击后跳转到通讯录或好友列表。
  3. 设置通知提示方式:提供按消息类型设置某些通知项的接受渠道、接收时间段、各渠道之间的已读联动等,如微博;或者让用户选择消息通知的精确度,是否包含具体信息,如微信可接收“您收到了一条信息”的模糊消息。
  4. 打开消息推送权限:一些应用有一些状态更新或重要的提醒需要用户在系统设置中打开当前应用的通知权限,会包含提示用户打开通知的功能。这些提示需要在用户进行了如“办理事项”、“上传状态”等发起流程的操作后提示。不建议在用户启动 App 时就弹窗提示打开通知。

四、总结

本文是对消息通知系统设计的初步介绍,希望能帮助到新手产品、交互、产品体验设计师快速了解消息通知系统的内容盘点与消息中心的设计方法,制定及时、高效、完整的消息通知系统。

文中主要覆盖了常见的系统与场景,若实施过程中遇到文中方法无法解决的情况欢迎留言沟通。

 

作者:Megan,来自腾讯CDC主创团队

推荐关注公众号 “腾讯设计”( 微信ID:TencentDesign ),第一时间获取腾讯官方的设计方法论

本文由 @腾讯设计 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自Unsplash,基于CC0协议

作者:卡卡西xi

来源公众号:腾讯设计(ID:TencentDesign),设计向善

本文由人人都是产品经理合作媒体 @腾讯设计 授权发布,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 感谢科普;如果能增加后台配置,那就更感激不尽了

    来自浙江 回复
  2. 非常好,mark

    来自北京 回复
  3. 如果只有第三方配置的模板消息,如何做消息中心,哪位大佬可以帮忙解答

    来自湖北 回复
  4. 很精彩的留言区,我是头大来搜文章的,那个留言流程不去掺和了,我感觉作者是站在了所有的各个平台都已经配置好了然后去拿去统计数据的来源做消息功能,而不是楼上大佬们讨论的我怎么去配置某一个功能项。
    对于我来说我感觉自己都会卡在第一步:盘点系统全局消息来源,无论是系统提示,或者用户操作反馈,或者是运营模块、通知公告类等,因为我感觉我看不见系统内里面流程(乙方),用户端需要账号会很复杂,后台铁定肯定更看不见…🤔我特么心累

    来自北京 回复
  5. 感觉挺常规的

    来自江苏 回复
  6. 表面设计是说明白的,但是具体实现并没有写,比如如何接入业务系统、业务系统和消息中心的职责划分是怎么样的?整体的系统实现流程是什么样子的,对这些更感兴趣

    来自上海 回复
    1. 后台一般不会做分享的

      来自北京 回复
    2. 哎,还是挺难的

      来自上海 回复
    3. 我最近有在做消息中心模块的功能,我是前台产品,我们是分了消息中心前台、消息中心后台、业务中台三块。首先我是梳理了消息推送的主流程,包括消息触发条件、消息推送内容、消息推送人群、消息储存等;再是对消息的触发条件进行了分类,哪些是需要业务系统触发的,哪些是需要运营同学配置发送的;接着对消息的内容进行了整理,把共有的内容提了出来,然后做成模板(或者说接口样式),然后把这个消息模板的管理放在了消息中心后台,由运营进行配置消息模板;业务系统触发就取对应的消息模板接口的消息内容给业务系统对应的人进行推送消息,运营配置发送的就把消息模板和人群包绑在一起,定向给某部分人发消息

      来自北京 回复
    4. 现在前台产品都这么全能了吗?这块对于产品来说这么多挺全的了,但是实现起来总是会遇到数据和系统边界问题,
      就比如运营同学想配一个模板,模板内需要应用订单号等数据,那么问题来了,需要引用哪些数据(总不能全部数据吧),引用的数据怎么做权限,如A产品线只能用A线的数据,不能用其他线路的数据,初步的想法是将业务类型跟数据源绑定,比如负责订单的同学可以看到abcd四个数据并用于配置到消息模板中,负责物流的同学可以看到bce并用于配置到消息模板,但是新的问题又来了,这个东西在哪里配?谁来配?数据哪里来(数据中台?没数据中台怎么整?)?
      再说系统边界问题,需求如下:给3年以上的会员发一个祝福,那么这个触发条件“3年以上的会员”怎么做?如果业务系统来做,好了,那天天都有满三年的,天天要调用你消息中心的接口,业务一多受得了吗?再加上有些业务系统会将消息内容在自己系统内配置,如何说服他们在我们系统配置?在我们系统配置有什么好处(目前看来还有数据问题,的确吃力不讨好);如果吗发送条件放到消息中心来做,那么消息中心的开发将陷入无休止的业务深潭中,不仅消息中心的迭代进度受到影响,而且在中台开发不了解业务的情况下,往往代码质量堪忧

      综上所述,我觉得消息中心是个对开发、架构要求高于产品的模块,重头戏还是背后,就是文章里没说的部分,想想都牛逼

      来自上海 回复
    5. 我们组是做营销工具和用户运营的业务,这个消息中心前后台都是我们组在负责,只是因为我是校招生,时间比较充裕,我在负责需求的梳理、业务的梳理和前台页面的设计以及中台后台需求的对接。我们目前订单类的消息是没有走配置页面的,当中台那边订单的状态满足某条件时就给我们订单消息的接口(订单类消息有统一的接口)灌数据,我们拿到数据后进行储存和给前台查询。我们是平台自营电商,对消息中心是否展示订单消息的需求没有那么强烈,又加上对消息中心的规划是主要用于营销消息,所以在订单消息方面没有做多复杂。
      关于第二条,我们目前的系统架构是:消息中心后台创模板、用户画像标签平台圈人群、营销渠道平台做执行发送,你提到的“给3年以上的会员发祝福”这个需求,目前我们业务上是没有的,但如果有这样的需求,我想的话让用户画像标签平台每天凌晨刷新当天或者当月或者当年是注册3年的会员的人群是可以实现的。

      来自北京 回复
    6. 通透啊通透,看来是苦逼产品一枚。

      来自浙江 回复
    7. 对于一般的APP来讲,讲到这个程度已经足够了。
      给产品讲的,当然集中在产品层面。电商APP比较复杂,当然应该另当别论。

      来自浙江 回复
    8. 你这个是啥产品的,有业务中台的吗?

      来自四川 回复
    9. 有中台

      来自北京 回复
    10. 电商的

      来自北京 回复
    11. 比较常规的思路。一般消息中心前后端都是这些功能,区别在于细节,这个是需要在使用中不断去提炼需求并合入功能中的。

      来自江苏 回复
  7. 想咨询一下这个消息的时间,具体是什么时间?消息接受成功的时间吗?消息发送成功的时间吗?还是怎样的?

    来自广东 回复
    1. 前台主要是收到的时间,后台主要是发送的时间

      来自北京 回复
  8. 消息什么来的->谁发出的->通过什么发送的->要发给谁->发的什么内容->需要怎么做

    来自北京 回复
  9. 太强了

    来自山东 回复
  10. 在二、如何盘点消息通知,3. 撰写通知内容与操作反馈里面的第二个图,“在完成通知内容以及操作反馈的梳理后,对消息梳理表格进行更新,补充相关信息”倒数第三列是否应该是“触达渠道”?如果是对应上面一个流程下来的话

    来自广东 回复
  11. 官方出品, 学习了,感谢。 那个消息中心, 跑马灯 的分类是否应该是 “消息形式 ”而不是 [触发条件] ?

    来自上海 回复
  12. 前段时间,正好做消息埋点,很多坑都踩过,对这个文章是深有感触。感谢大佬

    来自江苏 回复
  13. 这个整理真的很到位,之前我做过公司的消息系统,感觉当时要看到这篇文章应该设计的很全

    来自北京 回复
    1. 我设计还挺到位的 , 但总结没有这篇文章那么好, 还有一些瑕疵。

      来自广东 回复
  14. 对1年经验的产品都要求这么高了吗?
    汗汗汗

    来自北京 回复
  15. 官方……打扰了

    来自北京 回复
  16. 看的过程中就觉得总结得很全面,原来是官方团队出品,👍

    来自广东 回复