升级功能改进中的思考

一、从强制升级到升级引导

       自家的产品目前iPhone端新版本的覆盖率不错,但Android略低。为了提高后续新版本的升级覆盖率,计划优化升级流程。

        一开始老大的意思是做静默下载,在wifi环境下后台自动下载好安装包,再进入端内的时候弹框提醒就可以直接安装,由原来的  弹框-确认-下载-安装  的流程顺序调整为,下载(后台静默)-弹框-确认-安装的顺序,从用户感知层面减少一个流程从而提高版本的升级覆盖。

        后续开始进行产品的设计的时候多考虑了一步。因为之前有一个线上版本出现过严重bug(开机广告正常5秒,出现的bug导致平均14秒才能进入应用,甚至出现根本无法进入应用的情况,虽然马上推出了debug版本覆盖,但由于已经对用户体验造成的伤害无法逆转,而新版本覆盖还需要一段时间,最终导致用户流失了近25%),为了今后出现类似bug对用户体验的伤害,准备再加上强制升级的功能,用户不升级到新版本就无法使用产品。这样限制的情况下,可以强行让用户跳过出现bug的版本,直接升级到正常版本。

        但之后发现这个思路其实是不正确的,一开始就已经跑偏了。跑偏的原因有三点:

        1. 这个版本要做升级功能的优化,目的是为了提高我们的版本覆盖率,并不是为了规避bug。从目的上看强制升级的是个伪需求。

        2. 强制升级的用户体验是很不好的,所以注定只能在及其特殊的情况使用,比如上文说到的重大bug。所以使用次数及其有限,投入产出的性价比不高。

         3.从为了让用户跳过bug这个角度考虑其实也是欠妥的,规避类似这样的bug应该放在上线之前,绝壁不能是上线之后(失去了25%的用户),QA应该全力保障不能漏掉这样的bug。

         所以后续设计的时候又把强制升级的部分砍掉了,设计流程的时候也费了自己不少时间,如果一开始能把这部分想明白的话就能生下来这部分的时间了。

二、从产品开发者的角度看

         升级流程中涉及到检查版本更新的时机,一开始自己想着为了提高静默下载的成功率,一天之内多次请求服务器检查更新信息(启动客户端请求一次,网络环境变化时请求一次),最后方案被开发哥哥喷的很惨。主要有两个地方没有考虑到:

         1.  多次请求没有必要。一是一天之内多次请求费流量,增加服务器压力;二是目前客户端更细频率基本上是一个月一版,迭代速度并不是很快,所以一个版本周期内,除了新版本发布的一段时间(1-2周),其余时间并没有新版发布,这段时间内的高频率请求都是没有必要的。

         2.  静默下载成功率和安装成功率之间应该是边际效应递减的过程。一味从提高静默下载的成功率上考虑来提高安装成功率后期效率并不高,应该从其他方面来考虑(即第三个方面)

         最后改成了一天一次,每天首次进行数据请求的时候会上传客户端日志,这时候会检测一次更新信息,然后非静默下载下进入端内会弹框提示下载,即静默和非静默下载相结合的方式。

三、弹框实现的过程

         第一次评审中老大提出了要让文案在每次弹框上都不一样,目的是用户如果第一次取消了升级,第二次弹框出现时能在文案上吸引用户升级。

         然后自己在后台上就设计了三个可配的编辑区,分别对应每次弹框弹出的文案。但问题随之而来:默认弹框频率是弹三次,第三次弹框上的取消键变为暂不提醒(然后就再也不出现了,现在看这个其实也欠妥,这不自己拉低了自己的覆盖率么)。但还有两种后台可配的弹框频率,每天一次和每次开启都会弹出。如果指设计了三个文案的话,后两种弹框频率的情况下怎么弹?难道要循环么,太凑活了,肯定会被喷。

        但这个问题其实还是应该回溯一下源头,做这个功能就是为了提高新版本的覆盖率,那么这个文案随弹框每次出现都会变化能不能提高版本的覆盖率呢?我认为效果极其有限,因为大多数用户基本上都不太关心弹框上的文案(或者App首次打开的蒙层引导),直接就会做出选择。所以为了达到最初的目标,应该做的是弹框本身的设计优化。目前升级弹框样式是由上到下为最新版本号、升级文案、取消、确认安装,其中取消和确认安装两个按钮一样大!这就很尴尬了。首先确认按键没有大小上的吸引力,其次用户能很轻松的找到取消键。应该改成弹框底部只放一个确认按键,弱化取消按键编程右上角的×号并更改色值和周围色值类似,不容易被看到自然吸引力没辣么高。然后应该加上一些情感化设计比如跪求升级之类的卡通人物什么的。这样要比单纯用文字去吸引用户要好很多。

四、 自我总结

         这次的功能设计中,自己还有很多有待改进的地方:

        1. 拿到任务自己喜欢先闷头苦想,缺乏跟别人的沟通和交流。比如上文的多次请求的问题,其实应该先去问开发目前我们的请求规则是如何的,是基于一种什么样的考虑来设计的。问题就能早日解决;

       2. 一开始就应该明确功能要达成的目的,然后在设计过程中应该经常性的回溯这一目的避免跑偏(比如强制升级的考虑),及时省下不必要浪费的时间;

       3. 老大说的不一定都对,要思考老大说的话的意思(主要还是目的),达成同样的目的有不同的方案(比如弹框提示的不同方案实现)

一不留神写多了……汗……

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 173,284评论 25 708
  • 发现 关注 消息 iOS 第三方库、插件、知名博客总结 作者大灰狼的小绵羊哥哥关注 2017.06.26 09:4...
    肇东周阅读 12,232评论 4 61
  • 我是个小蝌蚪,出生在大山里的溪流中。 我不知道父母在哪,记不得他们的模样。 但我并不孤单,我有一群小伙伴。我们一起...
    云风景阅读 361评论 0 1
  • 不得不说,有时候女人的直觉和第六感真的很准。午觉后,你说这几天一直没睡着,老觉得有事,但不知道是什么事。 果然,下...
    aZzz洁阅读 429评论 0 1