移动端UI一致性解决方案

1. 背景

1.1 行业现状与问题

不少技术同窗都知道,移动端每每比较侧重业务开发,这会致使人员规模不断扩大,项目复杂度也会持续增加。而为了知足业务的快速上线,很难去落实统一的设计规范,在开发过程当中因为UI缺少标准致使的问题不断凸显,具体体如今如下4个层面:html

  • 设计层面:因为UI缺少标准化设计规范,在不一样App及不一样开发语言平台上设计风格不统一,用户体验不一致;设计资源与代码均缺少统一管理手段,没法实现积累沉淀,没法适应新业务的开发需求。
  • 开发层面:组件代码实现碎片化,存在屡次开发的状况,质量难以保证;各端代码API不统一,维护拓展成本较高,变动主题、适配Dark Mode等需求难以实现。
  • 测试层面:重复走查,频繁回归,每次发版均需验证组件质量。
  • 产品层面:版本迭代效率低,版本需求吞吐量低,不具有业务的快速拓展能力。

1.2 外卖移动端UI一致性状况

近来年,美团外卖业务开始由发展期走入成熟期,这更要求对细分场景的快速迭代。目前,外卖平台承载了餐饮、商超、闪购、跑腿、药品等多个业务品类,用户入口则覆盖了美团App外卖频道、外卖App、大众点评外卖频道等多个独立应用。因为前期侧重需求的快速上线,设计层面缺少标准化的规范约束,UI设计风格不统一,也存在屡次开发的状况,目前的维护成本较高,在开发过程当中逐渐暴露出一些问题,主要体如今如下三个层面。前端

指标一:移动端UI问题统计react

在Ones(美团内部研发需求管理工具)中,单个版本的UI适配问题占比超过总Bug数的11.82%,亟待优化;交互适配问题在绝大多数版本中均有出现,必定程度上反映了其发生的广泛性。web

指标二:需求承接率数据统计算法

用户侧UI需求吞吐率达18.3%,目前用户侧UI需求吞吐率较低,亟待解决。react-native

指标三:需求入版状况统计设计模式

目前各版本UI同窗都会提出必定数量的视觉优化需求,但实际入版量仅为三分之一左右,未上线的缘由均为RD开发时间不足。微信

从长远角度来看,随着固有业务渗透率的不断饱和,将来一段时间内,美团外卖还有开拓新业务、进入新市场的需求,如国际化App、闪购App等,须要移动端可以高效地组建新业务App。在此背景下,移动端具有快速调整适应的UI展示能力是重中之重。为了达到上述目标,须要PM/UI/RD共同维护一套设计规范,在产品上统一风格,在源头上作到统一设计,并在代码中统一进行实现。app

1.3 UI一致性项目

基于上述开发工做中的切实痛点,以及将来可预见的移动端能力需求,迫切须要一套统一的UI设计规范,以此沉淀设计风格,创建统一的UI设计标准。框架

UI一致性项目自2019年5月份被提出,是外卖UI设计团队与研发团队的共建项目,该项目是为了改善用户端体验一致性,提高多技术方案间组件的通用性和复用率,下降总体视觉改版的研发成本。经过抽离成熟的业务场景,创建可提供高质量、可扩展、可统一配置的基于Android/iOS/MRN的组件代码库,使之具有支持多业务高层次的代码复用能力,进而提升UI业务中台能力,使项目保持高度一致性。

为了帮助团队提高产研效率,外卖技术成立了袋鼠UI共建项目组,将门户建设、工具链建设以及组件建设统一管理统一规划,并将工具链的品牌肯定为“积木”,此前咱们已经写过两篇文章《积木Sketch Plugin:设计同窗的贴心搭档》、《积木Sketch插件进阶开发指南》介绍过积木相关的内容,本文主要介绍UI一致性。

UI一致性是绝大部分研发团队面临的共性问题,你们对落地设计规范,提升UI中台能力,提高产研效率具备强烈的诉求。经过UI一致性的建设,不只能够在品牌上实现体验升级,更能够全面提升产研效率,为业务的快速迭代提供有力支持和有效保障。统一的品牌符号、品牌特征,有助于加深产品在用户心目中的印象。统一的用户界面和交互形式,能帮助用户加深对产品的熟悉感和信任感。而一个好的设计语言能够在体验上为产品加分,也可以更好的创造一致性体验。

2. UI一致性总体方案

为了帮助更多的业务部门定制符合一致性原则的专属设计风格,外卖技术部在实践中不断总结经验,开发了一套通用的UI一致性解决方案。该方案经过UI一致性工具链落地项目建设,并打造一整套的闭环UI开发流程,目前已经取得了必定的成果,如下系具体方案的介绍。

2.1 方案全景

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

  1. 积木工具链:经过创建包含相同设计元素的统一物料市场,PM经过Axure插件拾取物料市场中的组件产出原型稿;UI/UE经过Sketch插件落地物料市场中的设计规范,产出符合要求的设计稿。将来,但愿经过高保真原型输出,能够给中后台项目、非依赖体验项目提供更好的服务体验,赋予产品同窗直接向技术侧输出原型稿的能力。
  2. 代码组件库(Android、iOS、MRN):设计稿中的组件与RD代码仓库中组件一一对应。
  3. 文档化说明:官网详细描述了代码组件库的集成方式、组件的使用方法,下降开发上手难度,只须要理解接口和职责便可进行业务开发。
  4. 定制化设计云协做平台:与美团内部的印迹团队(云协做平台)合做开发,在RD的设计稿中标注了哪些是代码组件库中已有的元素,避免重复开发,同时关联了官网中该组件的使用说明,是代码组件库与官网的纽带。

外卖UI一致性解决方案

2.2 接入指南

  1. 设计师逐步将设计语言沉淀为设计规范(包括组件、颜色、字体、图片等)上传至官网供整个设计团队查阅,同时将其量化并内置于积木Sketch插件中;开发同窗则将其代码化,针对Android/iOS/MRN三端进行组件库开发。
  2. 设计师使用积木Sketch插件绘制设计稿,能够保证设计元素均从既定的设计标准中获取,产出符合业务设计规范的设计稿,而代码组件库中也有对应的实现。
  3. 绘制完成的设计稿上传至印迹云协做平台,交付开发同窗进行设计稿还原。
  4. 开发同窗拿到设计稿后,就能够知道本次需求哪些组件已内置于代码组件库中,并能够点击设计稿中的连接,直接查看组件的使用说明。

UI一致性协做流程闭环

2.3 方案落地

虽然UI一致性在落地上会增长开发同窗很多的工做量,推动一致性建设也是一个艰难的工做,因为成本较高,且没法量化评估收益,不少团队最终未达到预期效果,但一旦有效运做起来后,团队将得到丰厚的回报。UI一致性的建设须要设计者对现有状态有足够的认识,对业务有充分理解,以及优秀的设计能力,同时还要不断地进行实践和优化。为了保证一致性项目的成功落地,避免“半途而废”,咱们制定了一系列的推动措施:

  1. 项目小组不能脱离平常需求开发工做。这样能够保证设计师所沉淀的设计元素始终来自于最新的业务场景,同时项目产出能够快速应用到最新的版本中得以验证。
  2. 优先选择受视觉因素影响较大、投入产出比高的模块场景进行改造,化繁为简,肯定最小验证闭环 (MVP,Minimum Viable Product),在实践中不断优化,进而跑通整个流程。
  3. 项目推动由UI同窗按版本提出需求,移动端排期并落地实施,由UI统一验收。
  4. 创建阶段性目标,并完成最近三期工做的具体规划,按期复盘完成状况,保证项目的持续推动。

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,每每已经暴露出不少设计问题,已经存在数百个成熟的线上页面,改造存在很是大的困难,必须根据具体业务选择合适粒度。在进行组件制做前,项目同窗对外卖的近百个页面进行了梳理,对使用到的组件进行了分类,并根据组件的使用频率进行排序,制定了逐步替换计划。从而避免了组件库作的很全、花费了不少的人力,但实际不少组件都用不上,或者开发的组件过少,覆盖场景不足等问题。

咱们将走查结果与设计师反复交流,发现复用性较高的组件大致能够分为两类:第一类“基础控件”,也就是相似于标签、按钮、开关等具有基础功能的元素,对应原子理论中的原子;第二类“业务组件”,相似于商品卡片等,是由“基础控件”组成(好比商品卡片由“标签控件”与“图片控件”组成),同时“业务组件”还能相互组合,成为更高阶的“复杂组件”,相似于原子理论中的分子。“业务组件”的组合又是变幻无穷的,不一样样式的业务组件能够组成相似“商家列表”、“菜品列表”等“模板”,而“模板”与“基本控件”组合在一块儿,就成为了“页面”。

外卖DPL模型创建

具有拓展性

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

组件应具备拓展性

支持统一管理

组件管理功能对外卖UI一致性起着相当重要的做用,这主要体如今两方面:首先是设计风格沉淀,目前袋鼠UI已经造成了本身的独特风格,外卖设计团队根据设计规范,对符合UI一致性外卖业务场景的组件不断进行抽象及建设,沉淀出愈来愈多的通用业务组件,这些组件须要及时扩充到Library中,供团队成员使用;另一个做用则是保持团队使用的均为最新组件。因为各类缘由,组件的设计元素(色彩、字体、圆角等属性)可能会发生变动,须要及时提醒团队成员更新组件,从而保持全部页面的一致性。

3.3 资源一致性

UI设计语言与自身业务关联性很强,美团不少业务包括外卖、酒旅、团购等都有一套本身的设计系统。“通用”意味着没法知足具备业务特点的需求,不一样业务的组件、色彩系统、动效、字体样式等千差万别,其中任意一环的缺失都会致使一致性被破坏。

设计语言并非一个抽象的概念,你们提到美团就想起美团黄,想到袋鼠,想到菜品卡片列表,想到骑着摩托车穿着印有“美团外卖”衣服的骑手,经过设计语言能够传达品牌主张和设计理念。目前,袋鼠UI已经造成了一套属于本身的独特风格,对于一致性元素处理有了一套本身的标准,对于产品的设计者而言,必须将这种风格化延续,才能使咱们整个项目具有高度的一致性,才能保持“袋鼠特点“,保证吸引力。

3.3.1 图片

创建插画库

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

因为以前产品中的插图未经系统整合,而插画师的我的风格明显,不一样的设计师在图形化的工做协同中,风格很难复现,而单纯由一名设计师去完成总体业务的插画建设工做也存在必定风险。不一样设计师以前画过的元素没法互通,形成不少元素重复设计、风格不统一,缺少系统性地创做和整理,没法最大化地提高生产效率,而且影响产品的品质感。因此插图体系在保持品牌一致性、提高工做效率以及规避风险上尤其重要。

插画规范示例

使用Iconfont

Iconfont可译为图标字体,顾名思义就是用字体文件取代图片文件来展现图标、特殊字体等元素的一种方法。简单来讲,Iconfont就是把多个图标文件打包为ttf字体文件,注册到系统中,App能够像使用字体同样使用图标。其原理能够简单理解为经过ttf字体文件维护一个Unicode码与图形的映射关系。当使用Iconfont为项目助力的时候,配置多个图标再也不须要去下载数个PNG文件,仅须要维护一套ttf字体文件便可。Iconfont不只具备矢量性、可自由变化大小的特色,并且支持任意改变颜色。从项目角度来看,因为无需针对不一样手机分辨率内置多张图片,能够必定程度减少包体积,并且方便UI同窗对图标进行统一管理,为无用icon和类似icon检测作基础。

使用iconfont替换项目中的图片

归档图片文件

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

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

一致性项目实施前项目中的类似图片

3.3.2 动效

动效是指那些那些可以为产品赋予生机的动态界面元素及视觉效果,这些交互效果一般与特定的响应行为相关,甚至包括那些与交互行为没有直接关联的临时状态。精细而恰当的动画效果能够传达状态,加强用户对于直接操纵的感知,经过视觉化的方式向用户呈现操做结果。

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

动效

3.3.3 颜色

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

定义颜色使用场景

3.3.4 字体

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

定义字体使用规范

4. 工具链建设

要想保持UI一致性,就不能打破规则。外卖UI一致性套件由积木工具链、代码组件库、定制化设计云协做平台以及官网四部分组成,经过将这四部分链接起来,造成一个闭环,把整个工做流限制在标准操做之内。

4.1 积木Sketch插件

在以前的文章中,咱们已经对积木插件进行了详细介绍,这里只做简要概述,介绍其在一致性项目中发挥的做用。从设计阶段颜色的选择、字体的规范、控件的样式,到RD开发阶段代码的统一管理、API的制定、多端的实现方式都必须遵照一套规则,经过积木Sketch插件落地设计规范,能够保证设计元素均从既定设计标准中获取,产出符合业务设计语言的设计稿,而各平台UI代码库中也有对应实现,从而使积木插件成为UI一致性的抓手。

积木Sketch Plugin平台化示意

4.1.1 插件功能

积木Sketch插件通过一段时间的建设,目前已具有Iconfont、标准色板、组件库、数据填充、文字模板等功能。经过Iconfont能够从公司图标库中拉取设计团队上传的SVG图标,并直接应用于设计稿;标准色板能够限定设计师的颜色使用范围,确保设计稿中的颜色均符合设计规范;组件库中包含从外卖业务抽离的基本控件与通用组件,具备可复用和标准化的特色,并与不一样开发语言组件库中的代码一一对应;数据填充库可使设计师采用真实数据进行填充,使设计稿更贴近线上环境;文字模板中内置了字体样式的使用规范,根据设计稿中文字的位置,点击文字图层便可直接应用。

积木Sketch Plugin功能演示

4.1.2 物料市场

经过Sketch管理后台,设计师能够将配色规范、文字规范、话术、Iconfont、组件库上传至云端并与整个设计团队中成员共享,并可实现设计资产的版本管理。经过将Sketch Library存储在后台物料市场,设计师能够与团队成员共享组件(Symbol),Library能够实现“一处更改,到处生效”,即便是关联了远程组件库历史的设计稿检测到更新时,也会收到Sketch通知,确保工做中使用的是最新组件。

积木Sketch Plugin 物料管理后台

4.2 代码模型建设

为了知足中小企业的需求,愈来愈多的开源组件库诞生,但开源表明着“通用”,没法知足业务特点的需求,因而不少企业也开始作起了本身的组件库。经过创建代码组件库,能帮助开发同窗快速搭建App页面,减小设计与开发沟通成本,统一体验规范等。

代码组件库模型

4.2.1 代码库功能

提升项目可维护性

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

实现文档化

组件接口有统一的规范,下降新人的上手难度,新成员只须要理解接口和职责便可开发组件代码,因为代码的影响范围仅限于组件内部,对项目的风险控制也很是有帮助。经过对组件统一管理,实现代码的积累沉淀与有效复用,全面提高了新业务的需求开发效率。

便于单元测试

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

实现无障碍等定制化功能

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

4.2.2 方案设计

统一配置文件

前文也提到,外卖业务入口覆盖外卖独立App、美团外卖频道以及大众点评外卖频道等,外卖组件须要在不一样的移动端上适配宿主App的UI风格及交互体验,这就须要组件库支持主题配置功能。因为主题涉及Android/iOS/MRN多端,须要一套通用的主题配置文件。通过了各端开发同窗与设计师的多轮讨论,最终肯定了包含主题颜色、文字外观、组件风格等内容的主题描述文件格式。配置文件经过下发,就能够实现全局替换主题的功能。

{
  // 主题颜色
  "rooBrandColors": {
    "rooBrandPrimary": "#FFCC33"
  },
  // 文本外观
  "rooTextAppearance": {
    "rooTextAppearanceHeadline1": {
      "fontFamily": "sans-serif-medium",    // 字体
      "textStyle": "normal",                // 风格(normal/bold/italic)
      "textSize": 44,                       // 字号
    }
  },
  // 组件风格
  "rooStyle":{
      "rooButtonStyle": {
        "textAppearance": "?attr/rooTextAppearanceButton",
        "backgroundColor": "?attr/rooBrandPrimary",
        "cornerRadius": 0,
      }
  }

搭建全平台组件库

目前,市面上耳熟能详的组件库包括阿里的Antd Desigin、Fusion Design以及美团的Roo Design等,基本都是服务于Web开发的组件库,经过这些组件库能够快速搭建一些中后台系统。为何没有知名的Native开源组件库呢?由于每一个应用的主题、风格以及交互体验都是不一样的,而这些不一样偏偏是传达品牌主张和设计理念的灵魂,所以必须结合业务,针对Android/iOS/MRN三端进行组件库开发。经过搭建全平台代码组件库,能够保证同一个UI组件在各端表现一致,进行UI升级时下降改错或遗漏的风险,除此以外,还能下降测试压力,提升需求的吞吐率。

4.2.3 示例应用

咱们针对Android/iOS/MRN三端代码开发了示例工程,经过示例工程,不只能够帮助UI同窗完成组件验收,还能帮助开发同窗快速查阅能够应用的全部组件,了解其使用方式以及进行代码调试。

组件库demo示例

4.3 官网门户建设

官网至关于项目的门面,一个好的门面才能吸引更多的用户,才能更好地对项目进行推广。官网做为设计师与开发同窗沟通的媒介,须要二者共同维护。经过官网能够帮助团队内设计师沉淀设计风格,创建统一的UI设计规范,帮助RD同窗进行组件文档管理与查阅。

4.3.1 官网功能

当前的官网主要由四部分组成,分别是设计语言、组件库、插画库以及资源下载,分别服务于UI和RD同窗。

外卖平台化官网导航栏

设计语言

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

组件库

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

插画库

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

资源下载

提供积木工具链产品下载功能。

外卖平台化官网

4.3.2 方案设计

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

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

官网支持平台化功能,不一样业务方能够建立属于本身的文档站点,一个好的文档站点对于设计组的方案推广、外部接入都大有裨益。

外卖平台化官网录入后台

4.4 工具链的闭环

当咱们信心满满的把UI一致性解决方案推广到平常开发中时,除了听到能够提高效率的褒奖外,开发同窗对项目的吐槽声也经常传入咱们的耳边,“怎么才能知道设计稿中的哪一个组件已经开发完成了?”,“查询这个组件的使用方法好麻烦,每次都要去官网检索”,“规范颜色、图标的名称是什么?怎么才能引用到?”咱们没法限制别人的选择,因此只能让这套体系变得更好用,若是不去优化整个流程,将其串联起来造成闭环,后面整个项目可能都会慢慢崩塌,因此咱们对项目进行了从新复盘,通过你们集思广益,终于找到了能将工具链体系打通的解决方案:设计稿做为衔接RD与UI的纽带,能够把官网与代码仓库打通。

咱们与美团内部的印迹团队合做开发,而后定制了一个设计云协做平台,在给RD的设计稿中标注了哪些是代码组件库中已有的元素,避免了重复开发,同时关联了官网上该组件的使用说明,RD同窗在开发过程当中遇到组件使用问题无需检索,点击便可跳转至使用文档。后期咱们还将颜色、iconfont以及插画库中图片也进行了关联,真正作到了一致性元素的全覆盖。

与印迹合做支持组件展现的云协做平台

加入咱们

UI一致性项目本来只是外卖技术团队提高UI/RD协做效率的一次尝试,如今已经做为全面提高产研效率的媒介,承载了愈来愈多的功能。围绕设计平常工做,提供高效的设计元素获取方式,让工做变得更轻松,是咱们的核心目标。如何推进设计规范落地,而且输出到各个业务系统灵活使用,是咱们持续追寻的答案。探寻研发和设计更为高效的协做模式,是咱们一直努力的方向。

如你所见,经过UI一致性建设能够帮助设计团队提高设计效率、沉淀设计语言以及减小走查负担;让RD同窗面对新项目时能够专一于业务需求,而无需把时间耗费在组件的编写上;减小QA工做量,保证控件质量无需频繁的回归测试;帮助PM提升版本迭代效率及版本需求吞吐量,提供业务的快速拓展能力。固然,咱们除了但愿制做一流的产品,也但愿可让你们在繁忙的工做中得以喘息。咱们会继续以设计语言为依托,以工具链建设为抓手持续进行UI一致性建设,不断提升移动端UI业务中台能力。

若是你也想参与咱们的UI一致性项目建设,欢迎加入咱们!

致谢

  • 感谢晓飞、彦平、杜瑶、冰冰、云鹏对项目的大力支持。
  • 感谢到家优秀设计师淼林、昱翰、冉冉、璟琦、雪美、田园。
  • 感谢用户平台组参与UI一致性建设的开发同窗王鹏、腾飞、赵炎、瀚阳等,感谢美团印迹开发团队的支持。
  • 感谢全部参与人的努力与坚持,为外卖DPL创建贡献力量!

参考文献

招聘信息

美团外卖长期招聘Android、iOS、FE高级/资深工程师和技术专家,欢迎加入外卖App你们庭。感兴趣的同窗可投递简历至:tech@meituan.com(邮件主题请注明:外卖大前端)。

想阅读更多技术文章,请关注美团技术团队(meituantech)官方微信公众号。在公众号菜单栏回复【2019年货】、【2018年货】、【2017年货】、【算法】等关键词,可查看美团技术团队历年技术文章合集。

相关文章
相关标签/搜索