pc是什么意思(如何从0开始)
编辑导语：消息系统是产品的重要组成部分，是企业产品与用户之间的桥梁。但如果产品不能有效向用户传递信息，就会影响后续的用户留存和产品迭代优化。为了去除杂乱，促进系统优化，应该做些什么来重建消息系统？本文作者做了相应的解读，大家来看看吧。
消息模块是每个产品必不可少的模块。消息系统作为用户和产品之间的重要桥梁，在整个产品的每一个周期中一直扮演着重要的角色。它必须保证企业核心业务流程的正常运行，传达用户的反馈。
本文将分为两部分，基于消息中心和平台的思路进行方案设计，最终落地消息中心和后台方案，以消息传递为基础，为公司不同的业务场景提供支持。
一、重建背景对于一家财务咨询公司来说，如何将专业的指导信息有效、准确、及时地传达给用户，是一项非常重要且核心的业务。随着新业务的不断叠加，由于没有系统的规划，现有业务存在很多问题，比如消息冗杂、消息分类不清、沟通方式不及时等。没有彻底的重建，就无法支撑更多的后续服务。
任何产品的一个重要模块的重建过程都是一项非常具有挑战性的工作，尤其是对于核心业务而言。原有的流程已经深入人心，前端的功能体验和交互方式已经被用户所熟悉和接受。如果突然做了很大的改变，用户重塑认知的风险会不会导致原有用户的流失，因为认知成本很高，业务人员会不会接受。很多因素是这个模块成功的关键因素。
下面，笔者将详细分享自己对于消息中心改造的设计经验(以下内容和数据有一些模糊处理，仅供参考)。
二、需求调研需求调研有很多种分类和方法。在这个消息系统的优化中，作者采用了内部调研和外部调研两种方案，下面详细说明。
1.内部研究如何对现有的消息系统有一个全面细致的了解，需要我们先找到一个突破点，消息的职能部门必须在日常工作职责中使用。
我们不仅要了解消息业务背后的痛点，还要对业务有一个系统的了解。如果需求调研更多的是解决一个点的问题，那么现在就需要了解和梳理整个流程，这样不仅可以知道更深刻的业务逻辑，也有机会对业务有更多的了解(作为一个新人，这是一种更快了解有需求业务的方式)。
方法一：相关人员走访调研
在实际调研过程中，确定业务部门的关键人物后，与相关业务人员进行面对面的访谈，是公司中常见的方式；不同办公室的同事也可以在线交流。
要提前想好问题，避免遇到需求方后不知道重点，导致研究无中心。在这里，我可以给你提供几个方向，帮助你在调查新闻业务时了解业务。
请列出我们部门需要通过消息推送发送给业务用户的业务。消息推送的整个过程是如何实现的？目前这些服务到达消息的途径有哪些？系统自动发送还是需要手动推送，发送频率如何？你遇到什么问题了吗？如何筛选现有渠道，微信官方账号推送/AppPush/站内信推？你认为有必要增加推送渠道吗？不同的渠道对应哪些业务场景？目前我们的消息服务能否满足现有的应用场景和客户群体？哪些短板可以针对更多有利于公司业务推广的场景进行优化？在没有消息渠道可以接触到客户的情况下，我们目前如何与客户沟通？沟通的结果是什么？有相关数据支持吗？要特别注意沟通，尽量把自己不明白的问题写下来，然后及时和相关面试部门确认，避免在后续计划的执行中遗漏更重要的解决方案。
方法二：收集相关资料
消息系统作为每个产品的基础模块，会在早期的版本规划中给相关的产品经理和技术留下相关的文档。如果业务方在具体实施之前没有明确的方向，我们可以通过内部调查来解决需求的真实性问题：
我们需要对齐产品内部的信息，并与相关产品经理了解其他模块和消息模块之间的业务关系，收集相关文档，避免优化过程中方案失效。其次，需要和相关技术负责人沟通，收集当前系统中的消息类型和发送机制，尽量让技术提供系统消息模板。这一步非常关键，因为随着业务和人员的变化，业务部门的人员提供的相关信息可能存在瑕疵和错误。看技术代码可以真实还原当前消息模块的具体情况。2.外部研究如果你对消息系统没有概念，只是知道这个系统的具体功能是什么，那是不够的。你需要进行深入的研究。我们可以进行竞品调研，大致了解你所熟悉的竞品和app的消息模块，这样你就可以提出足够有针对性的问题。
在短信模块的竞争力分析中，作者根据短信模块的特点，从业务层和体验层两大维度进行了分析。该表如下：
三、如何全面梳理消息系统关于消息系统，我们必须清楚的知道消息本身的底层逻辑包含了哪些主要维度，从这些维度来分析前台的功能设置以及后台需要配置的相关支撑数据。接下来作者用5W。
1H的方法，从5大维度进行分析。作为模块重建，通过对业务部门及内部产品的调研，我们不仅需要了解触发消息的业务都有哪些，还需要和业务方探讨随着业务的增加，有哪些新的业务需要新增消息提醒服务。
如运营部门现有的消息业务为课程打折活动，通过调研发现最近运营需要负责直播业务，此业务需要增加消息发送，我们需要先记录下此业务。
如：我们用直播业务流程完成的说明消息触发的条件举例说明：
直播创建后，当运营的同学成功上架一场新的直播活动，触发机制为运营在后台手动推送给目标用户，告知目标用户有新的直播可以预约；直播预约前，用户在直播模块的前端页面点击「预约直播」按钮，系统触发消息提示用户，本场直播用户预约成功；直播开播前，系统在设置的时间节点自动发送给预约用户，提示用户直播开始。即消息接收方，可能是系统中的全部用户，也可能会根据权限划分推送到某个用户群组，或者是某个特定用户；用户群组的划分，与用户的画像和业务紧密关联，如果后台已设置用户标签和画像库，则会使消息更加高效。
首先我们要先梳理，消息的推送渠道一共有哪些及这些渠道的特点：
电话；传统的电销模式下，电话提醒作为获客的主要手段，优势在于可以强提醒用户，并和用户做深度沟通，但是由于过度打扰用户，触发方式及渠道比较特殊，成本较高，所以这种提示方式需要甄别业务实施，不建议使用。短信；作为及时触达用户的一种方案，用于把重要且信息量较少的消息内容及时传达给用户的有效方法，如验证码、基金申购通知等。邮件；互联网2.0时代的重要的沟通方式，优势可以把信息量较大的消息准确地推送给用户。但是随着移动互联网的兴起，即时通讯APP大量的出现，邮箱作为主要的pc端工作交流的渠道，所以劣势就是无法及时提醒用户；如常见的消息业务员激活邮箱、验证码、银行账单等依旧在使用。push推送；主要是配合应用的出现，iOS和安卓系统的推送方式不同，iOS可以运用自身系统的原生推送渠道，推送规则一致；安卓则因手机厂商的规则不一致，则应用无法单独满足，一般会使用第三方服务；需要用户及时处理的消息则使用push推送。弹窗；主要作为用户前端操作反馈的及时通知，如订阅成功、直播预约成功等。站内信；作为主要应用消息的推送方式，可以把消息有效且准确地推送给目标用户，并在消息中心储存；应用类所有业务皆可使用此渠道。然后我们再去划分哪些业务的消息使用哪种渠道展示给用户；如直播业务中会涉及到的消息渠道：
直播创建后，运营在后台手动推送给目标用户，可以使用PUSH及站内信的方式展示给目标用户直播信息；直播预约前，用户在直播模块的前端页面点击「预约直播」按钮，系统触发tost弹窗/站内消息提示用户预约成功；直播开播前，系统在设置的时间节点自动发送给预约用户push消息，提示用户直播开始。消息的内容从功能设置上分为：只读与可操作。
只读，即当前消息用户在浏览后不需要做更多的操作，主要以了解为主；如申购基金成功提醒；可操作反馈，即当前消息需要用户浏览，且在浏览后做相应的后续操作；如补仓提醒。消息分类，需要和业务深度结合去进行消息分类的划分，目的是可以让用户用最短路径浏览到同类的信息，大概率可分为系统消息和业务相关消息，如果有社区，还会有互动消息之内的聚合。
通过梳理，此次主要需要对APP的应用级的消息进行重构，我们先明确优化渠道：push推送、站内信。
并通过业务侧的调研，消息主要的问题是新业务不断叠加，因为没有进行系统的规划，造成了现有业务消息冗杂、消息分类不明确，所以我们需要通过对业务消息进行分类合并，重新梳理消息的类型的划分，并从前端展现形式上对消息类型作出明确的划分。
Push的前端展示样式主要有：标题+摘要、标题两种展现形式；在不同的业务条件下，这两种展示都能够使用，所以要求我们设计后台的时候需要注意字段的扩展。
我们要注意的是由于Android和iOS机制不同，此处区分两个平台讲解。
1）Android
国内Android系统均为定制过的ROM，需将APP与各大手机厂商均有合作添加产品白名单，或将APP加入手机自带的安全工具白名单，这样才能保证推送不会丢失，因为和各大手机厂商对接的成本太高，一般情况下我们会接入第三方服务商（如：极光），各厂商字符规则如下：
2）iOS
iOS的推送需要通过苹果官方服务器进行推送，跟进程存活没有关系，前提是用户开启推送通知权限。
站内信的优化我们从两方面入手，首先需要业务方对消息进行整合分类整理，划分出明确的类型，从类型上减少用户识别路径；其次对于消息的入口、消息列表的展现形式，缩短用户查看消息路径。
1）消息入口
金融类的产品，消息入口常见的展现形式有底部主要导航tab、顶部图标入口两种形式：
底部主导航特点：此类设计说明消息模块在此产品中，用户的使用频率比较高，并且通过消息展示够让用户做出对主要业务影响的操作。顶部图标入口特点：一般会用在产品需要消息及时触大用户，且不做为主要业务，设置在顶部的优势，可以灵活地设置在需要消息支持的业务模块的顶部。作为金融属性的产品，信息的及时披露对于用户的交易和服务都是非常重要的，所以我们在设计消息入口的时候，会选择灵活性和即时性都兼顾的产品设计，这两种设计都可以对于重要的消息类型可提供数字badge作为未读消息数量的提示。
2）消息列表
消息列表为笔者这次改造的重点区域，从消息入口点击后跳转到消息列表，由于业务的增加，造成消息类型不明确，消息等级错乱，通过竞品调研，主流金融类产品的消息列表为以下两种形式，消息分类合并或者分tab的方式。
两种模式的区别在于，如果消息分类比较多，还有二级消息分类的情况，则使用分类合并的产品设计，列表的展示比较简洁，用户可以清晰地获取消息分类信息。
此外如果消息的二级分类列表，也可以使用二级分类列表，则可以使用tab交互方式，列表的排列顺序可以按照业务重要性质进行默认排列，信息详情按照时间的倒叙排列；大家可以按照自己的产品的具体情况设计产品方案。
3）消息列表详情
消息列表详情，主要的功能使用户不用点开消息详情，对主要消息内容有所了解，主要有以下几种类型：
标题+时间戳+内容概要（消息内容的固定字数）：一般会用在消息频率很高，消息内容比较长的消息或者消息字数比较少的消息列表详情，如新闻类资讯或者交易提醒，只读取固定字数的消息内容，需要用户点击进入查看更多消息内容，交互特点为未读读时，文字为高亮状态，点击查看后为变灰；标题+时间戳+内容概要（消息的关键内容）：对于消息内容可提取主要的概要字段的消息可以使用此列表详情，提高用户获取消息内容的效率，使有效信息可以及时触达用户；如收益情况等；标题+时间戳+图片+内容概要（消息的关键内容）：一般活动消息使用此列表详情，消息频次比较低的消息也可以使用，增加活动图片可以烘托活动气氛，增加用户点击欲望。特别说明一下时间戳的规则，一般使用12或24小时制格式为标准。
接收24小时内，时间格式显示展示为：时:分，如11:02；接收超过24小时，且在今年的范围内，时间格式显示展示为：月-日时:分；如12-1211:02；接收今年以前，时间格式显示展示为：年-月-日时:分；如，21-12-1211:02。本文是笔者在工作中对消息通知系统重构的详细介绍，金融类的消息通知需要及时地将状态、内容的更新触达到用户，用户则可以根据收到的消息做后续判断。如果没有及时将重要消息触达到用户或者滥用消息，则失去了消息通知的初衷。
特别是针对涉及复杂任务流程的产品，消息类型繁杂，难以全面盘点消息类型，消息系统的设计就显得尤为重要。希望通过这篇文章让各位在设计消息通知系统的时候能够有所借鉴。
本文由@大大大大大浪原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议