关于改版，在上一篇文章🌺中我谈到了三方面的内容：为什么要改版？期望达到的目标？如何改版？下面就这三方面（﷽我考虑了下，增加了改版后的测试），结合聚会上大家的讨论，小结一下。

　　为什么要改版？

　　原计划针对该问题做一次头脑风暴，后来由于场地时间限꧅制而取消了。在聚会过程中，大家讨论的最多的，应该是这个问题。为什么要改版？解答了这个问题，也就解答了是不是要改版。这个问题我觉得归总起来可以分三个层面：

　　战略商业层 ——

　　业务流程的变更，或者说是商业目标的变化、转型；
　　为了延长产品的生命周期；（见：贯穿整个产品生命周期的用户研究一文）

　　设计层 ——

　　用户群的增长导致用户需求的变更，或者原有的设计无法满足用户需求；
　　适应新交互方式的发展，以及视觉设计上的优化；

　　技术层 ——

　　原有的系统在不断的补丁过程中，无法承受快速灵活的应变，必须改版；
　　适应新技术的发展；
　　注：我倾向于将前端代码放入技术层。

　　上面三方面六点原因，大部分情况下是交织在一起的。基本上一个是被动改版，一个是主动改版。

　　有意思的是，大家都比较认同大规模改版的周期是两🌞年。我🍬觉得这又是因公司而异了（当然还有对改版这个概念的理解），特别是和业务类型密切相关。

　　有时候，第一次产品上线后，往往实现的只有 80%，剩余的 20% 是由于各种各样的原因（成本、收益，这一点都讨论到了）而没有实现。在后续发展过程中，这 20% 的慢慢实现过程，我觉得并不能算作改版，𝓰而是有节奏的计划，和原来的产品开发周期是在一起的。

　　期望达到的目标

　　这一点谈及的比较少。但另一个问题“改什么”是与此接🎶近的话题，而“改什么”是由上面第一个问题延伸出来的。

　　我为什么把“期望达到的目标”重点提出来，原因是在于沟通。

　　我们在改版开始之前，往往会有一份改版建议书，内容是：1、改哪些东西，2、改过之后的𒁃效果，也就是期望达到的目标（注意量化）。

　　上面说到的三个层面，基本上代表了三个人群：管理人员及其他涉众🦂、产品设计部门、技术部门。商业层更关注成本和收益，产品设计部门更关注用户需求的满足，技术部门更关注产品技术层面（代码、数据库等）的可扩展性和效率。各自有各自的目标。比较完美的情况下，无论这三者谁发起了改版，就必须将期望达到的目标写清楚，并且告诉另外两者。不然容易使得沟通无效。

　　另外讨论中还提及的是改版与其他涉众之间的关系，比如改版之后，销售部门、客服部门🐟的跟进，培训计划的实施等。这里不再展开。

　　如何改版？

　　这点基本上就没有太多讨论，因为本身也与新产品设计流程比较接近。继续跑入迭代的设计流程（区别在于，是在原来基础之上），用户研究、信息架构、交互设计、视觉设计、界面制作……

　　在如何改版这个问题上，我觉得没有太多必要展开和深入了。✤设计流程这个话题，是我最不愿意谈得一个话题。没有最正确，只有最合适。

　　改版后的如何测试？

　　其实也就是改版后如何评估改版的效果。无论是大规模的改版，还是局部小地方的改版，通过一些技术手段，都能够检测和统计处前后的数据变化。比如使用效率、访问量以及相关的一些数据，有条件的在原型阶段（或者上线后）进行可用性测试（偏定量）、用户访谈（偏定性），是比较好的办♛法。

　　对照改版时的🙈“期望达到的目标”，很容易评价出这一次改版的效果。这对战略商业层、设计层、技术层都是一个很好的交代𒐪。

　　--

　　最后

　　有一句话叫做：具体问题具体分析。请勿生搬硬套。

　　再次感谢本次参加聚会的同行们，欢迎大家下次继续参与话题讨论！

　　PS. 合影等照片晚些时候加上。