产品要不要做设计改版 ？来看总监的分析 ！
如何体面的设计完成产品 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% 到 100%。
这种做法带来的问题是 ：
- 新版本的推出是不可逆的 。新版本的设计无论用户是否喜欢 ，都需要接受它。因为超高的研发成本已经投入进去了。
- 你的改版用户可能并不 care 。俞军产品价值公式说的是“（新体验-旧体验）- 替换成本” ，用户如果习惯了使用旧版本的产品 ，他的替换成本就会变得很高 。如果用户把你的产品当成一个工具 ，那么他并不会希望这个顺手的工具在某一天忽然发生什么变化 。而我们改版后提供的新体验如果没有足够好。好到用户愿意重新重新调整自己的使用习惯来适应，那么这样的改版往往伴随着用户的骂声一片 。
但有意思的是 ，第二种其实是实体产品设计一直采用的方式。iPhone 14 发布之前用户并不知道它会是什么样子 ，但对新产品的发布充满期待 。但产品的新版本一旦发布之后 ，无论用户喜不喜欢灵动岛，销售团队都需要卖力宣传 。不可能像有些互联网产品的局部改版一样，因为有些用户不喜欢 ，就改回去。
第一种是快速迭代 ，小步快跑 。是数字产品研发团队的发明，不用花费大量的成本进行赌博 ，追求每改一点 ，都有明确的数据收益。
现在 ，几乎大部分团队都会采用第一种方式 ，而不是第二种方式 。原因是他们不相信自己可以创造一个远远超过旧版的全新体验 。
毕竟那真的很难。
作者 ：柴林的设计笔记
如何体面的设计完成产品 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% 到 100%。
这种做法带来的问题是 ：
- 新版本的推出是不可逆的 。新版本的设计无论用户是否喜欢 ，都需要接受它。因为超高的研发成本已经投入进去了。
- 你的改版用户可能并不 care 。俞军产品价值公式说的是“（新体验-旧体验）- 替换成本” ，用户如果习惯了使用旧版本的产品 ，他的替换成本就会变得很高 。如果用户把你的产品当成一个工具 ，那么他并不会希望这个顺手的工具在某一天忽然发生什么变化 。而我们改版后提供的新体验如果没有足够好。好到用户愿意重新重新调整自己的使用习惯来适应，那么这样的改版往往伴随着用户的骂声一片 。
但有意思的是 ，第二种其实是实体产品设计一直采用的方式。iPhone 14 发布之前用户并不知道它会是什么样子 ，但对新产品的发布充满期待 。但产品的新版本一旦发布之后 ，无论用户喜不喜欢灵动岛，销售团队都需要卖力宣传 。不可能像有些互联网产品的局部改版一样，因为有些用户不喜欢 ，就改回去。
第一种是快速迭代 ，小步快跑 。是数字产品研发团队的发明，不用花费大量的成本进行赌博 ，追求每改一点 ，都有明确的数据收益。
现在 ，几乎大部分团队都会采用第一种方式 ，而不是第二种方式 。原因是他们不相信自己可以创造一个远远超过旧版的全新体验 。
毕竟那真的很难。
作者 ：柴林的设计笔记
