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

0 评论 18073 浏览 48 收藏 10 分钟

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

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

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协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!