传统企业，更需要UI一致性工程

有时候一些产品的UI设计非常精巧，在网络上好评如潮。但这些产品往往都是互联网产品，传统企业的产品恰恰相反，他们的UI被吐槽一成不变，跟不上时代。传统企业当前也存在着优化体验的诉求，但落实起来却面临着行动步调不一致的困难。本文作者围绕传统企业的UI展开了分析，与你分享。

传统企业对产品体验的忽略程度是互联网公司难以想象的，以至于粗糙得还像个demo的版本就可以如期上线了，“功能至上”并不是传统企业专属的理念，互联网公司也是功能为先，只是差别在于互联网公司是“功能”和“体验”并重，传统企业是“功能”一枝独秀。

传统企业当前也存在着优化体验的诉求，但落实起来却面临着行动步调不一致的困难。在工期估算方法不变的情况下，单纯地提高对一线开发人员的要求，是一件推动起来明显吃力的事情。UI一致性工程，或许是传统企业解决这个问题的一个方向。

一、UI一致性工程是什么

提起UI一致性工程，很多人可能不太了解，但说起组件化，相信很多人都比较熟悉。

以前我们说组件化，常常是指开发侧，而且一般是指前端，因此组件化常常是指前端代码的组件化。前端代码组件化，是把页面中重复率比较高的一些样式代码提取出来，做成一个个的代码组件，这样再遇到需要开发相同或类似的样式，就可以直接拿过来使用，而不需要再从头开始写，它在一定程度上提高了前端开发效率。

那么UI一致性工程又是什么呢？它和前端代码组件化有哪些差别呢？

前端代码组件化，通常只涉及开发侧，不涉及设计侧，而且它的主要目的是提高开发侧的效率。UI一致性工程，可以粗略地认为是对前端组件化的一个比较大的升级，它不仅仅关注开发侧，也关注产品设计侧，它的视角是整个研发过程，自然它的目的也不再是单一的提高开发侧的效率。

UI一致性工程，更为重要的命题是：如何保持UI的一致性。在多业务线、多场景、多渠道多终端、多部门多项目团队之间，想要保持UI上的一致，向公司内外部用户传达统一的视觉风格和品牌标识，对于产品经理和设计师来说是一件看起来太过于奢华的梦想。它的成本极高，以至于似乎遥不可及，单从作为视觉源头的设计师来说，对于设计规范的管控和遵从就已经显得力不从心了。在这个背景之下，UI一致性工程应运而生。

想要保持UI的一致性，UI一致性工程的重要使命便是：设计规范的统一贯彻落实。这个落实，既包括设计团队的落实，也包括开发团队的落实，甚至也可以将产品团队包括进来。

设计团队通过UI一致性工程保障设计规范能够很好地贯彻落实的手段在于：设计的组件化和设计资源的管理与限定。UI一致性工程首先的任务便是将设计规范进行设计组件化和设计资源化。通过创建设计侧组件，并在设计团队内分享复用，既提高了设计效率又避免了无效创新，以达到设计上的统一。通过设计资源化，使整个设计团队保持统一的设计风格，减少误用、滥用，以保持体验的一致。

开发团队通过UI一致性工程，不仅仅将之前沉淀的前端代码组件更加规范，还包括了设计资源的规范代码。通过对组件代码和资源代码的复用，使UI设计更加有效地落地，提升开发还原度，无需再重复走查、频繁回归，形成设计-开发流程的闭环，提升复用性与开发效率。

UI一致性工程通过全局变量和组件关联变量的提取，并在设计侧和开发侧的定义，使快速实现视觉优化、设计升级和更新的成本大大降低，使一键变更主题、适配Dark Mode等难以实现的需求变得非常easy。

设计组件和开发组件之间的便捷关联，对于后续项目上实际的设计开发工作起着举足轻重的作用。我们完成了设计的组件化和资源化，也完成了组件代码和资源代码，但若没有一种便利的在设计稿上找到对应代码片段的关联方式，就会面临功亏一篑的境地，前面实现的越多，后面查找起来就越费劲。一个能在设计稿中对设计组件和设计资源中的元素进行自动标识和代码关联的协作平台必不可少，是UI一致性工程中至关重要的一环。有了这个平台，开发人员可以在设计师输出的设计稿上直接看到哪些使用了已经创建好的组件和资源，并且点击即可直接查看到对应的组件代码和资源代码，极大地提高了开发对于组件代码和资源代码的复用效率。

二、UI一致性工程对传统企业的意义

传统企业对产品体验的重视程度不足，又缺乏产品和设计方面的专业人才，在这个大背景之下，现有的产品体验不尽人意。长期注重功能开发，为了满足业务的快速上线，很难去落实统一的设计规范，在开发过程中由于UI缺乏标准导致的问题不断凸显，主要表现在三个方面：

• 由于UI缺乏标准化设计规范或者落实设计规范不力，在不同产品/系统及不同开发语言平台上设计风格不统一，用户体验不一致，同时设计资源与代码均缺乏统一管理手段，无法实现积累沉淀，无法适应新的开发需求。
• 组件代码实现碎片化，存在多次开发的情况，质量难以保证，各端代码API不统一，维护拓展成本较高，变更主题、适配Dark Mode等需求难以实现。
• 重复走查，频繁回归，每次投产上线均需验证开发质量与还原度效果，修改后还需要再次确认，由于效率比较低，造成为了提升产品体验而做的工作性价比比较低。

产品经理进入传统企业后，首先承担起的便是产品体验优化的重任，但一段时间以后就会逐渐发现，肩上的担子分解下来的层层任务只有自己那部分可控的任务能顺利如期地完成，然后就会遇到难以推动的困境。提出的产品体验优化相关的需求总是被功能性的项目需求一拖再拖。即便是领导亲自下发了体验优化的任务，也难以抵抗现有的KPI评价体系和业务与开发团队的惯性思维和习惯性动作。

结合传统企业业务经营场景与实际需要，缺乏有效提升产品体验的体系化工具，可能是导致产品体验问题一拖再拖、一直得不到解决的关键所在。UI一致性工程，或许是产品经理可以依托的一杆旗帜。

产品经理借助UI一致性工程，不仅可以解决自己所负责产品/系统的产品体验问题，还可以将其平台化，供其他项目团队使用，这对于有比较多中后台系统的传统企业来说，更是一个整体性的UI解决方案。传统企业直接面向客户的科技产品，尚且可以通过人力的单独密集配置、产品体验的重视程度、敏感度与开发还原度的提升等方式使之达到一个尚且不错的水平，但对于中后台产品/系统的体验问题基本上没有办法来集中解决、整体提升，更多依靠的是每个团队自己，除非依靠UI一致性这样的整体性工程。

抛开所处的企业环境与人力资源境况之外，单说UI设计与设计规范落实，也该提升一下效率了。一个页面一个页面地画、一个元素一个元素地设计，虽然每个设计师也会有一套自己的设计库，但这远远不足，依然存在很多环节可以改进和提升的地方。设计专业基础的原子、分子、组织、模板、页面的原子理论，也该将设计规范按照这个理论进行组件化和资源化了。说起这一点，不得不感叹，开发侧在分享、复用、协作这些方面比产品和设计侧要走得靠前一点，在时间上、在广度和深度上，都是如此。或许，这是因为产品与设计侧一直强调的是创意、创新，开发侧更务实，强调的是效率、工期吧。

说了这么多，其实UI一致性工程归根到底解决的是两个方面的问题，一个是产品体验的一致性，一个是研发效率的提升。我们一定要在UI一致性纷繁复杂的大工程里始终清醒地认识到这一点，始终紧紧抓住这两个关键作用，不能自己迷失了方向。

这里的研发效率既包括开发侧的效率，也包括设计侧的效率，也可以包括产品侧的一点效率。这里的效率，更多的是体现在UI设计师和前端开发的工作效率，以及两者需要相互配合完成的协作效率上，如开发还原度与UI走查。由于产品经理最主要的工作瓶颈不在于产品原型的产出，所以说是能提升一点效率。除此之外，产品体验的一致性和研发效率的提升也存在一点内部逻辑关系，这个逻辑关系便是：UI一致性工程首先要达成研发效率的提升，才能进一步促使完成产品体验的一致性。这一点，在传统企业里是非常重要的，任何脱离开发只谈产品及体验的改善都不具有足够的吸引力。

UI一致性工程的建设，可以帮助设计团队提升设计效率、沉淀设计语言以及减少走查负担；让开发同学面对新项目时可以专注于业务需求，而无需把时间耗费在组件的编写上；减少测试同学工作量，保证控件质量无需频繁的回归测试；帮助业务同学和产品经理提高版本迭代效率及版本需求吞吐量，提升业务的快速拓展能力。

虽然UI一致性工程在落地上会增加开发同学不少的工作量，推进一致性建设也是一个艰难的工作，由于成本较高，且无法量化评估收益，很多团队最终未达到预期效果，但一旦有效运作起来后，团队将获得丰厚的回报。

三、UI一致性工程之外

有了UI一致性工程以后，是不是单纯依靠它就能解决所有问题了呢？当然不是。

组件化与资源化虽是提效和统一体验的好方式，但在设计过程中我们也不能过度强化组件和资源的使用，丧失了设计创新的可能性，而是通过对产品价值的深入认知、对设计方案的全局审视来进行决策，以实现两者间的平衡和价值最大化。