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

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