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