DP

如何设计产品的更新

David Peng

2016-02-29

需求分析

用户基于以下几点需求:

  1. 用户认为新版本一般包含新功能,或者修正了以往版本的问题,能增强稳定性和性能,提升用户体验。
  2. 用户可以使用新功能,解决其新的需求。
  3. 用户希望软件能不断完善,尤其是 SaaS 产品的用户,如果产品一直不更新,用户会觉得厂商开发的活跃度较低,对用户不重视,进而影响对厂商的信任。

对厂商来说,有以下几个原因来提供产品的更新:

  1. 更新是衡量老用户活跃度的一个关键指标,一直更新产品的用户一般是活跃度和忠诚度都较高的用户。
  2. 更新是厂商对用户反馈的新需求的回应,如果能解决用户的问题,提升使用的体验,则能有效促进厂商和用户的良性互动。

什么情况下用户不想更新?

  1. 用户觉得现在的版本够好,能满足自己的需求,比如用 Windows XP 和 7 的用户。
  2. 用户觉得新版本比老版本差。这主要是厂商在需求把握、产品设计或产品质量上出了问题。比如用户认为 Windows 8 和 10 不如 7,所以一直不更新。用户觉得迅雷 7 广告太多,使用又卡,而 5 界面清爽,能满足下载的核心需求,所以不更新。用户觉得 iOS 9 不稳定,问题多,所以不更新。
  3. 用户没有更新的合适的条件。比如更新包太大,而用户的网络太差,网速较慢,下载更新需要大量的时间,所以不愿意更新。
  4. 新版本完全为了符合厂商的需求,而不考虑用户的需求。比如在新版中加入广告,而不加入其他的功能。

设计

在设计产品更新时,有以下几点设计需要注意:

自动检查更新

在应用启动时,能自动检查是否有新版本。因为总会有用户找不到从哪里更新,所以我们要主动帮用户检查更新。

手动检查更新

除了自动检查之外,我们也要有手动检查的按钮。用户可能会忽略掉自动更新的提示,但是后来又希望更新。比如这样的一个情景:用户要立即对 PPT 进行编辑和修改,这时弹出了更新的提示,用户会马上忽略掉。当他忙完了 PPT 之后,他可能会在空闲的时间更新 PowerPoint 软件,这时就可以使用手动检查更新的功能。

自动安装更新

对较大的更新,如果处理得当,可以让用户在后台下载更新,并在下次启动后自动安装和使用新版本。不能强行让用户下载更新,而应该让其设置,让用户对自己的电脑有控制权。微软为了让用户升级到新版本 Windows 10,自动下载安装包,导致用户的存储空间不够,或耗费大量的流量费用,这是不对的。

除了要注意让用户自己打开设置外,还应该考虑地更人性化。比如手机更新应用时,应该在有 Wi-Fi 时更新,而不能使用移动网络,否则可能会耗费用户大量的流量费用。

增量更新

如果安装包较大,应该考虑使用增量补丁的更新方式,从而避免让用户每次都下载很大的一个安装包或者数据。比如 Windows、iOS、Ubuntu 等操作系统的更新。

在线更新

尽量不要使用离线更新的方式,除非用户有这样的明确的需求。在线更新用户的使用成本更低,而且能保证让用户得到的更新是最新的,在日新月异的软件行业中,快速发布更新是至关重要的。有些情况是可以使用离线更新的,比如用固件安装老版本的系统。

快速下载更新

想办法让用户能更快地下载更新。可以考虑使用 CDN 分发更新包。或者使用 P2P 技术来提供用户下载的速度。比如 Windows 10 更新时可以使用 P2P 方式。使用 P2P 有用户隐私和安全相关的问题,这里只是举一个加速下载的例子。

描述清楚更新的内容

更新的内容应该有以下几种:

让用户能清楚地知道新版本是否值得更新。用户可以在简略的更新中,更加详细地了解更新。这一般是在有很多功能的产品发布更新时用到。可以加一个链接跳转到版本的页面,在这里可以查看新版本完整的更新内容。

要诚实地写出你的更新内容,不要刻意隐瞒某些可以告知用户的部分。

让用户分享他的更新

让用户可以方便地分享他的更新。有些更新用户如果觉得很好,他会想要分享给好友。这时我们可以保留一个新功能的页面,用户随时可以在产品中打开这个页面,并分享。

下载更新时要智能

比如支持断点续传,如果用户中断下载或下载失败,可以只下载未下载完成的部分,这样用户不用花费更多的流量。因为有时候运营商是按流量收取用户的数据费,比如手机运营商、某些大学的网络提供商。

安全验证

对更新包进行安全验证,防止用户安装经过篡改后的更新,避免对用户造成损失。

更新失败

更新失败时,要给用户明确的提示,并告知其如何能解决问题。

自动帮助

要能自动帮用户解决问题,而不是老是打断用户。比如下载完更新后,能马上安装并在下次启动时自动安装更新,而不需要用户手动干预。比如 Atom 编辑器。比如 Windows 的系统更新。

统计分析

所有的问题在解决后都要验证是否解决了问题,解决得怎么样,以便后续更加优化。所以要做更新的数据统计,能以数据和图表反映更新的实际情况。另外,要收集用户对更新的反馈。

广而告之

更新通知不一定要通过应用本身发布,可以使用各种方式公布,比如网站、微信、微博等社交网络、线下发布会。

A/B 测试

在发布之前做产品的 A/B 测试,可以在以下几个阶段做:

灰度发布

在完成 A/B 测试后,我们已经明确了给客户用的哪个版本更优。这时,可以向更多的用户发布了。因为我们在做 A/B 测试时,可能使用的样本并不多,不能保证所有的用户都喜欢新版本。所以这时可以用灰度发布的机制,让一部分用户先用新版本,其他用户仍然用老版本。

更新的注意事项

如果系统更新时,确保设备通电或有足够的电量,否则如果更新到一半,设备没电了,可能设备会变砖。

在用户使用移动网络下载较大的更新包时,提示用户会耗费较多流量费用。

不要这样做

强制安装更新

不要强制安装更新,而不通知用户,这样会让用户觉得无法掌握自己的设备。其次,用户的网络很差的话,下载更新会耗费大量的时间,一直在运行的下载进程可能造成用户的电脑比较卡。也可能会耗费掉用户大量的流量费用。比如 微软让 Windows 7 在后台默默下载 Windows 10。

©2020 David Peng ♥ 采用 Pandoc 搭建