APP的消息通知设计：你的APP适合什么样的通知模型

1、消息中心的设计差别：针对以交友为主的通讯软件与以内容为主的社交软件

在以交友为主的通讯软件中，通讯录与消息中心一般是并存的。方便用户从好友中迅速发起聊天。以内容为主的社交软件，比如K歌，微博等，消息系统内嵌于一个APP中，用以辅助用户间沟通，通常情况下好友列表和消息中心是分离的，可以在消息中心右上角嵌一个通讯录入口，但不宜太重。主要原因如以下：

（1）辅助型的消息中心，用户发送消息的场景一般在浏览信息时产生，如刚好读到一篇文章，刚好听到一首歌，突然有感，发送聊天消息。

（2）消息中心的用户列表，是通讯录里好友的精华，即亲密的好友，基本会存在于消息中心的聊天记录中，可以满足很大程度的用户聊天需求。即使是熟人社交，如微信，找一个好友聊天，基本上从消息中心进入，其实是通讯录搜索，不记得备注的时候，才会翻页查找。

2、消息中心的样式

一种是包含固定位置分类，一种是全部聊天记录随机。如果基本没什么广告，都是核心的用户聊天，推荐后一种，其他的推荐第一种，确保核心消息优先显示。对一个联系人的主要三个功能：备注、消息免打扰、拉黑、删除好友。

拉黑应该是基于好友的，也就是拉黑之后，再解除应该还是好友关系，要不然有删除干嘛。微信只做了一对一的屏蔽，并未做群的屏蔽。

3、消息中心的页面逻辑

（1）消息推送：

①实时推送对比拉取难点和有点在于：实时接收，消息的连续；

②消息的推送分为离线推送（借用手机系统，开启消息通知，对客户端来说是离线的），在线推送，手机拉取

③消息本身以及小红点是两套推送

④每个人的消息都是独立存储

（2）聊天刷新：

①聊天框内实时推送

②消息中心实时展示

朋友圈的消息提醒，有一个消息中转页面，另外一对一的消息，A评论B，B回复A，A收到消息；同时C评论B，A也收到消息。

（3）删除数据：

①聊天框内数据删除，消息中心的预览内容以及时间展示同步更改

②拉取历史聊天记录数据。例如一个月内，一个季度内有聊天的好友。

（4）数据保存：

①客户端保存

②分页加载

（5）版本兼容

①消息大类的兼容

②消息内部的兼容，规定具体的格式。

来源(Source)： 这是APP中生成通知的源头。每个APP根据自己不同的内容体系可以有多个内容池，当系统、其他用户或者用户自己的操作引起内容池变化时便会产生通知。

信息(Information) ：以通知为载体传达给用户的消息。比如说“Jesse申请成为你的好友”或者“James赞了你的推文”。

徽章(Badge) ：引导用户查看通知的视觉元素 。徽章里的指示可以是一个简单的点，也可以展示未读消息的数量。（对于强迫症患者来讲，徽章就是“恶魔”）

锚点(Anchor) ：指的是界面中用来引导用户进入通知的提示位置。简单来说，锚点就是用户看到通知指引或显示徽章的地方。锚点并不一定只能通知来源的地方显示，也可出现在你希望体现有通知的地方。锚点可以用来展示多种来源的通知，当然也可以只展示一类。你可以这样想，来源是信息架构层面的概念，而锚点不过是你可以看到徽章的视觉元素。

通知是App与用户沟通的一种方式，提高用户再次进入App的可能性，增加用户的粘性，同时也有几率唤醒那些沉默用户。因此通知是APP中十分重要的部分。常用的App通知模型主要有以下几种：

一、通知中心式

在这个模型中，将App内所有的通知都放在独立的通知心中里。通知中心可以是一个精致的页面，也可以是一个弹窗，这可以根据需求及使用场景来确定。

无论通知的来源是什么，所有的通知都被锚点到通知中心里，然后再对通知进行导航分类。Medium就是使用这种模型，底部导航中的铃铛图标会出现徽章，从而作为指向所有通知的入口。视觉上区分已读和未读通知变得尤为重要，用户需要清晰地辨别这两类信息。

这种方式的优点在于比较灵活，扩展性较好，通知中心的入口可以根据需要进行调整，后续即便是增加了新的通知类型，只需在通知中心内部调整即可，对其他模块没有影响。

缺点就是众多类型的通知放在一起会略显杂乱，最好用tab加以区分

设计原则：

所有不同类别的通知都需要使用同一种设计模式，而且一定要考虑这种模式的扩展性。

如果你有太多通知来源，可能会出现界面乱糟糟的情况，这时候你就要考虑将同一类的通知合并成一个组，有助于减少信息重复出现。例如：James与2位好友开始关注你。

请确保通知中心的入口容易被发现和触达。

通知中心式适合于：

产品中的通知无法被锚点到任何一个已有的导航中。可能因为通知不和已有内容一致，或现有内容架构中并没有生成通知的来源。

有些来源的通知在已有页面中无法承载。

当时间很紧急，你可能很难把所有可能的通知场景该如何锚点都细想一遍。这种情况下，通知中心是一个很简单的方案，在实际操作中也很灵活。

二、来源锚点式

这种方式中，所有的通知都被锚点到导航的菜单中，这些菜单也正是通知的来源。

APP中并没有一个共有的通知中心。看下WhatsApp的截图会更易理解，无论是安卓还是iOS版本，通知被锚点到了各自的来源——Chats和Calls。

这种方式的优点在于内容极易被发现，凭借通知用户可以非常直接地获取到信息，过程中无需进入额外的中间页。不过这种方式的灵活性和伸缩性不如通知中心式，一旦后续需要调整，可能各个消息来源模块都要改动，工作量会较大。

这种方式高度依靠APP本身的信息架构，导航本身必须可以容纳不同类别的通知，即所有的通知必须有与之对应的来源模块。和上一个模型一样，这里也需要通过视觉设计来区分已读和未读通知。

设计原则：

确保每一个通知可以和导航里的菜单对应起来。随着你APP复杂度的增加，各个通知的来源也随之变多，这个时候你可以考虑使用通知中心或者混合式的模型（把通知中心式和来源锚点式混合起来）。我们将在下一个段落中讲到混合式。

每一个锚点的设计模式应该可以承载各自的内容，并确保你的通知适合这种锚点的设计模式。用WhatsApp举例，锚点“聊天”本身有自己的设计模式定义了每一个聊天应该长成什么样，那关于聊天的通知就必须跟随这个设计模式。“电话”也是同理。

确保每一个锚点都易被发现与触达，尽量避免在子级页面中出现锚点。

来源锚点式适合于：

当所有的通知的来源可以被安置到APP首页（包含主导航）中。

你必须仔细想一遍所有需要通知的场景，且所有的通知可以被安置到现有的设计模型里。通知和来源的设计模式必须保持一致，这一点很重要。

三、混合模式

顾名思义是前两种模式的混合体，且使用最为广泛，Facebook、LinkedIn、 Twitter、Instagram等一些热门APP都在使用它。

例如：Facebook，消息中心变成了主导航中的一个菜单，用来展现哪些无法在主页面中展示锚点的通知。Facebook把好友邀请的通知锚点在了主导航的好友菜单中，而把推荐用户锚点到了通知中心。

这种模型同时具备了前两种模型的优点并且可以适用于大部分情况。虽然你现在可以把所有通知都锚点到通知中心里，但仍有必要仔细考虑一下是不是有些场景的通知更应该优先使用来源锚点式。

设计原则：

定义产品体系中所有的内容池，并按重要等级排序，这样可以帮助你列出哪些通知应该被锚点到来源，哪些可以直接进消息中心。由于这种模型与导航非常相关，通知的配置方式会影响到你导航的设计。

确保主锚点和通知中心易被发现，并且作为主页导航的一部分。

混合式模型适用于：

当你仔细考虑通知的场景后，发现一些通知可以被锚点到对应的来源中，但是有些却找不到已有的来源。

在你的导航体系中，有些来源藏得比较深。举个例子，Facebook导航中有个汉堡包餐单，当他的二级餐单中有通知来源时，汉堡包餐单就会变为锚点，例如：小组、视频、那年今天、收藏夹等。

结论

上述的模型都要用在正确的场景中，根据你APP的信息架构来选择合适的模型，可以让通知发挥更好的效果。

原文链接：https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96

提升商业效率需要引导用户打开app-使用app-活跃于app-留在app-进而实现变现

app消息中心需要满足业务需求以及用户需求

业务需求：

（1）评论/回复：引导用户发布评论，参与回复，让用户活跃在app，用户之间的互动提升了用户和产品之间，用户和用户之间的粘性

（2）收到的赞：奖励机制、用户在看到有人对于自己发布的内容给予了肯定，在心理上会产生积极的影响，会有继续输出内容的欲望

（3）私信：引导用户对私信者做出反映，促进用户之间的交流

浏览内容-发布内容-互动，促进用户成为平台内容的消费者和生产者，实现功能的良性循环，进而吸引更多的用户使用app；用户在平台输出内容，平台可以使用算法抓取用户的数据，用户输出的越多，获得的用户数据越多，得到的用户画像越精准

用户需求：

（1）评论/回复：浏览其他用户对自己的评论，获取到自己评论之后得到的反馈

（2）收到的赞：了解自己发布分享的内容的得到的反馈怎么样，根据点赞的结果对以后发布的内容进行改进

（3）私信：方便和其他用户进行交流

设计关键因素分析：

动机（为什么要设计消息中心）：设计消息中心的目的是提醒，引导用户使用app，关注到用户之间的互动，从而建立用户和产品之间的连接，进而实现变现

担忧（设计消息中心会有什么担心的）：消息中心频繁的推送通知，提醒用户，但是有效的信息很少，无效的互动很多，这样会招致用户的反感，反而会降低用户留存率和活跃度

根据以上关键因素的分析，消息中心的设计既要实现商业效率提升，又要不引发用户的负面情绪，所以除了以上的基本消息，还需要提供用户“全部标为已读”和“屏蔽某人消息”的功能

为什么要添加这个新功能：

爱奇艺手机app是一款PGC平台，强调内容，更像是一个服务商，平台购买版权，通过内容吸引用户付费或观看，为了吸引到更多的用户，继续购买版权，商业模式比较单一，变现的方式只有会员机制和广告，为了吸引更多的付费用户购买大量的版权从成本上来说是高昂的

爱奇艺需要更高多的商业模式和变现渠道，实现更稳定的资金流和商业闭环，我认为可以强化社区功能，现在的爱奇艺泡泡虽然满足了用户的期待型需求，可以进行社交和讨论，但是并不能为爱奇艺带来有效的变现渠道，爱奇艺用户群体都是带有目的性使用这款app的，比如想看某个综艺或电影才会使用，用完了就走，相对来说用户的粘性和活跃度都比较低

添加什么新功能：

带着提升活跃度和用户粘性以及寻找更多变现渠道的目的，可以给爱奇艺增加一个“泡泡圈”的功能，这个功能允许优质用户建立自己的泡泡圈，泡泡圈的主题可以是电影、动漫、游戏或者某个二次元的爱好，把泡泡圈按照不同的兴趣爱好和人群属性进行细分，打破次元之间的壁垒，让用户可以在泡泡圈发现更多兴趣爱好相同的人，泡泡圈相当于一个基于兴趣爱好的陌生人社交的社群，可以提供基础的聊天，发布信息等功能

进阶功能：

泡泡圈基于兴趣场景吸引到更多的用户，用爱好圈住用户，提升用户和产品、用户和用户之间的粘性，为了帮助爱奇艺实现盈利，可以给泡泡圈增加更多的进阶功能，比如圈主付费就可以解锁语音功能、视频功能、声音特效等等；圈主付费可以升级泡泡圈的容量，比如基础的是200人，付费之后可以有400、500甚至更多

欢迎批评指正讨论

公众号-产品offer看我