消息模块是辅助业务实现与用户互动最直接的产品模块。由于消息本身的意义很宽泛，所以业务的不同，也会产生不同的消息产品形态，消息产品的设计也是仁者见仁，智者见智。业务千变万化，掌握消息设计的关键点，才能以不变应万变。

一、消息的分类：案例分析

1. 电商产品的消息分类设计：以：“某淘”为例

以某淘为例，在电商场景中，基于核心业务需求，会有不同业务的消息需要触达用户，有些信息优先级较高，有些需要跟用户实时沟通，比如私聊，IM通讯等。

因此，在做消息系统设计之前，一定要清楚消息涉及的业务形态。这决定在具体设计时，如何设计消息形态与交互。就电商而言。消息形态分类：

消息页面会根据业务消息量，在页面信息路径上有不同的展示方案。

一般，消息页面共有二级：消息列表页——消息主页。

消息主页可以是以服务号的消息卡片流为主，也可以是一行文案或者链接，或H5互动页，或卡片流；如下图：

电商产品消息设计，重点集中在售后的环节。
因此，在消息创建主体来源于商品/门店/订单/物流/品牌/优惠券/促销活动等这一类业务资源的变动。通常这一类消息会由相应的管理系统发送，但产品经理也需要依据相应的业务动态定义消息的形态。

2. 社交产品的消息分类设计：以“某博”为例

对照电商产品，社交产品的消息设计则又明显的侧重。如下图：

以“微博”产品为例，相关的消息类型总结如下：

社交类产品中，消息的产生可以来自于：关注与未关注用户、粉丝、群、社区、订阅号等主体对象。而这些角色则也是构建社交产品的基本框架。

二、“消息”基本产品流程

从以上案例来看，在实际消息设计中，我们需要分清自己负责的平台的属性是电商/社交/金融等。根据具体业务，定义消息产品流程、消息类型、消息优先级、消息发送方式、消息展示方式。

消息发送的产品流程见下图：

 三、“消息”产品分步骤设计

第一步：「定义消息」

从消息的本质来思考如果为系统编辑消息诞生的规则，我们可以从语义以及系统的原理中找到答案：

第一点： 从场景角度解构，消息作为一个包含动作的词语，从语义上来分析，存在一个普遍结构：模型1 ：“对象+动作” 或者 “ 对象A+动作+对象B”

其中，对象A就是动作的施加者，对象B则是动作的承受者（非常简单的语法解构）。

第二点，从开发的角度来说：资源在不断更新中触发消息产生的规则，并最终并推送给订阅接收的用户；

这里包含4个对象：

1. someone = 提醒的触发者，或者发送者，标记为sender
2. do something = 提醒的动作，评论、喜欢、关注都属于一个动作，标记为action
3. something = 提醒的动作作用对象，这就具体到是哪一篇文章，标记为target
4. someone’s = 提醒的动作作用对象的所有者，标记为targetOwner

比如对于电商产品来说，提醒触发的者可以分为促销系统/管理员/门店/订单系统/物流系统/；社交类，则是用户、KOL等自媒体帐号。

输出需求关键点1：定义：资源/动作+消息模版；即：谁+在什么情况下+对什么，作出什么事情，且在用户端的消息文案模版如何展示；

第二步「用户订阅」

每一个用户都有一张属于自己的订阅管理表。subscribeconfig，来记录用户的提醒设置。当用户没有提醒设置是，可以使用系统默认的一套设置。一则用户订阅管理记录大致包括：

1. 订阅的目标（资源是什么）
2. 订阅的目标类型
3. 订阅的动作（action）
4. 订阅的触发条件 （subscribereason =发布，则对应的action=赞/评论，比如我发表了一篇文章，如果有人针对这篇文章进行点赞和评论，就可以通知我）

输出需求关键点2：定义用户订阅管理对象名称有哪些，如上图。

第三步 消息分发与获取

1 消息分发方式的确定：

• 第一种：拉取；客户端在用户登录时请求服务拉取相关消息数据，定时向服务器获取新的消息，并进行更新，或者在用户进行手动下拉加载消息页面时进行更新。
• 第二种：push；push在针对消息的时效性方面作用很大。

2 分发频率的确定：

依照消息的优先级制定消息发送的高低策略。比如高优先级消息，频率可以是：实时更新；这类信息需要用户即使知晓并处理。中级消息，不需要即使知道，频率可以是：时/天/周；低优先级消息，频率可以是：固定周期；

3 消息分发的优化：聚合

消息的聚合，就是可以定义什么情况下，可以把类似的行为划分为同一类信息，进行推送。

输出需求关键点3：消息分发的方式（可以跟技术沟通），消息分发的优先级更新策略。

第四步： 消息的阅读、标记

输出需求关键点4：

定义消息数量展示规则：

1. 消息在TAB或在列表中的展示规则，如展示方式，最多展示几条，超过限制如何展示等；

2. 定义消息处理的交互以及处理状态：定义消息的有效操作，即用户如何操作才标记为已读/以处理等状态。

从交互的弱——强来分，处理交互可分为：

• 忽略：忽略此条信息
• 查看：点击详情或主动标记为已读
• 删除：删除本消息
• 确认：需要对本消息进行确认
• 回复：需要进行数据交互
• 处理：适合更为复杂的业务通知。

第五步：消息的回收

消息回收：产品依据开发实际开发需求，设置相应用户设计，向用户确认是否在一定周期内删除指定的消息内容。

四、总结

消息产品设计前提：明确消息产生的主体（非常重要）；

• 第一步：定义：资源/动作+消息模版；
• 第二步：定义用户订阅管理具体对象；
• 第三步：消息分发的方式（可以跟技术沟通）、对象、时间、更新时间、加载规则；消息分发的优先级更新策略；
• 第四步：定义消息在产品端的展示规则（数量/文案/图文结构等）；消息标记规则；
• 第五步：消息的回收规则。

消息设计的本质是在考量产品经理是否具备抽象业务的思维，这也是搭建产品基础框架的基本素质，同时也涉及到对于信息的设计以及交互等知识，值得好好研究。

本文由 @Sherry 杨 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议