缩我suo.im
短网址高速,稳定,免费生成,专注解决运营人的推广需求!
消息模块是辅助业务实现与用户互动最直接的产品模块。由于消息本身的意义很宽泛,所以业务的不同,也会产生不同的消息产品形态,消息产品的设计也是仁者见仁,智者见智。业务千变万化,掌握消息设计的关键点,才能以不变应万变。
一、消息的分类:案例分析
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. 定义消息处理的交互以及处理状态:定义消息的有效操作,即用户如何操作才标记为已读/以处理等状态。
从交互的弱——强来分,处理交互可分为:
- 忽略:忽略此条信息
- 查看:点击详情或主动标记为已读
- 删除:删除本消息
- 确认:需要对本消息进行确认
- 回复:需要进行数据交互
- 处理:适合更为复杂的业务通知。
第五步:消息的回收
消息回收:产品依据开发实际开发需求,设置相应用户设计,向用户确认是否在一定周期内删除指定的消息内容。
四、总结
消息产品设计前提:明确消息产生的主体(非常重要);
- 第一步:定义:资源/动作+消息模版;
- 第二步:定义用户订阅管理具体对象;
- 第三步:消息分发的方式(可以跟技术沟通)、对象、时间、更新时间、加载规则;消息分发的优先级更新策略;
- 第四步:定义消息在产品端的展示规则(数量/文案/图文结构等);消息标记规则;
- 第五步:消息的回收规则。
消息设计的本质是在考量产品经理是否具备抽象业务的思维,这也是搭建产品基础框架的基本素质,同时也涉及到对于信息的设计以及交互等知识,值得好好研究。
本文由 @Sherry 杨 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议
缩我suo.im
短网址高速,稳定,免费生成,专注解决运营人的推广需求!