在产品的迭代升级过程中，改版设计是常常会遇到的问题。文章对结合自己的工作经验，梳理分析了产品改版设计的步骤，并对过程中需要注意的问题进行了分析总结，供大家参考学习。

当产品要进行大改版时，也就意味着产品经理要没日没夜的赶进度，完成新产品的设计工作，在高压的同时也是一个不可多得的机会，把握住此机会往往能成为自己谈资的资本，那么如何进行大版本迭代？又该如何高效完成产品的设计工作？

我参考前墨迹天气产品总监的分享，整理了以下7个步骤：

1. 前期准备
2. 建立工作坊
3. kickoff会议
4. 验证
5. 快速实现和发布
6. 快速验证的敏捷
7. A/B测试

01 前期准备

1. 概论：
2. 团队内部明确大改版的目的
3. 产品现状：
4. 用户画像
5. 用户细分
6. 用户的行为偏好

大改版的过程中，内部一定要确定好一个很明确的目标。是只改交互和页面，还是整个App架构都变化了，还有一种情况是只改单个模块，如果这个模块是旧模块，我们去改这个旧模块的时候，一定会说这个旧模块有一定的问题，这个时候我们需要把它的问题点列出来。

如果说我要去做一个新的尝试，可能是基于我现在APP的架构上多了一块业务而做的这个模块，总之不同的业务，不同产品的时期，或者是说公司不同的情况导致你的目的有不同的偏重，我们在改版的过程中一定要清晰明了的知道我们的目的是什么，做好产品的目标管理。

另外就是要了解自己产品的现状，现在大家都在说大数据、用户画像，这个基于产品前期来讲的话，做需求场景的时候已经定义的有几类用户，A类和 B类，A类肯定有一个需求，但A类用户是什么样子的，这个就是当你之前做的时候和你现在在改版这一时刻用户画像有没有改变，你要去判定一下；

或者说我的用户画像已经改变了，我是不是要把我之前设计的场景重新梳理一下，就是怎么去使用，现在说可能有的团队已经有了一个用户画像和用户标签，有团队可能没有，当然也包括用户群的细分，用户偏好的细分。

在这里为大家提供一些办法，想网上禅大师，酷传科技，七麦数据等互联网产品分析网站都会积累大量的数据和做相关调研，如果公司没有这些用户数据的话可以考虑借助这种第三方平台提供的服务，相互合作，完成前期的准备。

在整个设计过程中，我们要提前把用户的行为梳理起来，就是用户吸引过来的时候他的核心路径是哪些，在改版之前会梳理一下核心路径有几条，用户进来的时候打开首页去哪里，去哪里之后跳出页是哪里，然后我变动这个功能模块，变动这个架构的时候影不影响核心路径，假如影响核心路径怎么去改变。

最后一点是你需要找出你的核心流程、主流程。把一两个核心功能梳理出来，判定上线之后的数据情况是什么样子的，或者是把这个做为一个快速迭代时候的判断指标，有一个统计是用户80%集中在核心流程，另外的功能弱，也就是说你发现用那些功能的就五六个人，所以改版在资源调度上面很重要，或者是方向很重要，包括我们在日常进行迭代的时候，怎么样把注意力放在重点功能上，这就是一个思路和参考。

02 建立工作坊

将团队分成2个team，每个team完成各自的4个任务（角色讨论20min，使命必达15min，设计原则20min，品牌特性25min），然后做汇报审核，共同讨论。

为什么要建立工作坊呢？是因为我们要跟所有团队的人去讨论一下大改版或者实施方向，我们怎么去做这个工作坊？我们把我们整个团队分成2部分，这时候你选人的时候非常重要，我们做改变的时候，有可能产品经理不是离用户最近的人，这个时候就要把要把运营市场的专员叫过来，还是就是我们在改版的时候有哪些坑。

你找的team1和team2一定要是来自不同部门，有不同诉求的，这样综合改版的时候不是我的产品要创造哪些东西，而是说击中了大家的思维。我们之前说产品经理要学会借力，这也是借力的方法。有了工作坊接下来就是任务了

第一个任务是角色的讨论，我们做了那么多前期的准备定义了大概的方向之后，接下来就是我们要把我们的用户再去细分，也就是用户是什么样的，广义上70后，80后或者90后，按照年龄、性别，他们的经济状况，手机使用情况，行为状况不一样的，所以我们要对用户决策进行建模，明确现阶段我们做什么。

另外一个就是项目的使命是什么，我们要不停地提炼项目的使命，最终确定一个清晰简练的项目使命。比如第一个使命是16个字，后面就慢慢减少，每次减少一半，直到不能减少为止，此时就有了一个清晰的目标。

第三个设计的原则，这个设计包括 UI和交互，可能还有更多的人参与，我们这个设计原则是什么？希望实现什么？为什么这样设置呢？因为平常设计在产品上遇到了一些问题，可能在迭代的过程中由于时间的原因他不敢去说，但在这个过程中他敢表达自己的想法。

另外就是品牌特性，这块是说明我们做完东西怎么去做宣传，然后我这个功能点上能不能差异化，一个是宣传的差异化，另外是产品上已有的差异化，把这个提炼出来，就是品牌特性，其实品牌特性有很多很多方面需要考虑，品牌不光和我们产品关联，还是和我们应用推广有关联。

这块能挖出来的东西特别多，在改版的时候不要局限在改这个模块，或者改这个设计，而是站在综合的角度上考虑我改版的目的。

03 Kickoff会议

Kickoff会议上可以把项目的周期确定，用什么启动，然后第一次的UI，包括产品原型，然后设计开发是什么时候，另外是我们需要多久，或者项目跟进的时候大家怎么调动这个资源，一定要有一个明确的项目周期。

另外改完之后肯定是要做外部评审，因为改完之后可能是设计风格要去审，也有可能这次改的主要功能要做一个评审，还有可能这次关心的用户不一样，有的公司可能是团队内测的，部门内测还要给老板汇报，要把这个时间周期安排好，因为每一次决策，不同人在不同角度决策的时候，会对项目周期和产品结果的促成很大影响，我们需要把这些因素都考虑进去。

KickOff会议结束之后，重点的是深度的探索和输出，产品上建议大家不要让思路过于太散，就在关键一两个点上去做。有可能我们改一个全新的，数据猛跌，新用户留不住，所以建议内容一定要拆解，要找一两个主线，因为现在的产品经受不住很大的折腾。还有就是业务重点建议把高保真原型输出，用研这块可以通过高保真的原型去尝试。

04 验证

我们有了大概高保真的时候就和用户做验证，相当于我们做可行性测试。沟通需求，测试计划，用户招募，撰写脚本，用研准备，预测试，测试执行，撰写小结，撰写报告，宣讲报告这是内部大概的流程和环节，用户筛选的时候条件一定要足，就是第一次做的时候老衲倒不建议做新用户，可以做老用户，核心用户，另外在主路径上流程比较高的用户是哪些可以去除。

一般大改版会进行三轮的，第一轮有一些核心业务员，中期会在模拟机上跑，后期产品上线，每次都要去做一些，可能第一次比较难，大家要找到合适的方法。

05 快速实现和发布

快速实现的阶段我们会对模块功能进行拆解，如果发现新版本有问题的时候，这时候可以把功能放在老版本做迭代，我们有可能正在做5.0，做6.0新东西的时候，6.0是个大模块，这时候又要维护5.0，又要维护6.0，我把这个拆解往 5.0上迭代，看部分的用户对这个功能反馈是什么样的，如果这个是好就放在6.0上通过。

我们会引入相关的机制，这块会降低你改版的风险度。另外就是深度筛选你的目标渠道，其实360的用户画像和豌豆荚的用户画像，包括百度、商场、商店完全是不一样的，特别是oppo、vivo和小米，用户画像、用户群完全不一样，包括消费水平都是不一样的，我们在发布时需要做具体考虑。

还有一块就是在全量发布的时候一定要有一个标准，起码说产品质量，包括提供的服务要一定没什么问题。全量发布的标准内部一定要定义好，就是内部的策略，线上的渠道，然后到底发布的时候推给老用户还是给新用户用，这块一定要做一个相关的验证。

06 快速验证的敏捷

另外新版本上线发布的时候要建立一个快捷敏捷的机制，这个敏捷的机制该是做一些假设，做假设的时候可以快速修改，修改可以快速的看一些机制。

因为在上线之前可能经历了无数次个别功能模块的调整，这就导致我们商业化变低了要调整，用户的喜好不一样了，所以上线以后可能发现一部分用户反馈特别差，要快速改这些，这也是通过我们的产品去验证自己的一个方法，这是在大改版中一定是重中之重的思想。

07 A/BTest

A/BTest，随着我们体量的增加我们就把A/BTest使用上了，国内用A/BTest是头条一直在用。A/BTest最有效的是在你团队内争议的时候对于图标的测试，你可能感觉这个图标不好看，用了这个机制之后可以把它的这个图标打成三份，虽然明显的知道虽然它非常丑，但是分享率特别高，这是一种设计上A/BTest非常有用的地方。

还有就是产品上做转化率，就是我们从首页入口到滴滴订单的时候，我们在设计上可能有分歧的地方，那就可以用两三套A/B Test 的机制快速展示就可以快速的得到。

最后，我总结一下大改版背后的一些注意事项：

1. Timing:团队情况+产品属性
2. 时间周期，资源度
3. 迭代模式，小步快跑
4. A/B Test
5. 主线不要太多
6. 分配迭代
7. 发布前的预热准备
8. 危机意识的防范

本文由 @Te Fuir 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议