B 端产品改版需谨慎对待，获取充足的数据来明确改版目的尤为重要。说到设计改版，对于设计师而言是一个又爱又怕的工作。
爱，是因为一次改版对于设计师而言，无疑是一场全面的自我挑战，是一个展现价值且能大展身手的机会。
怕，是因为“小步快跑”是目前大多数互联网公司的发展节奏，一个项目周期给到设计师的时间往往少于预期，需承受新版本体验变化带来的用户反馈或吐槽的压力。
那如何在有限的时间内将设计改版做到符合甚至超过预期，相信对于每个设计师都是一个有压力的挑战。
本文将浅谈一下笔者在改版设计中的一些思考。
01、明确设计改版的背景和目的
对于大多数中小型公司而言，资源和时间是非常有限的，实际工作中设计师也没有那么多时间做深入的用户调研，甚至无法直接触达真正的行业用户。
而且不同于 C 端， B 端产品更具专业性，天然具有特定的专业知识壁垒，设计师的理解学习成本也更高。
这里鼓励设计师积极参与到前期的产品规划讨论中，尽早了解改版背后的目的和规划。
对于资源人手紧缺的中小型公司，获取售后或技术支持等同事的消息反馈，也是获取相对准确的用户诉求的渠道。有助于拓宽我们改版前期的相关数据信息收集，挖掘改版背后更深的痛点和目的。
而面对产品设计的改版，需要付出的成本也相对更大。若没弄明白背后目的盲目进行改版，从公司层面看，对整条产品链路都有影响，后续要再改动则会更加复杂（牵扯跨部门的改动）。
从用户层面看，首先不同于 C 端用户，B 端用户往往是被动接受软件的使用，目的也是为了高效地完成任务，而改版势必会影响用户已建立的使用习惯，影响任务的效率，重新学习极其容易给用户带来负面情绪。
若是错误的改版，那影响则更大。所以 B 端产品改版需谨慎对待，获取充足的数据来明确改版目的显得尤为重要。
02、根据目的找准设计方向
通过第一点的思考，我们可以了解到明确改版目的的必要性。而且不同的目的背后有着不同的最优解，这里抛开产品整个业务形态都改变了的情况不谈。
在 B 端产品设计改版中，设计师需要保持“克制”，如何通过较少的改变量达到需求目的是我们应该去思考的方向。
在改版需求中，会有针对 UI 视觉部分的重新设计，其目的可能是希望通过视觉层面的优化来提升产品的品牌调性，或是希望贴合主流的设计风格，又或是单纯的看腻了（具体目的需要根据实际情况分析）那对于这类目的的改版方向，我们在有限的时间内需要着重去分析视觉层面的问题，弄清问题的来源。
尽量少得去改变原有的任务流程和已有的交互习惯，把好钢用在刀刃上，毕竟实际工作中开发资源都是有限的，合理拆分也是让设计方向更为专注。
针对用户和实际场景下配色的 UI 改版
但作为 B 端的产品最为常见的还是业务层面的改版。
这类需求往往因为随着业务的增长，原有的 UI 组件和布局出现体验问题或无法承载新的功能，需要重新规划界面或者重构组件。
针对这类改版方向，在思维上设计师就不能固定在“设计理论“这一个维度上，前面提到 To B 的行业专业性问题，放到这里看就是要求我们去多接触跨领域知识，结合不同维度寻找“最优解”。
云台相机模块重设
To B 产品要确保使用的高效，界面交互的一致性很重要，所以组件的复用率很高。
我们需要系统性梳理现有内容，拆分元素、组件进行设计（原子设计），功能模块组合试验。
改版过程中不但要考虑满足当下新功能需求，同时也要去思考重新设计的内容能否为之后的业务拓展做到更强的兼容性。
组件模块化
当明确了设计改版方向后，及时和参与人员（产品、开发、测试、市场等）进行一次信息的对齐也非常必要，可以很大程度上避免后期因为信息不对等造成的扯皮。
03、改版后的设计规范完善
下面聊聊改版中设计规范建设的必要性。
对于大多数公司而言并没有像大厂一样有搭建自己设计中台的资源，更多是设计师以设计文档的形式输出的一份视觉交互“说明书”。同时我们有必要及时对规范进行维护更新，组件模块的更新也是会发生在各个小版本中。
总体而言做设计规范是一个持续完善的过程。
部分设计规范文档
1. 确保人员之间设计信息对齐
在项目中，参与改版的人员可能涉及多个设计、多个开发同事。
彼此对设计稿中元素的理解难免会存在偏差，比如同样样式的按钮大小有三种，但是在数十张设计稿中，开发同事可能并不能全方位地发现其中的细节。
而设计规范能系统的对每个元素组件模块拆解说明，对齐参与人员之间的理解偏差，确保最后的落地能更接近设计，视觉交互更统一。设计组员之间的沟通配合也能更高效。
2. 迭代新增功能保持体验的一致性
在版本迭代中存在换人的情况，规划上也可能有一个版本维持很久的情况。
而且不同于 C 端产品着力于对 UI 视觉的打磨、用户体验的提升（目的提高用户的留存），B 端产品则更加强调“稳定”，其侧重点更偏向于体验的一致性（提高任务效率）。
换人或者长时间的不接手，必然对先前的设计产生陌生感，后续的设计不一定能达到一致性的标准。这时候设计规范的就能快速复用一些组件，或根据规范元素指导补充新的组件，从而规避问题。
3. 避免冗余设计出现
工作中经常会出现某某地方要加一个弹窗，某某地方要增加一个按钮，若没有一份详细的规范指导，很有可能在多个版本，多个设计师经手之后出现了 N 种样式的组件，同类型不同样式的 icon 等，时间一久出现大量冗余的设计。
不但对后续的设计会有影响，甚至到下次改版会变得非常复杂。
04、走查及回顾
完成改版后及时进行视觉交互的走查，记录反馈，确保在第一时间能配合开发同事解决 issues 。
当改版最终上线后可以等待用户使用一段时间后收集反馈信息。
为什么要说使用一段时间后，前面也有提到，因为 B 端用户往往是被动接受软件的使用，对新的体验难免会存在一定的排斥心理，且短时间内用户可能并没有完整地使用整个产品。
所以等待 1—2 周后再对信息的反馈进行收集追踪，能更真实地发现其中的问题。同时通过数据或者售后反馈，能分析是否达到改版目的。
最后整理问题，分析其中的原因，为下一次的优化找准目标和方向。
