重构类产品方法和经验分享
前言
之前做过这么一个项目，需要对公司下一个较为核心的平台做大的改版，旨在解决旧版平台功能割裂感强、流畅性差等问题，而这次重构复杂度也很高，历时整整一年，算是比较典型的大型重构项目，最终平台的规范性、易用性都有了很大提升，新的平台也获得了很多用户的认可，与此同时，通过这次的重构也带来了很多新的收获，实际上重构类项目和日常功能迭代有着很大的区别，相应产品方法也不尽相同，对于重构我们不仅要考虑功能本身的体验和效率，还要和已有习惯做平衡或斗争，即使新的操作习惯能带来更高效率，但是这个改变本身就是痛苦的，这会带来加倍的阻力。
那么如何完成一个大型重构，有什么样的框架可参考，重构有什么额外关注点，有哪些可借鉴的经验，是这篇分享希望带来的——提供一个重构方法论的参考示例。
重构阶段拆解
对于一个平台的大型重构按阶段拆分可以拆成如下多个环节，其中高亮部分是重构项目中很容易忽略的环节，例如很多重构项目可能会忽略二轮调研验证，就可能加大后续线上实验的成本，下面会详细说明：
环节1：产品方案设计/交互
环节2：一轮用户调研（用户场景与痛点收集）及可用性测试（产品方案纠偏）
环节3：详细UE/UI设计
环节4：二轮用户调研（新功能场景验证）及可用性测试（交互及视觉方案纠偏）
环节5：技术调研与实现
环节6：内部众测debug
环节7：三轮用户调研（极小范围真实用户测试及走访验证）
环节8：发布前准备工作（功能引导、亮点触达、反馈渠道、运营培训）
环节9：小流量开放
环节10：推广及放量阶段
环节11：完成全量新旧共存阶段
环节12：小流量下线旧版
环节13：完成全量切换
产品方案及调研阶段（1、2环节）
环节1：产品方案设计/交互
环节2：一轮用户调研（用户场景与痛点收集）及可用性测试（产品方案纠偏）
对于大型重构需要做详细的一轮用户调研，在这个环节需要保证样本丰富度和代表性做好客户分层，目的是梳理用户场景以及收集痛点，基于对平台问题和优化方向有基本思路的前提下有初步产品方案，在调研过程中能做初期的可用性测试和产品方案纠偏。
而在实际调研及产品纠偏过程我们需要不断打破思维定式，挖掘不同用户的真实诉求，并从中做取舍，从展示形式到布局，去尽可能满足用户的实际操作场景和诉求，如果在产品方案的时候能输出高保真原型，那可以直接利用一些工具（如蓝湖）实现可交互效果，用于做可用性测试，这样能加速前期进度。
交互及视觉阶段（3、4环节）
环节3：详细UE/UI设计
环节4：二轮用户调研（新功能场景验证）及可用性测试（交互及视觉方案纠偏）
当方案确定需要进入正式的交互和视觉设计，UE一般在1、2阶段就需要参与进来，在第3环节则需要进入到正式的设计阶段，考虑到每一个细节，对于复杂的操作流程需要有可交互demo来准确传达交互效果，让技术更好的理解交互细节避免理解不一致问题。同时需要注意的是，一般大型重构周期跨度会很长，如果UI稿距离正式开发时间有较长间隔，开发前一定要再次check UI稿确定是最新版本，避免按老版UI开发导致不必要的资源浪费；
同时环节4的二轮调研对于重构项目来说也非常重要，有些团队会忽略这一步，可能做了一轮调研、调整相关方案并且输出UI后就直接进入开发，不做二轮验证很容易导致新方案偏离实际用户预期，一般来说在UI、UE方案对比一轮调研方案还会有一些改动，建议在UI出来后针对核心功能或者冲突点功能进行二轮用户调研做可用性验证，看最新方案对用户理解和使用体验上是否有问题或偏差，避免线上试错的情况。
开发阶段（5环节）
环节5：技术调研与实现
在开发阶段重点强调「windows兼容」和「性能」。 很多项目在功能设计、开发、走查都基于Mac进行，容易忽略主流的Windows用户，例如不同系统滚动条会有差异，而不同显示器也会带来颜色、字号等差异，这些细节可能都会影响使用体验，这些也是很容易被忽略问题，在设计和实现时一定要考虑windows以及核心浏览器的兼容问题，在重构项目中每一个细小问题都能成为客户切回旧版的动机。
另外重构项目中性能问题需得到重视，如果新版功能久久加载不出来，不管功能再好也会劝退一大波用户，在上线前我们需要对关键接口和功能做好压测评估和监控，而在开发前更需要做好技术调研和评估，目标不是找到实现方案而是找到最优实现方案。
发布阶段（6-13环节）
对于大型重构的发布一般需要经历几个阶段：公司内部（环节6）→外部小范围测试（环节7）→外部大范围测试（环节8-11）→正式发布（环节12-13）。
内部测试
环节6：内部众测debug
第一步是内部众测，当功能可用时建议先进行内部众测以便更快发现问题，具体可先设定任务列表（可参考推广管理重构众测任务列表） ，可先进行小组内内测，然后部门内进一步扩大覆盖PM、UED、RD、QA进行更大范围的众测。
外部小范围测试
环节7：三轮用户调研（极小范围真实用户测试及走访验证）
第二步是外部小范围测试，在小流量前建议先做极小范围的真实用户测试并进行走访验证（即环节7），公司内的用户终归不是真实的用户，有些细节点我们自己体验可能会被忽略，这时候与使用最频繁的真实用户接触能更好的暴露问题，并且建议采用现场走访形式，能更快速、高效的发现问题，通过线上收集反馈可能会拉长问题暴露时间，影响项目周期。
外部大范围测试
环节8：发布前准备工作（功能引导、亮点触达、反馈渠道、运营培训）
在重构中我们往往更倾向于用乐观的态度看待用户对新事物的接受程度，认为新平台体验好大家自然就会用，从而忽略相关配套准备，实际上对于重构类项目除了要关注体验本身，用户的「习惯」会对重构带来巨大的影响，不管是手机系统还是平台使用，在持续多年的习惯面前大家会更倾向于保持原状，如果一个新功能要让用户改变旧有习惯用户往往会缺乏尝试的动力，这就要求重构项目必须做好发布前的准备工作，例如功能引导、亮点触达、反馈渠道、运营培训等等。
受长期已养成的习惯影响，相比功能新增，改版会有更大的推进阻力，对于大跨度的重构如果不给客户提前预告往往被“吓住”，比如重构中往往能听到这几类声音：
- 「愤怒」“我日常操作的功能去哪了！”——可能功能都在，但没做好功能引导；
- 「冷漠」“旧版可以满足使用需求，因为已经用的习惯了，根本不会去挖掘新功能的亮点”——没做好亮点触达，客户不知道新版有哪些好所以不会有尝试的动力；
- 「无奈」“每天这么忙，没精力去体验新版，优先完成工作”——B类产品效率优先，如果没做好用户培训，学习成本会成为新版切换的很大阻力；
当客户在找不到功能或者有一点不适应就可能放弃学习，切回旧版，不愿改变的惰性是天然的，习惯在舒适区的可掌控感，特别是对于B端，对于改版后的不熟悉也会降低使用的安全感，担心新功能有bug等等，让重构的迁移带来更大难度，不给新版体验机会，价值就很难触达。
最好在第一次接触用户时就做好相关准备，否则用户可能在强切前不会给你第二次机会，避免错过最优时间。所以在小流量前除了关注业务功能本身，还需要配合更成熟的配套方案来帮助用户学习和度过这个适应期，带着用户去发现新功能的亮点和价值，为用户创造学习的动机，而不是等着用户自己发现。再有就是配合官方宣传和运营支持提升客户的安全感，让客户知道我们很重视并且能得到及时支持。
这个阶段有几个通用产品策略：
• 新手引导：适合首次进入，将核心改动和亮点做集中触达，但实际触达效果有限，基本上80%以上用户会在前几步关闭，所以建议关闭后提供常驻入口能反复查看；
• 触发式引导：适合对希望强调的亮点/改动点/易忽略的细节功能做更详细的提示和引导，可以使用动图的方式做功能演示；
• 教学视频：对于大型重构项目除了内部培训之外，建议为用户提供线上的新版教学视频，通过视频演示会更易于学习并且能反复观看；
• 反馈渠道：在灰度阶段提供常驻的反馈入口，为客户提供顺畅的反馈渠道，及时发现问题，但是客户反馈的积极性往往不高，可以带有一定的活动属性如反馈有奖的形式鼓励大家尝试和反馈；
• 旧版页面宣导：旧版页面需要有适当的窗口让运营有更多机会去触达用户和传递新版优势，可以把吸引客户使用新版当成一个活动营销去做；
环节9：小流量开放
环节10：推广及放量阶段
环节11：完成全量新旧共存阶段
当前面工作都做足了，在小流量和放量阶段会更为顺畅，这个环节的重点依然是暴露问题，流量增多、样本扩大，需要关注线上与线下不同的声音以及监控性能的影响。其他大家更关注的可能就是放量标准，对于重构项目来说放量标准可以基于两方面——1.典型用户操作效率对比验证，2.问题优先级和解决状态，以这两点作为标准。
实际上我们很容易忽略用户习惯对于大型重构的影响，很多产品在做重构的时候可能会把返回旧版率作为重构放量的判断指标，认为新平台体验更好那返回率自然会低，对于放量初期没有太大问题，但是在中后期会发现返回率到了一定值后就变得难以下降了，因为对于各类场景的大型改版来说都会存在“念旧”的用户，而且不在少数，对于这类用户来说即使没有任何功能问题，习惯也会成为新旧切换的极大阻碍，甚至有时候功能问题只是一个借口，如果不强制切换这类用户可能会永远停留在旧版。
对于大型重构可以基于两个标准，一是典型用户操作验证能有正向的效率提升和体验评价，而不是看所有人的返回率，可以找一批不同类型的典型用户，进行现场操作调研，在了解功能的前提下看不同操作路径的效率和反馈，区分问题来自于功能本身问题还是习惯问题；第二则是问题的优先级和解决状态，当影响用户新版使用的核心问题解决后就可以开始扩量，一个问题在调研过程中超过30%用户反馈时我们认为对于重构项目这是一个核心问题。当判断典型用户体验正向且核心问题已解决时，就可以开始扩量并逐渐下线旧版。
完成全量发布
环节12：小流量下线旧版
环节13：完成全量切换
对于大型重构，扩量和下线旧版的周期往往较长需要有心理预期，需要平衡用户的适应程度和切换速度，不需要操之过急稳步推进即可。
流程框架总结
针对以上总结出重构项目的流程框架和关注点，可以作为后续重构的一个checklist进行校对，提前做好准备：
产品方案及调研阶段
环节1：产品方案设计/交互
环节2：一轮用户调研（用户场景与痛点收集）及可用性测试（产品方案纠偏）
• 保证样本丰富度和代表性做好客户分层；
• 调研及产品纠偏过程需要不断打破思维定式；
互及视觉阶段
环节3：详细UE/UI设计
• 复杂流程用可交互demo来准确传达交互效果；
• UI稿距离正式开发时间有较长间隔需再次review；
环节4：二轮用户调研（新功能场景验证）及可用性测试（交互及视觉方案纠偏）
• UI输出后对核心功能和冲突点做二轮可用性验证，避免线上试错；
开发阶段
环节5：技术调研与实现
• 关注windows和核心浏览器的兼容；
• 重视性能，关键接口和功能做好压测评估和监控；
• 做好前期技术调研和评估，找到最优实现方案；
发布阶段
环节6：内部众测debug
环节7：三轮用户调研（极小范围真实用户测试及走访验证）
• 先做极小范围的真实用户测试并进行走访验证再做小流量开放；
环节8：发布前准备工作（功能引导、亮点触达、反馈渠道、运营培训）
• 不要忽略习惯影响，做好发布前准备工作；
环节9：小流量开放
环节10：推广及放量阶段
• 放量标准可以基于两方面——1.典型用户操作效率对比验证，2.问题优先级和解决状态；
• 做好时间预期，大型重构需要平衡用户的适应程度和切换速度，周期会持续较长；
环节11：完成全量新旧共存阶段
环节12：小流量下线旧版
环节13：完成全量切换
结语
综上是关于平台大型重构的一些经验总结，希望能给到一定的经验和方法参考。最后，针对重构还有个玩笑——「用户在重构前觉得旧版哪都差，重构后会觉得旧版哪都好」，这恰恰是习惯对于用户体验带来的影响，很多时候我们在推进新老用户的时候可以感觉到明显差异，新用户可能会推进的会很快并且接受度更高，但推动老用户则会更加吃力，因为需要改变他们历史一年甚至两年的操作习惯，这就像微信19年做的大改版，对很多人来说第一想法是不习惯，以及手机系统大跨度更新第一想法是更新回去，而不是理性分析或者适应之后再判断，初期主观感受会更占上风，但是实际会发现适应之后就回不去旧版了。在有历史包袱的前提下除了交给时间外还需要我们前置付出更多努力和引导，同时关注改版冲突点，这也是重构项目对比其他项目最大的不同。
扩展阅读：
【上篇】写给刚入门的产品经理
【中篇】产品的进阶
