如何重构建消息系统

释放双眼,带上耳机,听听看~!

消息模块是每个产品必不可少的重要模块,作为沟通用户与产品的重要桥梁,消息系统一直在整个产品的各个周期中占有重要的地位,它必须保证企业核心业务流程的正常运转,同时还需要传达用户的反馈。本文作者做了相应解读,一起来看一下。

如何重构建消息系统

本文将分为上下两篇,以消息中台的思路设计方案,最终落地消息中心及后台方案,以消息收发为基础应用,为公司不同的业务场景提供支撑。

一、重建背景

对于一个金融咨询类公司来说,怎么把专业指导消息有效、准确、及时地传达给用户,是非常重要且核心业务。随着新业务不断的叠加,因为没有进行系统的规划,造成了现有业务消息冗杂、消息分类不明确、传达方式不及时等诸多问题,如果不进行彻底的重构,无法做到支撑后续更多的业务。

任何一款产品重建重要模块的过程,都是一种极为富有挑战的工作,特别是对核心业务,原有流程已经深入人心,前端的功能体验和交互方式已经被用户所熟悉和接受,如果突然进行很大的改变,用户重塑认知的风险,会不会因为认知成本太高而造成原有用户流失,业务人员会不会不接受,众多因素都是此模块能否成功的关键因素。

下面笔者将详细分享自己对于消息中心重建的设计经验(以下内容数据方面有一定的模糊处理,仅供参考)。

二、需求调研

需求调研的方式有比较多的分类和方法,在这此消息系统的优化中,笔者采用了内部调研和外部调研两种方案,下面给大家详细说明。

1. 内部调研

如何对现有消息系统有全面细致的了解,需要我们先找到一个突破点,日常工作职责中必须用到消息的职能部门。

我们不仅需要了解其在消息业务背后的痛点,要对业务进行系统的了解,如果是需求调研更多是为了解决一个点的问题,而我们现在要对于整个流程进行了解和整理,这样不仅可以知道更深刻的业务逻辑,还可以让我们对业务有进一步了解的机会(作为新人带着需求去了解业务是比较快的成长方式)。

方法一:相关人员走访调研

实际的调研过程中,确定了哪些业务部门的关键人以后,与相关业务人员面对面访谈,在公司内部比较常见的方式;如果是不同办公地点的同事也可采用线上沟通的方式进行。

我们要先提前把问题想好,避免约了需求方见面后以后不知道重点,造成调研无中心。这里可以提供大家几个方向问题,帮助大家在调研消息业务时,进行业务方面的了解。

  1. 请列举一下我们部门那些业务需要通过消息推送发送给业务用户,消息推送全流程是如何实现的?
  2. 目前这些业务对于消息的触达方式有哪些?系统自动发送还是需要人工推送,频率如何?有没有遇到什么问题?
  3. 大家现有的渠道公众号推送/App Push/站内信推送时是如何进行推送渠道的筛选的?你们觉得是不是需要增加推送渠道?不同的渠道对应的是哪些业务场景?
  4. 目前我们的消息业务是否可以满足现有应用场景和客户群体,对于更多有助于公司业务提升的场景中,我们有哪些不足点可以进行优化?
  5. 在没有消息渠道触达客户时,我们目前是如何与客户进行沟通的?沟通的结果如何?是否有相关的数据支撑呢?

特别注意沟通的时候尽量要记下来自己不懂的问题,随后要和相关访谈部门进行及时的确认,避免在后续方案实施中遗漏比较重要解决方案。

方法二:收集相关资料

消息系统作为每一款产品的基础模块,在前期的版本规划中,相关的产品经理和技术会留有相关的文档,如果我们在具体实施方案前,业务方没有明确的方向,我们可以通过部门内部调研,来解决需求真伪的问题:

  1. 我们需要通过产品内部对齐信息,并与相关的产品经理了解其他模块与消息模块的业务关联,并收集相关的文档,避免造成优化的过程中方案无效。
  2. 其次我们需要和相关的技术负责人沟通,收集现在系统中的消息种类、发送机制等,尽量让技术提供系统消息模版,这一步非常关键,因为随着业务的变迁,人员的更迭,业务部门的人员提供的相关信息可能存在纰漏和错误,查看技术代码可以最真实的还原现在消息模块的具体情况。

2. 外部调研

如果你对消息系统没有概念,只是知道这套系统具体功能是做什么的,这样是远远不够的。你需要进行深入的调研,我们可以进行竞品调研,大致把竞品和你所熟知的app的消息模块进行系统了解,这样你才能够提出足够有重点的问题。

笔者在进行消息模块的竞品分析时,根据消息模块的特点,从业务层和体验层两个大的维度进行了分析,表格如下:

三、如何全面梳理消息系统

关于消息系统,我们必须清楚的知道消息本身的底层逻辑都包含哪些主要维度,并从这些维度去分析前台的功能设置,以及后台需要配置的相关支撑数据,接下来笔者使用5W1H的方法,从5大维度进行分析。

1. 消息触发的业务(what)

作为模块重建,通过对业务部门及内部产品的调研,我们不仅需要了解触发消息的业务都有哪些,还需要和业务方探讨随着业务的增加,有哪些新的业务需要新增消息提醒服务。

如运营部门现有的消息业务为课程打折活动,通过调研发现最近运营需要负责直播业务,此业务需要增加消息发送,我们需要先记录下此业务。

2. 消息触发的条件(way、when)

  • 从业务维度划分:在什么业务流程中什么时间会给用户触发消息,如按周期重复的时间点,或系统状态变更、用户操作结果等;
  • 从触发维度划分:分为系统触发和手动推送两部分,系统触发顾名思义为用户触发某个业务流程后自动发送给用户,例如购买基金成功后会发送申购成功的通知;手动推送消息,需要运营同学或者业务同学在后台进行设置后,才可以推送给目标用户。

如:我们用直播业务流程完成的说明消息触发的条件举例说明:

  1. 直播创建后,当运营的同学成功上架一场新的直播活动,触发机制为运营在后台手动推送给目标用户,告知目标用户有新的直播可以预约;
  2. 直播预约前,用户在直播模块的前端页面点击「预约直播」按钮,系统触发消息提示用户,本场直播用户预约成功;
  3. 直播开播前,系统在设置的时间节点自动发送给预约用户,提示用户直播开始。

3. 消息推送的人群(who)

即消息接收方,可能是系统中的全部用户,也可能会根据权限划分推送到某个用户群组,或者是某个特定用户;用户群组的划分,与用户的画像和业务紧密关联,如果后台已设置用户标签和画像库,则会使消息更加高效。

4. 消息推送的渠道(where)

首先我们要先梳理,消息的推送渠道一共有哪些及这些渠道的特点:

  • 电话;传统的电销模式下,电话提醒作为获客的主要手段,优势在于可以强提醒用户,并和用户做深度沟通,但是由于过度打扰用户,触发方式及渠道比较特殊,成本较高,所以这种提示方式需要甄别业务实施,不建议使用。
  • 短信;作为及时触达用户的一种方案,用于把重要且信息量较少的消息内容及时传达给用户的有效方法,如验证码、基金申购通知等。
  • 邮件;互联网2.0时代的重要的沟通方式,优势可以把信息量较大的消息准确地推送给用户。但是随着移动互联网的兴起,即时通讯APP大量的出现,邮箱作为主要的pc端工作交流的渠道,所以劣势就是无法及时提醒用户;如常见的消息业务员激活邮箱、验证码、银行账单等依旧在使用。
  • push推送;主要是配合应用的出现,iOS和安卓系统的推送方式不同,iOS可以运用自身系统的原生推送渠道,推送规则一致;安卓则因手机厂商的规则不一致,则应用无法单独满足,一般会使用第三方服务;需要用户及时处理的消息则使用push推送。
  • 弹窗;主要作为用户前端操作反馈的及时通知,如订阅成功、直播预约成功等。
  • 站内信;作为主要应用消息的推送方式,可以把消息有效且准确地推送给目标用户,并在消息中心储存;应用类所有业务皆可使用此渠道。

然后我们再去划分哪些业务的消息使用哪种渠道展示给用户;如直播业务中会涉及到的消息渠道:

  1. 直播创建后,运营在后台手动推送给目标用户,可以使用PUSH及站内信的方式展示给目标用户直播信息;
  2. 直播预约前,用户在直播模块的前端页面点击「预约直播」按钮,系统触发tost弹窗/站内消息提示用户预约成功;
  3. 直播开播前,系统在设置的时间节点自动发送给预约用户push消息,提示用户直播开始。

5. 消息推送的内容(how)

消息的内容从功能设置上分为:只读与可操作。

  • 只读,即当前消息用户在浏览后不需要做更多的操作,主要以了解为主;如申购基金成功提醒;
  • 可操作反馈,即当前消息需要用户浏览,且在浏览后做相应的后续操作;如补仓提醒。

消息分类,需要和业务深度结合去进行消息分类的划分,目的是可以让用户用最短路径浏览到同类的信息,大概率可分为系统消息和业务相关消息,如果有社区,还会有互动消息之内的聚合。

四、客户端消息构建方案

通过梳理,此次主要需要对APP的应用级的消息进行重构,我们先明确优化渠道:push推送、站内信。

并通过业务侧的调研,消息主要的问题是新业务不断叠加,因为没有进行系统的规划,造成了现有业务消息冗杂、消息分类不明确,所以我们需要通过对业务消息进行分类合并,重新梳理消息的类型的划分,并从前端展现形式上对消息类型作出明确的划分。

1. Push推送前端展示现方案

Push的前端展示样式主要有:标题+摘要、标题两种展现形式;在不同的业务条件下,这两种展示都能够使用,所以要求我们设计后台的时候需要注意字段的扩展。

我们要注意的是由于Android和iOS机制不同,此处区分两个平台讲解。

1)Android

国内Android系统均为定制过的ROM,需将APP与各大手机厂商均有合作添加产品白名单,或将APP加入手机自带的安全工具白名单,这样才能保证推送不会丢失,因为和各大手机厂商对接的成本太高,一般情况下我们会接入第三方服务商(如:极光),各厂商字符规则如下:

2)iOS

iOS的推送需要通过苹果官方服务器进行推送,跟进程存活没有关系,前提是用户开启推送通知权限。

2. 站内信的优化

站内信的优化我们从两方面入手,首先需要业务方对消息进行整合分类整理,划分出明确的类型,从类型上减少用户识别路径;其次对于消息的入口、消息列表的展现形式,缩短用户查看消息路径。

1)消息入口

金融类的产品,消息入口常见的展现形式有底部主要导航 tab、顶部图标入口两种形式:

  • 底部主导航特点:此类设计说明消息模块在此产品中,用户的使用频率比较高,并且通过消息展示够让用户做出对主要业务影响的操作。
  • 顶部图标入口特点:一般会用在产品需要消息及时触大用户,且不做为主要业务,设置在顶部的优势,可以灵活地设置在需要消息支持的业务模块的顶部。

作为金融属性的产品,信息的及时披露对于用户的交易和服务都是非常重要的,所以我们在设计消息入口的时候,会选择灵活性和即时性都兼顾的产品设计,这两种设计都可以对于重要的消息类型可提供数字 badge 作为未读消息数量的提示。

2)消息列表

消息列表为笔者这次改造的重点区域,从消息入口点击后跳转到消息列表,由于业务的增加,造成消息类型不明确,消息等级错乱,通过竞品调研,主流金融类产品的消息列表为以下两种形式,消息分类合并或者分 tab 的方式。

两种模式的区别在于,如果消息分类比较多,还有二级消息分类的情况,则使用分类合并的产品设计,列表的展示比较简洁,用户可以清晰地获取消息分类信息。

此外如果消息的二级分类列表,也可以使用二级分类列表,则可以使用tab交互方式,列表的排列顺序可以按照业务重要性质进行默认排列,信息详情按照时间的倒叙排列;大家可以按照自己的产品的具体情况设计产品方案。

3) 消息列表详情

消息列表详情,主要的功能使用户不用点开消息详情,对主要消息内容有所了解,主要有以下几种类型:

  1. 标题+时间戳+内容概要(消息内容的固定字数):一般会用在消息频率很高,消息内容比较长的消息或者消息字数比较少的消息列表详情,如新闻类资讯或者交易提醒,只读取固定字数的消息内容,需要用户点击进入查看更多消息内容,交互特点为未读读时,文字为高亮状态,点击查看后为变灰;
  2. 标题+时间戳+内容概要(消息的关键内容):对于消息内容可提取主要的概要字段的消息可以使用此列表详情,提高用户获取消息内容的效率,使有效信息可以及时触达用户;如收益情况等;
  3. 标题+时间戳+图片+内容概要(消息的关键内容):一般活动消息使用此列表详情,消息频次比较低的消息也可以使用,增加活动图片可以烘托活动气氛,增加用户点击欲望。

特别说明一下时间戳的规则,一般使用12或24小时制格式为标准。

  • 接收24小时内,时间格式显示展示为:时:分,如 11:02 ;
  • 接收超过24小时,且在今年的范围内,时间格式显示展示为:月-日 时:分;如12-12 11:02;
  • 接收今年以前,时间格式显示展示为:年-月-日 时:分;如,21-12-12 11:02。

五、总结

本文是笔者在工作中对消息通知系统重构的详细介绍,金融类的消息通知需要及时地将状态、内容的更新触达到用户,用户则可以根据收到的消息做后续判断。如果没有及时将重要消息触达到用户或者滥用消息,则失去了消息通知的初衷。

特别是针对涉及复杂任务流程的产品,消息类型繁杂,难以全面盘点消息类型,消息系统的设计就显得尤为重要。希望通过这篇文章让各位在设计消息通知系统的时候能够有所借鉴。

给TA买糖
共{{data.count}}人
人已赞赏

相关文章

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索
幸运之星正在降临...
点击领取今天的签到奖励!
恭喜!您今天获得了{{mission.data.mission.credit}}积分