移动端UI一致性解决方案( 三 ) _UI

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

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

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

2.4 一致性成果
经过一段时间的UI一致性建设，在资源一致性方面，外卖App团队已经完成了近百个Iconfont的替换工作，有效减小了安装包的体积。在组件代码库建设方面，完成组件替换三十多处，中等业务需求平均节约3pd人力；在工具链方面，根据UI/UE提供的数据，对于强依赖设计资源的需求，在使用积木Sketch插件后，提效能够达到30%以上，对于UI资源依赖不强的流程需求，平均提效可以达到50%以上。
3. 设计体系建设细化来看， UI一致性整体方案主要分为两个部分，一个是设计体系建设，另一个则是工具链建设。设计体系建设是基础，主要是设计师沉淀设计风格，建立统一的UI设计标准的工作，而工具链建设则是支撑，是开发人员通过开发一系列的工具将开发过程闭环，实现设计体系落地。
3.1 外卖DPL
DPL（Design Pattern Library）是一份面向UED设计人员的文档化说明，描述了设计模式库的规范以及应用场景等，外卖DPL主要包括组件搭建规范以及资源一致性两部分。DPL的背面是技术实现，一般体现在Android/iOS/RN代码框架中，比如阿里的FusionDesign库、腾讯的QMUI库等，这些封装好的代码组件面向程序开发人员。在未建立DPL模型之前，开发同学拿到设计稿进行视觉还原后，需要修改多次，才能最终通过设计师的验证，极大影响了开发效率，还降低了需求吞吐率。

文章插图
未建立外卖DPL模型之前开发流程
而通过DPL实现设计-开发流程的闭环， UI同学由于设计规范的标准化，可使出稿效率、走查效率显著提升，重复组件甚至无需走查；对于RD同学来说，组件库中的组件在配置正确的情况下，由于已经经过了历史版本的检验，适配问题出现较少，无需重复进行视觉的修正；对于设计团队来说，优秀的设计体系具有包容性且充满生命力，好的设计模式库能够帮助实现规范化，从而减轻界面开发的工作量，提高一致性；而对于设计师来说，建立DPL有助于减少误用、滥用以及无效的创新。
3.2 组件搭建
在长期的版本迭代中，随着功能的不断增加以及UI的持续改版，新旧样式混杂，维护极为困难。设计师通过将页面走查结果归纳梳理，制定设计规范，从而选取复用性高的组件进行组件库搭建。通过搭建组件库可以进行规范控制，避免控件的随意组合，减少页面之间的差异；组件库中组件满足业务特色，同时可以应对不断变化的环境，具有云端动态调整能力，可以在规范更新时进行统一调整。
在不影响需求实现以及设计效果的前提下，只有在方案设计中尽可能使用组件，提升组件设计稿中的覆盖度，才可能真正通过组件库来提效。而除了在新的需求中使用组件，还需要将已有页面内容尽量替换成组件，才能避免页面升级时的重复修改问题，真正提高产研效率。在进行组件库建设时要注意以下几点。
选择合适粒度
组件的粒度选择曾是困扰我们很久的一个问题，虽然有构建设计系统的核心理论——原子设计理论为指导，即按照“原子、分子、组织、模板、页面”五个层面进行页面设计。这一理论对于从零开发新应用没有任何问题，但进行一致性改造的App ，往往已经暴露出很多设计问题，已经存在数百个成熟的线上页面，改造存在非常大的困难，必须根据具体业务选择合适粒度。在进行组件制作前，项目同学对外卖的近百个页面进行了梳理，对使用到的组件进行了分类，并根据组件的使用频率进行排序，制定了逐步替换计划。从而避免了组件库做的很全、花费了很多的人力，但实际很多组件都用不上，或者开发的组件过少，覆盖场景不足等问题。