其实，只要静下心划分好需要做的区域，再各个击破细化，设计较为复杂的消息推送机制并没有那么困难。今天就以协同中很常见的某种单据审批功能做个实例。
开始设计之前
老规矩，请先不要急着打开Axure。
由于面向协同办公人员，与普通APP的消息推送对象有很大区别，普通APP的消息推送更多是作为产品运营渠道，而在办公流程中需要更多考虑业务流程如何打通、各类分支如何聚合、不同流程中的状态变更、什么样的角色在什么场景收到什么信息等等。把这些需要解决的问题先清晰地罗列整理出来。
框架流程长什么样？
原型也好，细节说明也罢，其实最终都会映射至业务流程中。协同类的流程更是如此，一个框架性的流程图包含人员角色、操作、状态变更等多个属性。根据框架流程，后续可逐步针对环节再细化分支流程。
业务流程是重点，因为这是直接目标导向的，让我们知道这个功能到底是为了做什么，是怎么一步步实现这个目标的。流程除了说明逻辑关系以外，可以将操作的角色以及单据流转时的状态变更一一对应（其实也就我们常说的：谁、什么时候、做了什么），这样能够让团队成员对整体流程闭环有更全面的了解。
消息推送规则
消息推送机制由服务端实现，需要考虑到内部及外部的触发原因，再具象来说就是操作触发及自动触发（比如状态变更引起的触发机制）。再者考虑推送的对象，消息并不是面向所有人员都push的，要让通知消息在正确的时间、正确的场景到达正确的人手中，以确保消息的有效性。
这里不得不说一下场景化的事儿。在需求评审的时候，大家往往会抛出各种各样的场景：
- “XX人员要是他自己就是想知道呢？”
- “我觉得删除后会不会还想要把信息找回？”
- “要是小明手机没带就收不到了。。。”
我们在考虑场景的时候，经常会想象出一些发生频率很低的极端场景，然后为了满足少部分人的需求而牺牲了多数人的操作体验。“场景化”应该是具有典型性而非全面性的，从来不需要做一个让任何人用的都满意的产品（其实也做不到），而需要做让大部分用户觉得满意即可。因此相比于可能发生但很少出现的情况，更需要考虑的是高频场景。
梳理共性字段
对于多类型单据组成的功能模块而言，在需求分析时抓出共性部分能够有效提高后续制作原型以及开发实现时间。有规律，才有效率。另外在说明字段的时候，尽量不要把一堆文字洋洋洒洒铺了一屏，开发看了也累，可以以表格方式体现，如果能附上对应的页面原型就更好了。毕竟在展示中，字不如表，表不如图。
其他：基于模块的页面结构说明
将一些机制规则梳理好后，后续就是在页面原型设计中将这些规则融入。
由于各表单都基于结构化框架，因此在页面展示也上存在许多共性部分，这时候可以针对模块，设计出全局通用的页面结构说明。将复用的页面部分整理出来，至于用什么形式——以项目团队接受的方式即可（这时候才开始用Axure画原型）。
根据该模块的通用页面结构，划分了上中下三个区域，并对每个区域中的共性部分进行说明。
顺便说个题外话，因为之前发现开发有时会忽视下方具体的页面交互说明，所以当原型页面刚好占了一屏的时候，我就会放右下方那个“To Dear Coder”的小tip提醒一把。
页面通用结构的具体交互说明，主要是规约页面上一些相同的操作交互，便于开发可带着模块全局观去查看每个不同类型单据中的区别功能需求点。规则也好，页面也罢，都是先抓共性，再看差异。
之前朋友曾调侃，APP消息推送机制不就是push几个消息嘛。Push消息是没有错，不过那是对用户而言，背后可不仅仅是服务端设置几个参数这么简单——“看起来优雅的天鹅，在水面下却拼命的划水”也是这个道理。要想让用户在适合的场景下得到自己需要的信息，还是得乖乖从业务流程、推送规则、字段信息、结构设计等方面梳理，同时将推送机制融合至模块功能和用户场景中，从而保证信息推送的有用性和有效性。
结语
对于一个产品汪而言，逻辑能力往往比页面设计能力重要（当然原型设计也是基础），但由于原型图是表现层的产物，大家往往忽视页面背后的实现机制。其实很多时候就像修路，把每一个砖头都稳稳的铺好，自然就会形成一条路。
