消息通知是应用程序与用户通信并可能将用户带回应用程序的媒介之一。因此，App通知模型是应用程序设计的一个非常重要的部分。通知中心、来源锚定和混合模式，分别适合不同的消息来源与查找习惯。这里讨论的是App内部的通知入口与消息归属，不是手机操作系统的推送样式。先确认用户在哪里找到消息、点开后去哪里，才能选择合适的模型。
模型确定后，可以借助Pixso 的原型协作能力串联消息列表、来源页面和返回入口，让团队沿着同一条通知路径评审，检查已读状态与上下文是否衔接。
1. 通知中心
在通知中心这种App内部通知模型中，你的所有消息通知都会放置在一个已定义的位置。通知中心App通知模型，可以是专用屏幕或弹出窗口，具体取决于可用空间。在此通知模型中，所有消息通知都锚定到通知中心，无论其来源如何。然后，你可以从通知中心导航到消息通知的来源。这种App通知模式的最大优点是它的灵活性。这是一个可以容纳所有消息通知的地方，无论是来自现有来源的还是新的东西。
通知中心使用场景
-
所有不同类型的消息通知都必须经过深思熟虑，并且应该遵循相同的设计模式。在设计模式时，将可伸缩性视为我们的主要目标很重要。
-
如果你的消息通知来源过多，此模型可能会开始显得有些混乱。如果有类似类型的消息通知，你可以将它们组合在一起，这将有助于减少重复。例如，“张三和其他 3 人向你发送了好友请求”。
-
确保通知中心易于发现和访问。
注意事项
-
如果你的产品需要无法锚定到任何现有导航选项的通知，这可能是因为消息通知与产品上的现有对象不一致，或者消息通知不是源自信息架构中定义的任何来源。
-
可能的App消息来源比主界面能够容纳的入口更多。
-
当你时间不多的时候，比如在某些情况下，你可能需要在有时间考虑所有可能的通知场景并找到每个消息通知的锚点之前发布一个功能。在这种情况下，通知中心可能让你柳暗花明又一村，因为它本质上非常灵活。
2. 来源锚定通知
在来源锚定通知模型中，每个消息通知都锚定到一个导航选项，该选项也很可能是通知的来源。你的所有消息通知都没有一个集线器/中心。该模型在很大程度上取决于App的信息架构。
导航必须能够适应所有不同类型的消息通知。与之前的模型一样，此处的已读通知和未读通知在视觉上有所不同也很重要。消息来源是聊天会话时，聊天未读消息的定位应从首条未读开始，并提供返回最新的入口，不能只清除导航红点，却让用户在长记录中重新寻找阅读起点。
来源锚定通知使用场景
-
确保每类App消息都能对应到主界面中的一个明确业务入口。随着应用程序复杂性的增加，通知源的数量也可能会增加。在这种情况下，你既可以选择通知中心，也可以考虑混合模型（即来源锚定通知模型和通知中心的组合）。
-
每个锚点都应该有一个它所容纳的内容的设计模式。确保你的消息通知符合锚点的架构。
-
确保锚点易于发现和访问。避免使用嵌套锚。
在以下情况下使用来源锚定通知
当主界面能够清楚呈现各类消息的业务入口时。
3. 混合模式
该模型是两种模型的组合。混合模式适合消息来源不同、又需要一个集中回看入口的产品。在这里，通知中心成为导航菜单中的选项之一，可以收纳没有独立主导航入口的消息。
该消息通知模型具有两种模型的优点，并且可以轻松适应大多数情况。尽管现在你可以将通知锚定到通知中心，但仍然必须考虑所有场景并优先考虑来源锚定通知可以适应的情况。就像来源锚定通知模型一样，这个模型也严重依赖导航菜单，现在也有通知中心作为选项。
混合模式通知模型使用场景
-
识别并排列产品架构中最重要的信息类别。对它们进行排名将允许你优先考虑哪些消息通知应该锚定到源，哪些应该进入通知中心。
-
确保主要业务入口和通知中心都易于找到，不依赖层层展开才能发现新消息。
注意事项
-
你已经考虑了消息通知方案。你有一些消息通知可以锚定到它们各自的源，但其他一些通知不能锚定到体系结构中的任何现有源。
-
你的导航中有嵌套的来源。
先列业务事件，再决定消息归属
以同时包含订单与社区的App为例：订单发货与某一笔订单明确关联，评论回复属于某一条讨论，优惠活动可能跨多个商品，账户异常则关系到整个账号。前两类有稳定来源，适合在订单或评论入口提示；后两类不能硬塞进某个商品页面，可以进入通知中心，再通往活动说明或账户安全页面。
通知中心与来源入口也可以同时存在，但它们应指向同一条业务消息，而不是各自生成一条副本。比如一条评论回复在“互动”标签显示红点，也出现在通知中心；用户从任意入口读过之后，另一处应采用同一已读状态。这样的混合模型保留了集中回看的便利，也没有丢失消息的业务语境。
不要把所有消息都设计成必须立即打断的弹窗。是否提醒、是否置顶和是否需要立即处理，与消息放在通知中心还是来源入口是不同决定。Carbon 的通知指南区分了提示信息、成功、警告、错误及可操作通知，也建议让用户能回到通知中心处理过去的消息。
读过一条消息，不等于完成了它的任务
“有人回复了你的评论”通常在进入对应讨论后就可以标为已读；“订单地址待确认”即使被读过，也仍可能没有完成确认。前者解决消息是否被看见，后者解决业务任务是否完成。把二者都压成一个红点，容易让用户误以为点开就处理好了。
可以在通知列表保留“待确认地址”这样的任务状态，在订单详情中提供真正的确认入口。用户选择“全部标为已读”时，只改变阅读状态，不应替他确认订单、接受邀请或批准申请。操作成功后，再让列表里的任务状态随实际业务结果更新。
点开旧消息时，避免落到一张空白页
如果评论已被删除，落地页可以说明“这条评论已被删除”，同时提供返回原讨论的入口；如果用户不再有查看订单的权限，则说明权限发生变化，并给出返回订单列表的路径；优惠活动过期时保留活动已结束的说明，不要把用户直接送回首页而不解释原因。能否显示原消息内容还应服从当前权限。
在 Pixso 中，用一条“评论回复”分别连接通知中心、互动列表和讨论详情，再为“已读”“待处理”“内容失效”补上状态说明。团队由此能讨论同一消息跨入口的一致性，而不只是讨论红点用什么颜色。通知文案和出现时机的设计，可继续阅读通知提醒体验的设计方法。
4. 专业的在线协同设计工具Pixso
Pixso是一款在线UI/UX设计工具，在App移动UI设计、交互设计方面也是很方便的，并且它可以进行团队协作，查看相关反馈，这对于我们的设计师设计App通知栏来说非常有用。
除了以上基本的交互操作，Pixso还有很多非常实用的功能，比如说具备实时在线协作、一键交付、多功能文件导入、全局样式、自动布局、团队协作等多个功能，通过低代码交付，开发人员可查看设计属性、标注和可用的代码片段，具体业务逻辑仍需开发实现。
通过这些Pixso设计工具能够有效解决以往设计中，团队沟通难、设计效率低、资源管理乱等痛点。因此，这里Pixso设计师强烈推荐大家试用一下，相信大家会有很多收获。
