以电商社交为例解析不同业务消息功能的关键点

　　消息模块是辅助业务实现与用户互动最直接的产品模块。由于消息本身的意义很宽泛，所以业务的不同，也会产生不同的消息产品形态，消息产品的设计也是仁者见仁，智者见智。业务千变万化，掌握消息设计的关键点，才能以不变应万变。
　　一、消息的分类：案例分析
　　1. 电商产品的消息分类设计：以：＂某淘＂为例
　　以某淘为例，在电商场景中，基于核心业务需求，会有不同业务的消息需要触达用户，有些信息优先级较高，有些需要跟用户实时沟通，比如私聊，IM通讯等。
　　因此，在做消息系统设计之前，一定要清楚消息涉及的业务形态。这决定在具体设计时，如何设计消息形态与交互。就电商而言。消息形态分类：
　　消息页面会根据业务消息量，在页面信息路径上有不同的展示方案。
　　一般，消息页面共有二级：消息列表页——消息主页。
　　消息主页可以是以服务号的消息卡片流为主，也可以是一行文案或者链接，或H5互动页，或卡片流；如下图：
　　电商产品消息设计，重点集中在售后的环节。
　　因此，在消息创建主体来源于商品/门店/订单/物流/品牌/优惠券/促销活动等这一类业务资源的变动。通常这一类消息会由相应的管理系统发送，但产品经理也需要依据相应的业务动态定义消息的形态。
　　2. 社交产品的消息分类设计：以＂某博＂为例
　　对照电商产品，社交产品的消息设计则又明显的侧重。如下图：
　　以＂微博＂产品为例，相关的消息类型总结如下：
　　社交类产品中，消息的产生可以来自于：关注与未关注用户、粉丝、群、社区、订阅号等主体对象。而这些角色则也是构建社交产品的基本框架。
　　二、＂消息＂基本产品流程
　　从以上案例来看，在实际消息设计中，我们需要分清自己负责的平台的属性是电商/社交/金融等。根据具体业务，定义消息产品流程、消息类型、消息优先级、消息发送方式、消息展示方式。
　　消息发送的产品流程见下图：
　　三、＂消息＂产品分步骤设计
　　第一步：「定义消息」
　　从消息的本质来思考如果为系统编辑消息诞生的规则，我们可以从语义以及系统的原理中找到答案：
　　第一点： 从场景角度解构，消息作为一个包含动作的词语，从语义上来分析，存在一个普遍结构：模型1 ：＂对象+动作＂ 或者 ＂ 对象A+动作+对象B＂
　　其中，对象A就是动作的施加者，对象B则是动作的承受者（非常简单的语法解构）。
　　第二点，从开发的角度来说：资源在不断更新中触发消息产生的规则，并最终并推送给订阅接收的用户；
　　这里包含4个对象：
　　someone = 提醒的触发者，或者发送者，标记为sender
　　do something = 提醒的动作，评论、喜欢、关注都属于一个动作，标记为action
　　something = 提醒的动作作用对象，这就具体到是哪一篇文章，标记为target
　　someone’s = 提醒的动作作用对象的所有者，标记为targetOwner
　　比如对于电商产品来说，提醒触发的者可以分为促销系统/管理员/门店/订单系统/物流系统/；社交类，则是用户、KOL等自媒体帐号。
　　输出需求关键点1：定义：资源/动作+消息模版；即：谁+在什么情况下+对什么，作出什么事情，且在用户端的消息文案模版如何展示；
　　第二步「用户订阅」
　　每一个用户都有一张属于自己的订阅管理表。subscribeconfig，来记录用户的提醒设置。当用户没有提醒设置是，可以使用系统默认的一套设置。一则用户订阅管理记录大致包括：
　　订阅的目标（资源是什么）
　　订阅的目标类型
　　订阅的动作（action）
　　订阅的触发条件 （subscribereason =发布，则对应的action=赞/评论，比如我发表了一篇文章，如果有人针对这篇文章进行点赞和评论，就可以通知我）
　　输出需求关键点2：定义用户订阅管理对象名称有哪些，如上图。
　　第三步 消息分发与获取
　　1 消息分发方式的确定：
　　第一种：拉取；客户端在用户登录时请求服务拉取相关消息数据，定时向服务器获取新的消息，并进行更新，或者在用户进行手动下拉加载消息页面时进行更新。
　　第二种：push；push在针对消息的时效性方面作用很大。
　　2 分发频率的确定：
　　依照消息的优先级制定消息发送的高低策略。比如高优先级消息，频率可以是：实时更新；这类信息需要用户即使知晓并处理。中级消息，不需要即使知道，频率可以是：时/天/周；低优先级消息，频率可以是：固定周期；
　　3 消息分发的优化：聚合
　　消息的聚合，就是可以定义什么情况下，可以把类似的行为划分为同一类信息，进行推送。
　　输出需求关键点3：消息分发的方式（可以跟技术沟通），消息分发的优先级更新策略。
　　第四步： 消息的阅读、标记
　　输出需求关键点4：
　　定义消息数量展示规则：
　　1. 消息在TAB或在列表中的展示规则，如展示方式，最多展示几条，超过限制如何展示等；
　　2. 定义消息处理的交互以及处理状态：定义消息的有效操作，即用户如何操作才标记为已读/以处理等状态。
　　从交互的弱——强来分，处理交互可分为：
　　忽略：忽略此条信息
　　查看：点击详情或主动标记为已读
　　删除：删除本消息
　　确认：需要对本消息进行确认
　　回复：需要进行数据交互
　　处理：适合更为复杂的业务通知。
　　第五步：消息的回收
　　消息回收：产品依据开发实际开发需求，设置相应用户设计，向用户确认是否在一定周期内删除指定的消息内容。
　　四、总结
　　消息产品设计前提：明确消息产生的主体（非常重要）；
　　第一步：定义：资源/动作+消息模版；
　　第二步：定义用户订阅管理具体对象；
　　第三步：消息分发的方式（可以跟技术沟通）、对象、时间、更新时间、加载规则；消息分发的优先级更新策略；
　　第四步：定义消息在产品端的展示规则（数量/文案/图文结构等）；消息标记规则；
　　第五步：消息的回收规则。
　　消息设计的本质是在考量产品经理是否具备抽象业务的思维，这也是搭建产品基础框架的基本素质，同时也涉及到对于信息的设计以及交互等知识，值得好好研究。