设计改版，还做不做

如何体面的完成产品UI设计大改版，似乎是每个设计团队的负责人都会考虑的问题。似乎看上去，涉及到UI+交互的全栈大改版是数字产品的设计部门能够制造出来的最大声响。

的确，很多大厂的成熟产品每隔一两年就会推出一次大的改版，我们也可以直观的看到设计语言的整体迭代，并且伴随着产品亮点功能的推出。

不过，所有的产品都应该这样做吗？大厂的方式一定适合你吗？中小型公司也应该这样做吗？B端产品也要这样做吗？设计改版在什么情况下必须要做呢？UI的改版与翻新难以通过数据量化衡量，那这样的劳民伤财的项目又该如何推进呢？

最近几年我的工作更偏 B 端一些，又恰逢经济环境恶化，企业会更加关注业务本身。在这样的矛盾中，对这个话题有了一些新的思考，就以此文简单做个笔记式的总结。

 劳民伤财的，为什么要改版？

如果我们私下说，产品的UI太陈旧了，我们想改一下。这句话听上去完全没问题。但在公司里面做事情，如果你想通过会议的方式推动这个项目立项，那就需要更多的角度评估。

谈到项目立项，那就得有项目立项评审，有评审就需要写文档，写文档就需要讲清楚这个项目的背景、目标及预期收益、参与团队、执行计划以及风险管理。

设计团队如果只做UI和风格层面的改版，那就只能落脚品牌。品牌收益没法量化，品牌又是一个很大很重要的事情。但如果我们把收益归结为品牌收益，但这个项目的参与团队和成员中没有品牌部门的人，那就很奇怪。所以如果产品改版只改 UI，基本上很难推动。

除非，产品所处的阶段急需通过品牌升级的方式带来用户增长。在这样的语境下，设计团队要做这样一件事，会更容易得到理解和支持。

还有一种方法，设计团队可以联合前端团队做一些组件化的事情，这样还可以说我们在做的事情有助于后期产品研发效能的提升。但这种效能的提升也不是很好衡量，没有很好的监控指标可以立竿见影的说服决策者。

这是大部分公司设计团队的窘境。当然，也有一些公司的设计师比较幸运，老板更加看重体验价值和设计价值，这样的项目，搞定老板一个人，其他的也就好说了。

无论你所在公司的设计环境怎样，都需要回答为什么要UI改版的问题。面对这个问题，设计师容易陷入一种尴尬。在设计师看来，这个问题就好比你问一个程序员，你为什么要改这个bug？程序出了bug主动去修复，不是天经地义顺理成章的事情吗？产品的 UI 太陈旧了，我们作为设计师看不下去，想改一下，这不是我们的本能吗？

因为问“为什么要改”这个问题的人，往往不是设计师，对设计价值的理解有限。或者说他认为 UI 改版并不能带来什么实际的价值，因为无法通过数据指标在短期内衡量出来。

要回答这个问题，我来打个比方。

最近，我们写字楼的食堂把门关了，搞装修。你说他们好好的为什么要重新装修呢？如果是“好好的”，他们是不会装修的。因为装修需要停业，停业期间没有收入。不仅没有收入，还需要花钱。不仅要花钱搞物理上的装修，开业的时候还需要花钱重新宣传，让吃货们注意到你重新装修了，又重新开业了。

我们楼下的食堂过去一年以来生意不咋地，因为菜不怎么好吃，还有点贵。并且灯光昏暗，餐具陈旧，当你走进去的时候，除非你需要义不容辞地在规定时间内完成你的吃饭任务，否则大概率会转一圈，然后告诉自己：要不还是换一家吃吧。

食堂的装修，跟设计改版非常类似。设计改版可以提供给用户“焕然一新”的感觉，带来全新的体验，这种“新”的感觉和体验，也许正是企业在某个阶段所急切需要的。他们希望通过改版摆脱困局、带来新的业绩增长。

这就是为什么我在A公司推动App 的 UI 改版花了很多力气很长时间都没有成功，但在B公司碰巧跟产品团队一拍即合了，没费力气就把 UI 给改了。

因为 A 公司和 B 公司处在不同的业务阶段。

 产品改版并不是设计师的一厢情愿 

“借力”，是我开始做设计团队管理之后学到的很重要的一件事。因为设计团队在产研流程中既不是需求的源头，也不是工程的主力，而是一群想法挺多，整天嚷嚷着给别人“赋能”、扩大自己的影响力的人。

人家需要你的赋能吗？

只有对方需要的时候，你的赋能才有价值，只有对方真正需要的时候，你的项目才能双赢。否则，那得私下请吃多少顿饭、喝多少瓶酒呢？

产品的改版不是设计师的一厢情愿，产品改版往往是产品处在某个阶段需要通过改版带来一个大的突破，才需要在产品定位、产品功能、信息架构、交互流程、UI 界面等方面进行整体升级改造。实在不大可能只改 UI。设计团队如果想要大改UI，需要懂得向其他团队借力。

数字产品的大型改版，一看产品类型，二看产品阶段。

像百度网盘这样的 C 端产品，UI 改版的频率就非常高。而对于一些操作复杂的 B 端产品，改版频率就会非常低。因为 B 端产品的用户是出于办公需要使用你们的产品，好不好用都是它，自己选不了，不好用也得用。不好用的产品，用户用着用着用习惯了，他也不希望你改。你一改，他就骂你。你一改，他就吐槽你。因为B端用户很不爽。

有好几次，我们觉得某个页面在交互和 UI 上有很大的改动空间，初心是为了给用户更好的操作体验。从专业角度看，我们也确实觉得新版页面要比旧版好很多。但上线之后就会被骂。因为B端用户每天高频使用这个页面，他习惯了。你的新版可能有优点，但他不习惯，不习惯就是问题。这时候就要看我们有多坚定，能不能扛得住用户的这波负反馈。C 端产品就不一样，C 端用户在使用产品的时候是有更多探索欲的，因为是他自己想要用，而不是迫于生计，为了完成工作而去用。

其次，B端产品的大改版往往与产品的销售关系密切。如果产品进行大的改动，那么销售团队就需要提前学习掌握这些feature，好跟客户去讲清楚，让客户认识到这次改版的价值。

再看产品阶段。

还是上面那家食堂，他为什么要停业装修？是因为业绩越来越差了，新菜品、新服务等很多方法都已经试过了都不好使，所以想要通过装修改版带来新的转机。在这个发展阶段，他们不得不这么做。

同样的，数字产品在某些阶段也需要通过发布大的版本升级，提升产品的竞争力和吸引力。在产品的创新探索阶段、定位转型阶段、增长乏力需要新突破的阶段，都需要这样的改版。

百度网盘的v12.0改版就是一个很好的例子。这是百度网盘近4年来最大的一次改版。这次改版通过更简单的交互方式（左一屏）、更大胆的UI设计（大黑框），以及由大模型支持的个人助理（云小朵），“全方位地提供个人文件的智能服务，使全新的百度网盘变得更好用”。

百度网盘 App 这次改版真的变化很大，不光产品和 UI 改了，云一朵放大了，连 logo 也做了微调。为什么要做这个大的产品改版呢？因为百度网盘想要通过这次改版，塑造一个全面智能化的产品形象，从而给业务带来更多新的增长。

 开弓不该再有回头箭，
 产品改版的落地方式与风险管控 

大改版之所以难以推进，还有一个原因是执行周期长、难度大。

产品设计改版项目的落地方式，在不同的团队有不同的做法。

第一种，小范围一点点改。有的团队担心用户不能接受新版本的设计，同时也不确定新版本的设计可以确实带来多少明确的收益，所以不想一次性投入过多资源进行一次大型的改版。所以他们保守的在旧版上不断进行小的局部的迭代。

这种做法带来的问题是：

1）产品结构上的问题不太容易在这种小版本迭代中得到改进。所以有些旧的问题会一直积累。
2）用户难以感受到特别明显的改版和变化。
3）产品会越改越乱。
4）旧账不清，新账又增，很多小问题聚在一起，最后会发展成意想不到的大问题。

第二种做法是一次性投入大量的资源进行大版本的开发。
在开发完成之后，邀请一小部分用户进行内测，听取用户的意见不断完善，然后陆续放开灰度测试的范围，从 1% 到 100%。

这种做法带来的问题是：

1）新版本的推出是不可逆的。新版本的设计无论用户是否喜欢，都需要接受它。因为超高的研发成本已经投入进去了。

2）你的改版用户可能并不care。俞军产品价值公式说的是“（新体验-旧体验）- 替换成本”，用户如果习惯了使用旧版本的产品，他的替换成本就会变得很高。如果用户把你的产品当成一个工具，那么他并不会希望这个顺手的工具在某一天忽然发生什么变化。而我们改版后提供的新体验如果没有足够好。好到用户愿意重新重新调整自己的使用习惯来适应，那么这样的改版往往伴随着用户的骂声一片。

但有意思的是，第二种其实是实体产品设计一直采用的方式。iPhone 14 发布之前用户并不知道它会是什么样子，但对新产品的发布充满期待。但产品的新版本一旦发布之后，无论用户喜不喜欢灵动岛，销售团队都需要卖力宣传。不可能像有些互联网产品的局部改版一样，因为有些用户不喜欢，就改回去。

第一种是快速迭代，小步快跑。是数字产品研发团队的发明，不用花费大量的成本进行赌博，追求每改一点，都有明确的数据收益。

现在，几乎大部分团队都会采用第一种方式，而不是第二种方式。原因是他们不相信自己可以创造一个远远超过旧版的全新体验。

毕竟那真的很难。