基于产品设计的插件化，谈谈App升级方式

　　更新升级是一款App长期迭代的关键方式。
　　在软件升级功能中，一般分为强制，提示和静默三种。静默一般就仅以红点或字样显示，干扰最小。具体的内容，可参看《细节体验你离用户只差一个好的交互》一文举例说明。
　　App升级更新是产品不断演变调优的必进之路。更新升级的目的就是在满足用户的核心需求的前提之下，增强原有需求的体验并加强相关的功能，免去或者减弱一些使用频次较低、相关度低的功能，从而让产品看起来简单且易用。一般来说，用户面对升级更新，都会显得很懒惰而不愿意升级，其原因大致分为三类：
　　认为升级是要花大量手机流量的，不愿意浪费；
　　认为核心需求在现有版本已得到解决，没必要更新；
　　已沉默的用户，已经不会经常使用产品，其更新意愿也不会强。
　　所以，为了避免“懒惰”的用户，尽量使用你精心设计的功能，第一步就是要学会引导他们乐意升级App。对于升级更新，通常来讲有强制升级、非强制升级两类。接下来，我们具体说明这两类升级方式的不同之处。首先，我们了解两种更新方式的逻辑流程如图所示，请细读：
　　强制升级
　　出现场景：适用于老版本需要废弃，全面启用新版本时，如：重大Bug影响核心功能使用，造成经济损失等
　　展示方式：显示弹窗，无法取消
　　非强制升级
　　出现场景：新功能上线，新的活动内容，部分插件内容更新
　　展示方式：通过小红点提示用户可升级，用户可自行掌控是否更新
　　用户开启App后，后台拉取更新协议（通常48小时一次），判断是非强制性更新的情况下，App更新的入口出一般会放置小红点，示意有新版本的可以更新。稍微友好的体验是，先检查是否在WIFI环境下，若是WIFI环境则系统后台直接静默更新，更新完毕前端展示更新弹窗引导用户手动更新。产品要不要刺激用户需求，从而影响用户去完成产品更新升级呢？更新升级的弹窗的设计及体验有什么窍门呢？这里总结两个原则：
　　原则一，言简意赅又要切中用户的需求或痛点地告知升级的主要内容；
　　原则二，保持版本更新的力与度，降低升级给用户所带来的不信任感。
　　对于业务丰富且偏平台化的产品来说，每一次版本的更新可能涉及商业模式的更替，主干流程的调整以及分支流程的调优。为了降低App升级所带来的用户体验最优化。越来越多App的产品经理开始学会使用插件化的方式，处理临时更新的模块及内容。
　　插件化设计，如同玩乐高拼接，同样的素材，如何做到具有想象力的模型，这就需要产品经理在设计产品的时候巧思并变通。一点有了插件化的思维，那么产品版本的更新就变得更加自由了。插件化设计组件，小Q曾在《一套适合ToB产品经理使用的工作方法》一文中有详细的解释和案例分析，可查看并了解。
　　插件的作用是：满足小众化需求，这类需求相对来说不是主流需求，把他们放在二级页面里面或者可配置的，可以满足喜欢用的用户，也对没有这需求的人没有任何影响。其优势是，降低产品试错成本，简化产品核心规则，无需在产品初期就实现非常复杂的产品形态。
　　可插件化的常见模块：运营活动模块、嵌入式引导文案模块（在线参数可配）、业务模块（主程序外的插件式程序支持，通过插件的形式支持不同业务需求，如淘宝App的各个频道）等。
　　除系统下的更新机制之外，如果是推出新的对于公司的运营有利的较重大功能的新版本时，则可以推出活动来激励用户更新，例如升级送积分。
　　由此可见，对于非强制性的升级的引导，我们需要根据App自身所处的阶段来考虑，一般有两类可能性：
　　第一类：发展期的App。这个时期的App通常已经积累较大量的用户群，且用户对App的功能较熟悉，那么则直接采取提示更新的弹窗即可；
　　第二类：成长期的App，新版功能的目的是为了积累用户，拓宽用户渠道，那么就需要添加新功能引导，首页进入提示（采用蒙层操作提醒等等），增加用户粘性。
　　最后，强调一点就是用户是最不喜欢被干扰的，所以对于非强制性升级的提醒，可以尽可能的采用能“跳过”的弹窗方式。可“跳过”的弹窗通常包括两类：一类是只有新版本第一次进入时弹出并提醒用户，另外一类是弹窗上加一个”忽视此版本“的选项，点击之后这个版本就不再提醒了。
　　小Q来总结
　　更新升级是一款App长期迭代的关键方式。因为在App设计之处，不可能把所有用户的需求及功能都实现，因此就一定会出现不断调优，更改的可能。
　　产品的设计与使用如同开车一样，随时都需要产品“握紧”方向盘，调整行驶方向，根据产品定位人群，产品目前周期，使用数据及更新的内容进行分析采用哪种提醒或引导方式，保证不打扰用户使用习惯的前提之下，合理使用插件化的设计，让你希望用户看到的功能，被用户使用。