产品经理进阶（一）Web APP UI 一致性设计

一、前言

做前端开发一段时间后，你会不会发现自己在持续的做着页面重复开发的工作，后面甚至干脆是Ctrl+C、Ctrl+V操作。你可能会说，那就使用组件啊！的确，通过抽取公用视图，创建子组件的方式确实可以提升代码复用度。上面是回答是基于你做程序员开发某个产品模块功能点的时候做出的。当你的问题思考提升一个层次，从前端框架设计角度思考的时候，会不会思考这样的问题：对于交互样式比较固定的业务系统，能否基于 UI 一致性、UI 设计规范进行规范的交互方式、页面及组件样式设计，简易高效的进行界面搭建？通过搭建可视化、所见即所得的 Web APP 代码自动化生成平台降低前端开发的学习成本和门槛应如何设计？如何应用以上特性最大化实现产品 UI 一致性，提升用户体验？

基于此，自己阅读了大量的文献资料，例如，美团的“乐高”、阿里的“飞冰”等，并以此探究如何最优实现前端产品开发的持续性，提升用户体验。

二、痛点

为满足业务层面的快速发展，在开发过程中由于UI缺乏标准，设计层面缺乏标准化的规范约束，UI设计风格不统一，导致的用户体验不佳问题不断凸显，很难去落实统一的设计规范，具体体现在以下 4 个层面：

• 设计层面：由于UI缺乏标准化设计规范，在不同Web App及不同开发语言平台上设计风格不统一，导致用户体验不一致；设计资源与代码均缺乏统一管理手段，无法实现知识积累沉淀，无法适应新业务的快速开发需求。

• 开发层面：组件代码碎片化，存在重复开发的情况，产出质量难以保证；由于各端代码API不统一，维护拓展成本较高，变更主题、适配Dark Mode等需求难以实现。

• 测试层面：重复走查，频繁回归，每次版本出库均需验证组件质量。

• 产品层面：版本迭代效率低，版本需求吞吐量低，不具备业务的快速拓展能力。

为改善用户端体验的一致性，提升多技术方案间组件的通用性和复用率，降低整体视觉改版带来的研发成本，需要PM/UI/RD共同维护一套设计规范，在产品上统一风格，在源头上统一设计，在代码中统一实现。

基于上述开发工作中的切实痛点，以及未来可预见的Web端能力需求，迫切需要一套统一的UI设计规范，以此沉淀设计风格，建立统一的UI设计标准。

通过抽离成熟的业务场景，建立可提供高质量、可扩展、可统一配置的基于ElementUI、iView、Ant-design-vue等主流UI样式库的组件代码库，使之具备支持多业务高层次的代码复用能力，进而提高UI业务中台能力，使项目保持高度一致性。

UI一致性是绝大部分研发团队面临的共性问题，大家对落地设计规范，提高UI中台能力，提升产研效率具有强烈的诉求。通过UI一致性的建设，不仅可以在品牌上实现体验升级，更可以全面提高产研效率，为业务的快速迭代提供有力支持和有效保障。

统一的品牌符号、品牌特征，有助于加深产品在用户心目中的印象。统一的用户界面和交互形式，能帮助用户加深对产品的熟悉感和信任感。而一个好的设计语言可以在体验上为产品加分，也能够更好的创造一致性体验。

为了帮助更多的业务模块定制符合一致性原则的专属设计风格，可在实践中不断总结经验，开发一套通用的UI一致性解决方案。通过 UI 一致性工具链落地项目建设，并打造一整套的闭环UI开发流程。

三、方案全景

美团外卖 UI 一致性套件由积木工具链、代码组件库、定制化设计云协作平台以及文档化说明（官网）四部分组成。

• 积木工具链：通过建立包含相同设计元素的统一物料市场，PM通过Axure插件拾取物料市场中的组件产出原型稿；UI/UE通过Sketch插件落地物料市场中的设计规范，产出符合要求的设计稿。未来，希望通过高保真原型输出，可以给中后台项目、非依赖体验项目提供更好的服务体验，赋予产品同学直接向技术侧输出原型稿的能力。

• 代码组件库（ElementUI、iView、Ant-design-vue）：设计稿中的组件与RD代码仓库中组件一一对应。

• 定制化设计云协作平台：与美团内部的印迹团队（云协作平台）合作开发，在 RD 的设计稿中标注了哪些是代码组件库中已有的元素，避免重复开发，同时关联了官网中该组件的使用说明，是代码组件库与官网的纽带。

• 文档化说明：官网详细描述了代码组件库的集成方式、组件的使用方法，降低开发上手难度，只需要理解接口和职责即可进行业务开发。

四、UI 一致性协作闭环流程

1. 设计师逐步将设计语言沉淀为设计规范（包括组件、颜色、字体、图片等）上传至仓库供整个设计团队查阅，同时将其量化并内置于积木Sketch插件中；开发工程师负责将其代码化，针对ElementUI、iVIew、And-design-vue等主流UI框架进行组件库开发。

2. 设计师使用积木Sketch插件绘制设计稿，可以保证设计元素均从既定的设计标准中获取，产出符合业务设计规范的设计稿，而代码组件库中也有对应的实现。

3. 绘制完成的设计稿上传至协作平台，交付开发工程师进行设计稿还原。

4. 开发工程师拿到设计稿后，就可以知道本次需求哪些组件已内置于代码组件库中，并可以点击设计稿中的链接，直接查看组件的使用说明。

虽然UI一致性落地会增加开发工程师一定的工作量，推进一致性建设也是一个艰难的工作，且由于成本较高，无法量化评估收益，但一旦有效运作起来后，团队将获得丰厚的回报。UI一致性的建设需要设计者对现有状态有足够的认识，对业务有充分理解，以及优秀的设计能力，同时还要不断地进行实践和优化。为了保证一致性项目的成功落地，避免“半途而废”，可通过制定一系列的推进措施来提高执行力与产出质量：

1. 项目小组不能脱离日常需求开发工作。这样可以保证设计师所沉淀的设计元素始终来自于最新的业务场景，同时项目产出可以快速应用到最新的版本中得以验证。

2. 优先选择受视觉因素影响较大、投入产出比高的模块场景进行改造，化繁为简，确定最小验证闭环 （MVP，Minimum Viable Product），在实践中不断优化，进而跑通整个流程。

3. 项目推进由UI同学按版本提出需求，业务端排期并落地实施，由UI统一验收。

4. 建立阶段性目标，并完成指定的具体工作规划，定期复盘完成情况，保证项目的持续推进。

细化来看，UI一致性整体方案主要分为两个部分，一个是设计体系建设，另一个则是工具链建设。设计体系建设是基础，主要是设计师沉淀设计风格，建立统一的UI设计标准，而工具链建设则是支撑，是开发人员通过开发一系列的工具将开发过程闭环，实现设计体系落地。

在长期的版本迭代中，随着功能的不断增加以及UI的持续改版，新旧样式混杂，维护极为困难。设计师通过将页面走查结果归纳梳理，制定设计规范，从而选取复用性高的组件进行组件库搭建。

通过搭建组件库可以进行规范控制，避免控件的随意组合，减少页面之间的差异；

组件库中组件既能满足业务特色，同时也可以应对不断变化的业务环境，具有云端动态调整能力，可以在规范更新时进行统一调整。

在不影响需求实现以及设计效果的前提下，只有在方案设计中尽可能使用组件，提升组件覆盖度，才可能真正通过组件库来提效。而除了在新的需求中使用组件，还需要将已有页面内容尽量替换成组件，才能避免页面升级时的重复修改问题，真正提高产研效率。在进行组件库建设时要注意以下几点。

• 选择合适粒度

组件的粒度曾是困扰设计师与开发工程师很久的一个问题，虽然有构建设计系统的核心理论——原子设计理论为指导，即按照“原子、分子、组织、模板、页面”五个层面进行页面设计。这一理论对于从零开发新应用没有任何问题，但进行一致性改造的Web App，往往会暴露出很多设计问题，对于已经存在数百个成熟的线上页面，改造存在非常大的困难，必须根据具体业务选择合适粒度。在进行组件制作前，项目开发工程师需要对已有页面进行梳理，对使用到的组件进行分类，并根据组件的使用频率进行排序，制定逐步替换计划。从而避免组件库虽然做的很全、花费了大量人力，但实际很多组件都用不上，或者开发的组件过少，覆盖场景不足等问题。

通过将走查结果与设计师反复交流，会发现复用性较高的组件大体可以分为两类：第一类“基础控件”，也就是类似于标签、按钮、开关、弹窗等具备基础功能的元素，对应原子理论中的原子；第二类“业务组件”，类似于商品卡片等，是由“基础控件”组成（比如商品卡片由“标签控件”与“图片控件”组成），同时“业务组件”还能相互组合，成为更高阶的“复杂组件”，类似于原子理论中的分子。“业务组件”的组合又是千变万化，不同样式的业务组件可以组成类似“商家列表”、“菜品列表”等“模板”，而“模板”与“基本控件”组合在一起，就成为了“页面”。

• 具备拓展性

组件必须具备一定的可配置属性才能提升适用场景覆盖度。可配置属性体现在三个方面：组件支持局部元素展示隐藏，例如商品卡片的标题、说明、价格可根据接口数据控制展示逻辑；组件支持多种样式，例如商品卡片的左图右文排列、上图下文排列；组件支持业务方配置主题，如调整高亮色、调整对齐方式等。

• 支持统一管理

组件管理功能对UI一致性起着至关重要的作用，这主要体现在两方面：首先是设计风格沉淀，通过形成自己的独特风格，设计团队根据设计规范，对符合UI一致性业务场景的组件不断进行抽象及建设，沉淀出越来越多的通用业务组件，这些组件需要及时扩充到Library中，供团队成员使用；另外一个作用则是保持团队使用的组件均为最新组件。由于各种原因，组件的设计元素（色彩、字体、圆角等属性）可能会发生变更，需要及时提醒团队成员更新组件，从而保持所有页面的一致性。

UI设计语言与自身业务关联性很强，很多业务模块都有一套自己的设计系统。“通用”通常意味着无法满足具有业务特色的需求，不同业务的组件、色彩系统、动效、字体样式等千差万别，其中任意一环的缺失都会导致 UI 一致性被破坏。

设计语言并不是一个抽象的概念，例如，大家提到美团就想起美团黄，提到阿里就想起阿里橙、提到京东就想起京东红等，通过设计语言可以传达品牌主张和设计理念。同一板块产品必须形成一套属于自己的独特风格，对于一致性元素处理有一套自己的标准，对于产品的设计者而言，必须将这种风格化延续，才能使我们整个项目具备高度的一致性，才能保持“产品特色“，保证吸引力。

以插图为例，插图作为一种视觉语言，是品牌识别度的关键核心元素，与单纯的文案信息不同，图形化在直观描述固有信息的同时，也在塑造情感背景，使用户更具沉浸感和共情性。插画在提升产品用户体验的同时完成商业目标，在表达效果及生产效率上有独特的优势，在追求效率的互联网产品中被大量地运用。

由于之前产品中的插图未经系统整合，而插画师的个人风格明显，不同的设计师在图形化的工作协同中，风格很难复现，而单纯由一名设计师去完成整体业务的插画建设工作也存在一定风险。不同设计师之前画过的元素无法互通，造成很多元素重复设计、风格不统一，缺乏系统性地创作和整理，无法最大化地提升生产效率，并且影响产品的品质感。所以插图体系在保持品牌一致性、提升工作效率以及规避风险上尤为重要。

Iconfont可译为图标字体，顾名思义就是用字体文件取代图片文件来展示图标、特殊字体等元素的一种方法，不仅具有矢量性、可自由变化大小的特点，而且支持任意改变颜色。。简单来说，Iconfont就是把多个图标文件打包为ttf字体文件，注册到系统中，Web App可以像使用字体一样使用图标。其原理可以简单理解为通过ttf字体文件维护一个Unicode码与图形的映射关系。当使用Iconfont为项目助力的时候，配置多个图标不再需要去下载数个PNG文件，仅需要维护一套ttf字体文件即可。

当Web App发展到一定阶段，必然面临着包体积会越来越大，无用图片与相似图片也会越来越多的问题。同时，由于开拓新业务而不断涌现的新场景，又不可避免地新增大量的图片。总结来看，图片文件在一致性项目中需要解决两个问题，即存量图片的处理以及新增图片的管理。

对于存量图片，必须判断其合理性，项目中存在大量相似图片，这些图片可能仅是padding不同，或者颜色尺寸存在微小差异，可以通过脚本扫描相似图片，根据图片的特征Hash判断图片的相似度，相似度高的图片根据 UI 建议，保留一张即可。那如何防止新增图片“重蹈覆辙”呢？通过建立图片管理后台，将图片按场景分类，标准图片需从组件代码库中选取，新增图片执行PR策略，需相关负责人审核，可有效防止相似图片的堆积问题。

动效是指那些能够为产品赋予生机的动态界面元素及视觉效果，这些交互效果通常与特定的响应行为相关，甚至包括那些与交互行为没有直接关联的临时状态。

精细而恰当的动画效果可以传达状态，增强用户对于直接操纵的感知，通过视觉化的方式向用户呈现操作结果。

随着业务需求的不断增加，动效的使用比重在不断增加，重要性日渐凸显，也是增强用户体验与竞品拉开差距的重要因素，因此，统一规范的使用动效尤为重要。通过动效库建设，UI层面可以承载品牌、传递情感，加深用户对Web App的印象，让用户放松、愉悦；RD 层面同一组件可在多场景直接复用，还降低了研发成本。

颜色可以起到传递品牌信息、区分信息的所属关系、标明控件的选中状态以及对内容的信息进行分层级展示等功能。重要的信息需要在页面中被突出展示。系统级色彩体系主要定义了应用的主要颜色、文字颜色、辅助颜色以及标准渐变色，颜色在一定时期内建议不再支持新增。通过将标准色板内置于插件中，限制UI绘制设计稿时的使用范围，而RD工程师仅可通过代码组件库中选取颜色，保证色值的准确性，也便于进行主题定制。

字体是体系化界面设计中最基本的构成之一。用户通过文本来理解内容和完成工作，科学的字体系统将大大提升用户的阅读体验及工作效率。设计师在字体设计过程中需要关注非常多的方面，比如字体 family、字距、行高、段落等等。如何让文字看起来更自然，是设计师团队一直探寻的答案，UI 工程师根据文字的层级关系，指定了Headline、Subtitle、Body、Button以及Caption的文字使用规范，根据设计稿中文字的位置，就可确定文字的具体样式。

在组件代码库时，应具有以下功能：

• 提高项目可维护性

由于组件库中的组件职责单一，降低了系统的耦合度，开发人员可以很容易地了解该组件提供的能力。组件可以自由替换、组合为高阶组件，在进行组件更新时仅需修改一处。每个项目成员维护一定数量的组件，让团队中每个人都能发挥所长，可以最大化团队的开发效率。

• 实现文档化

组件接口有统一的规范，降低新人的上手难度，新成员只需要理解接口和职责即可开发组件代码，由于代码的影响范围仅限于组件内部，对项目的风险控制也非常有帮助。通过对组件统一管理，实现代码的积累沉淀与有效复用，全面提升了新业务的需求开发效率。

• 便于单元测试

由于组件职责单一而清晰，对外仅暴露接口，概念上可以把组件当成一个函数，输入对应着输出，这让自动化测试变得更加简单。

• 实现无障碍等定制化功能

无障碍功能可以改善残障人士的用户体验，组件库中的组件资源高内聚，完全由自身控制加载，不与全局或其他组件产生影响。组件的加载、渲染路径清晰可控，对于组件功能定制，实现类似于无障碍等功能较为方便。

目前，市面上耳熟能详的组件库包括阿里的Antd Desigin、Fusion Design以及美团的Roo Design等，基本都是服务于Web开发的组件库，通过这些组件库可以快速搭建一些中后台系统。

为什么没有知名的Native开源组件库呢？因为每个应用的主题、风格以及交互体验都是不同的，而这些不同恰恰是传达品牌主张和设计理念的灵魂，因此必须结合业务，针对ElementUI、iView、Ant-design-vue等主流 UI 样式库进行组件库开发。通过搭建全平台代码组件库，可以保证同一个UI组件在各端表现一致，进行UI升级时降低改错或遗漏的风险，除此之外，还能降低测试压力，提高需求的吞吐率。

官网相当于项目的门面，一个好的门面才能吸引更多的用户，才能更好地对项目进行推广。官网作为设计师与开发工程师沟通的媒介，需要两者共同维护。通过官网可以帮助团队内设计师沉淀设计风格，建立统一的UI设计规范，帮助RD工程师进行组件文档管理与查阅。

4.1 手册功能

当前的官网应主要包括设计语言、组件库、插画库以及资源下载，分别服务于UI和RD工程师。

4.1.1 设计语言

UI一致性项目采取“原子理论”的构成原理，即从最小的元素开始定义，进而将这些元素按照规则进行组装，拼接成组件，最后通过这些组件拼接成最终的页面，这是一个由点到面的过程。设计语言章节主要服务于UI/UE工程师，该章节通过视觉、设计模式、动效等三个子章节使得读者能够快速了解项目的设计规范，从而快速上手。

4.1.2 组件库

组件库是设计模式中各种元素的具体实现，在这个页面描述了组件的使用方式。

4.1.3 插画库

插画库中则介绍了插画的使用场景，插画的绘制规范以及插画案例展示。

4.1.4 资源下载

提供产品下载功能。

4.2 方案设计

由于官网以纯粹的图文展示为主，且迭代频率较快，因而选择当下较为普遍的文档-网站生成系统VuePress，只需按照一定规范将书写的Markdown文档放至相应目录，前端自动解析后生成导航，并且支持多语种、图片、文件、视频等素材。这种方式极大地缩短了官网的开发周期，即便是没有前端经验的同学也能快速上手。

为了方便UI工程师对官网文档的修改，应基于文档网站生成系统搭建在线编辑平台。通过该平台，相关人员可以直接做到在线编辑、发布，节约了 UI 工程师与 RD 工程师的沟通成本以及发布成本。填充期间，使用者可以实时预览编辑的内容，修改后只需点击保存即可立即更新到网站中。

官网支持平台化功能，不同业务方可以创建属于自己的文档站点，一个好的文档站点对于设计组的方案推广、外部接入都大有裨益。

4.3 工具链的闭环

当我们信心满满的把UI一致性解决方案推广到日常开发中时，除了听到可以提升效率的褒奖外，开发同学对项目的吐槽声也常常传入我们的耳边，“怎么才能知道设计稿中的哪个组件已经开发完成了？”，“查询这个组件的使用方法好麻烦，每次都要去官网检索”，“规范颜色、图标的名称是什么？怎么才能引用到？....”

我们无法限制别人的选择，所以只能让这套体系变得更好用，如果不去优化整个流程，将其串联起来形成闭环，后面整个项目可能都会慢慢崩塌，可以考虑将设计稿作为衔接RD与UI的纽带，可以把官网与代码仓库打通。

通过定制设计云协作平台，在给RD的设计稿中标注了哪些是代码组件库中已有的元素，避免了重复开发，同时关联了官网上该组件的使用说明，RD工程师在开发过程中遇到组件使用问题无需检索，点击即可跳转至使用文档，真正做到了一致性元素的全覆盖。

五、拓展阅读

• 《移动端UI一致性解决方案》

• 《美团外卖前端可视化界面组装平台 —— 乐高》

• 《积木Sketch Plugin：设计同学的贴心搭档》

• 《积木Sketch插件进阶开发指南》