写在前面：
关于通知的设计在现阶段的形式有很多，例如Toast，Modal，Noticebar等等以及每种通知形式的用法，每个通知形式都有前人总结出来很好的使用方式，但有两个弊端，第一、每种形式都是深入思考总结出来的规律如果不了解其中背景及背后的思路历程很难真正将知识融入到个人的思维体系中；第二、各种通知形式之间有太多的交叉点，信息分类不够独立，如果只留于表面去用在日常的交互设计里，很容易被这些碎片化知识所淹没。
所以触发我思考的动力也是本文的目的是：一、建立体系化思维，在这些前人总结出的知识里，帮助个人的思维模型中构建每种知识之间连接。二、从全新的角度去整合分类这些信息通知的设计，找出知识之间相对独立的规律，从而在使用过程中能针对每次不同业务特点的输入，快速的输出相对系统完善的通知设计方案。
本文旨在和大家探讨，我也非常高兴能有不同观点之间进行碰撞，这样才能将思维模型构建的更清晰完善。
1.使用范围：
Web端交互/视觉设计（其他端也有参考意义）
2.通知设计的规律总结
这篇规律的边界在于，我所说的“通知”是指系统对用户进行单向的信息传递，即信息的流向为“系统”到“用户”，包括大家理解的消息，提示，告警，通知等等一类，只要属于系统对用户具有时限性的信息传递都在这个规律内，但是不包含“用户”到“系统”的信息反馈过程。
通知案例收集
下面收集了一些国际上比较有影响力公司的界面案例，因为重在总结出我的规律，所以对于案例我就不详细与大家介绍。
有没有发现，即使是同样的界面表现形式，每个公司团队对于它们的理解/命名/用法都不一样，国内关于这类的文章现状也是这样，我们可以先暂时抛开对名字符号的记忆，只要我们将背后的语义达到共识，但如果有更好的名字符号能准确的表达语义欢迎告知。
下文中对通知进行规律总结的基础源于交互界面中“层”的概念。
什么是“层”
在现阶段真实的产品生态中，我们大部分的操作界面都是在一块平面的屏幕显示器上，所有的界面都可以看成是的压缩在一个平面中（VR/AR界面除外），在我做设计的过程中会尽量理清各个界面层之间在空间上的分布关系以及归类各个层的特点，如果用一句话概括就是界面元素之间的遮挡关系。
通知在操作维度上相对独立于系统当前的交互操作，我们只需依据业务诉求设计页面通知方式来达到的目的，那么当输入的是不同的业务诉求，我们需要给出的输出是什么时候用什么界面通知形式，和构建怎样的界面通知体系。
首先，通知的设计从业务上包含两个维度即紧迫性和重要性，在设计上有三种表现形式即界面层次、视觉效果和回收机制。
这里我构建的第一条知识之间的连接规律：紧迫性影响界面层次，重要性影响视觉效果和回收机制
在紧迫性维度上
紧迫性影响的界面层次再分为三个层次，分别是操作前、操作中和操作后，从而将系统中的“通知”分为三个层级。处理的是多个界面间的分布关系。
第一层为操作前，是指用户在界面操作时覆盖在当前操作界面层上的一层，通常表现为紧迫度最高，系统需要用户立即了解的信息。典型的界面交互表现形式有：Modal、Flag、Toast 等等
第二层为操作中，是指用户在界面操作时的界面层，紧迫性上为中，系统需要传递给用户的信息没有那么紧迫。典型的界面交互表现形式有：Noticebar、Inline notification、Statubar等等
第三层为操作后，是指用户在界面操作时置于当前操作界面层下的一层，通常表现为紧迫度最低，系统不需要用户立即了解的信息。典型的界面交互表现形式有：Message box等等
在重要性维度上
重要性影响的视觉效果包括：视觉层级（视觉对比、元素大小、色彩冷暖、等等）、视觉位置（相对于上一项操作的视觉焦点的视线中心/边缘区）、视觉信息转换率（易理解的视觉信息、信息与用户意愿相关度等等）。处理的是一个界面内的分布关系。
重要性影响的回收机制包括：手动回收、自动回收
在使用的时候，只需根据业务诉求，判断系统对于用户传递信息的紧迫性和重要性两个维度的特征上去设计或者使用相应的界面表现形式，去构建自身系统的界面通知体系规则。
Part 2 里包含两个部分，第一是从上面提到的各大影响力的国际产品中深入分析，来验证我构建的思维模型，第二是运用这种思维模型如何在实际的产品设计中进行从0到1的构建通知体系，也就是从这里构建的世界观到输出可用的方法论工具。
下一部分的预告图
公众号：WuP的想法
Dribbble:https://dribbble.com/WUPENG
网友评论