移动APP消息推送设计，真的就是Push这么简单吗？

　　简直每一个移动APP中都或多或少包含了消息推送的功能，在协同类东西中更是如此，不同人物、纷歧起刻点、不同途径、不同的信息等交错在一起，往往在剖析和规划时让人觉得犬牙交错。

　　其实，只需静下心划分好需求做的区域，再各个击破细化，规划较为凌乱的消息推送机制并没有那么困难。今日就以协同中很常见的某种单据阅览功用做个实例。

　　1开始规划之前

　　老规矩，请先不要急着翻开Axure。

　　因为面向协同工作人员，与一般APP的消息推送政策有很大差异，一般APP的消息推送更多是作为产品运营途径，而在工作流程中需求更多考虑业务流程怎么打通、各类分支怎么聚合、不同流程中的情况改动、什么样的人物在什么场景收到什么信息等等。把这些需求处理的问题先清楚地罗列拾掇出来。

　　2结构流程长什么样？

　　原型也好，细节说明也罢，其实终究都会映射至业务流程中。协同类的流程更是如此，一个结构性的流程图包含人员人物、操作、情况改动等多个特点。依据结构流程，后续可逐渐针对环节再细化分支流程。

　　业务流程是要点，因为这是直接政策导向的，让咱们知道这个功用究竟是为了做什么，是怎样一步步完毕这个政策的。流程除了说明逻辑关系以外，能够将操作的人物以及单据流通时的情况改动一一对应（其实也就咱们常说的：谁、什么时分、做了什么），这样能够让团队成员对全体流程闭环有更全面的了解。

　　3消息推送规矩

　　消息推送机制由服务端完毕，需求考虑到内部及外部的触发原因，再具象来说就是操作触发及自动触发（比如情况改动引起的触发机制）。再者考虑推送的政策，消息并不是面向一切人员都push的，要让奉告消息在正确的时间、正确的场景抵达正确的人手中，以确保消息的有用性。

　　这儿不得不说一下场景化的事儿。在需求评定的时分，咱们往往会抛出林林总总的场景：

　　“XX人员要是他自己就是想知道呢？”

　　“我觉得删去后会不会还想要把信息找回？”

　　“要是小明手机没带就收不到了。。。”

　　咱们在考虑场景的时分，经常会幻想出一些发生频率很低的极点场景，然后为了满意少部分人的需求而牺牲了多数人的操作体会。“场景化”应该是具有典型性而非全面性的，从来不需求做一个让任何人用的都满意的产品（其实也做不到），而需求做让大部分用户觉得满意即可。因此比较于可能发生但很少出现的情况，更需求考虑的是高频场景。

　　4拾掇共性字段

　　关于消息推送多类型单据组成的功用模块而言，在需求剖析时抓出共性部分能够有用前进后续制造原型以及开发完毕时间。有规矩，才有用率。其他在说明字段的时分，尽量不要把一堆文字洋洋洒洒铺了一屏，开发看了也累，能够以表格办法体现，如果能附上对应的页面原型就更好了。毕竟在展示中，字不如表，表不如图。

　　5其他：依据模块的页面结构说明

　　将一些机制规矩拾掇好后，后续就是在页面原型规划中将这些规矩融入。

　　因为各表单都依据结构化结构，因此在页面展示也上存在许多共性部分，这时分能够针对模块，规划出全局通用的页面结构说明。将复用的页面部分拾掇出来，至于用什么办法——以项目团队承受的办法即可（这时分才开始用Axure画原型）。

　　依据该模块的消息推送通用页面结构，划分了上中下三个区域，并对每个区域中的共性部分进行说明。

　　趁便说个题外话，因为之前发现开发有时会忽视下方详细的页面交互说明，所以当原型页面刚好占了一屏的时分，我就会放右下方那个“To Dear Coder”的小tip提示一把。

　　页面通用结构的详细交互说明，主要是规约页面上一些相同的操作交互，便于开发可带着模块全局观去查看每个不同类型单据中的差异功用需求点。规矩也好，页面也罢，都是先抓共性，再看差异。

　　之前朋友曾戏弄，APP消息推送机制不就是push几个消息嘛。Push消息是没有错，不过那是对用户而言，不好可不仅仅是服务端设置几个参数这么简略——“看起来典雅的天鹅，在水面下却拼命的划水”也是这个道理。要想让用户在适合的场景下得到自己需求的信息，仍是得乖乖从业务流程、推送规矩、字段信息、结构规划等方面拾掇，一起将推送机制交融至模块功用和用户场景中，然后确保信息推送的有用性和有用性。

　　6结语

　　关于一个产品汪而言，市场营销方案逻辑才干往往比页面规划才干重要（当然原型规划也是根底），但因为原型图是体现层的产品，咱们往往忽视页面不好的完毕机制。其实许多时分就像筑路，把每一个砖头都稳稳的铺好，天然就会构成一条路。