移動端UI一致性解決方案

時間 2021-02-14

標籤 html 前端 react web 算法 react-native 設計模式微信 app 框架欄目無線简体版

原文原文鏈接

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一致性套件由積木工具鏈、代碼組件庫、定製化設計雲協做平臺以及文檔化說明（官網）四部分組成。

積木工具鏈：經過創建包含相同設計元素的統一物料市場，PM經過Axure插件拾取物料市場中的組件產出原型稿；UI/UE經過Sketch插件落地物料市場中的設計規範，產出符合要求的設計稿。將來，但願經過高保真原型輸出，能夠給中後臺項目、非依賴體驗項目提供更好的服務體驗，賦予產品同窗直接向技術側輸出原型稿的能力。
代碼組件庫（Android、iOS、MRN）：設計稿中的組件與RD代碼倉庫中組件一一對應。
文檔化說明：官網詳細描述了代碼組件庫的集成方式、組件的使用方法，下降開發上手難度，只須要理解接口和職責便可進行業務開發。
定製化設計雲協做平臺：與美團內部的印跡團隊（雲協做平臺）合做開發，在RD的設計稿中標註了哪些是代碼組件庫中已有的元素，避免重複開發，同時關聯了官網中該組件的使用說明，是代碼組件庫與官網的紐帶。

2.2 接入指南

設計師逐步將設計語言沉澱爲設計規範（包括組件、顏色、字體、圖片等）上傳至官網供整個設計團隊查閱，同時將其量化並內置於積木Sketch插件中；開發同窗則將其代碼化，針對Android/iOS/MRN三端進行組件庫開發。
設計師使用積木Sketch插件繪製設計稿，能夠保證設計元素均從既定的設計標準中獲取，產出符合業務設計規範的設計稿，而代碼組件庫中也有對應的實現。
繪製完成的設計稿上傳至印跡雲協做平臺，交付開發同窗進行設計稿還原。
開發同窗拿到設計稿後，就能夠知道本次需求哪些組件已內置於代碼組件庫中，並能夠點擊設計稿中的連接，直接查看組件的使用說明。

2.3 方案落地

雖然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實現設計-開發流程的閉環，UI同窗因爲設計規範的標準化，可以使出稿效率、走查效率顯著提高，重複組件甚至無需走查；對於RD同窗來講，組件庫中的組件在配置正確的狀況下，因爲已經通過了歷史版本的檢驗，適配問題出現較少，無需重複進行視覺的修正；對於設計團隊來講，優秀的設計體系具備包容性且充滿生命力，好的設計模式庫可以幫助實現規範化，從而減輕界面開發的工做量，提升一致性；而對於設計師來講，創建DPL有助於減小誤用、濫用以及無效的創新。

3.2 組件搭建

在長期的版本迭代中，隨着功能的不斷增長以及UI的持續改版，新舊樣式混雜，維護極爲困難。設計師經過將頁面走查結果概括梳理，制定設計規範，從而選取複用性高的組件進行組件庫搭建。經過搭建組件庫能夠進行規範控制，避免控件的隨意組合，減小頁面之間的差別；組件庫中組件知足業務特點，同時能夠應對不斷變化的環境，具備雲端動態調整能力，能夠在規範更新時進行統一調整。

在不影響需求實現以及設計效果的前提下，只有在方案設計中儘量使用組件，提高組件設計稿中的覆蓋度，纔可能真正經過組件庫來提效。而除了在新的需求中使用組件，還須要將已有頁面內容儘可能替換成組件，才能避免頁面升級時的重複修改問題，真正提升產研效率。在進行組件庫建設時要注意如下幾點。

選擇合適粒度

組件的粒度選擇曾是困擾咱們好久的一個問題，雖然有構建設計系統的核心理論——原子設計理論爲指導，即按照「原子、分子、組織、模板、頁面」五個層面進行頁面設計。這一理論對於從零開發新應用沒有任何問題，但進行一致性改造的App，每每已經暴露出不少設計問題，已經存在數百個成熟的線上頁面，改造存在很是大的困難，必須根據具體業務選擇合適粒度。在進行組件製做前，項目同窗對外賣的近百個頁面進行了梳理，對使用到的組件進行了分類，並根據組件的使用頻率進行排序，制定了逐步替換計劃。從而避免了組件庫作的很全、花費了不少的人力，但實際不少組件都用不上，或者開發的組件過少，覆蓋場景不足等問題。

咱們將走查結果與設計師反覆交流，發現複用性較高的組件大致能夠分爲兩類：第一類「基礎控件」，也就是相似於標籤、按鈕、開關等具有基礎功能的元素，對應原子理論中的原子；第二類「業務組件」，相似於商品卡片等，是由「基礎控件」組成（好比商品卡片由「標籤控件」與「圖片控件」組成），同時「業務組件」還能相互組合，成爲更高階的「複雜組件」，相似於原子理論中的分子。「業務組件」的組合又是變幻無窮的，不一樣樣式的業務組件能夠組成相似「商家列表」、「菜品列表」等「模板」，而「模板」與「基本控件」組合在一塊兒，就成爲了「頁面」。

具有拓展性

組件必須具有必定的可配置屬性才能提高適用場景。可配置屬性體如今三個方面：組件支持局部元素展現隱藏，例如商品卡片的標題、說明、價格可根據接口數據控制展現邏輯；組件支持多種樣式，例如商品卡片的左圖右文排列、上圖下文排列；組件支持業務方配置主題，如調整高亮色、調整對齊方式等。

支持統一管理

組件管理功能對外賣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檢測作基礎。

歸檔圖片文件

當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一致性的抓手。

4.1.1 插件功能

積木Sketch插件通過一段時間的建設，目前已具有Iconfont、標準色板、組件庫、數據填充、文字模板等功能。經過Iconfont能夠從公司圖標庫中拉取設計團隊上傳的SVG圖標，並直接應用於設計稿；標準色板能夠限定設計師的顏色使用範圍，確保設計稿中的顏色均符合設計規範；組件庫中包含從外賣業務抽離的基本控件與通用組件，具備可複用和標準化的特色，並與不一樣開發語言組件庫中的代碼一一對應；數據填充庫可使設計師採用真實數據進行填充，使設計稿更貼近線上環境；文字模板中內置了字體樣式的使用規範，根據設計稿中文字的位置，點擊文字圖層便可直接應用。

4.1.2 物料市場

經過Sketch管理後臺，設計師能夠將配色規範、文字規範、話術、Iconfont、組件庫上傳至雲端並與整個設計團隊中成員共享，並可實現設計資產的版本管理。經過將Sketch Library存儲在後臺物料市場，設計師能夠與團隊成員共享組件（Symbol），Library能夠實現「一處更改，到處生效」，即便是關聯了遠程組件庫歷史的設計稿檢測到更新時，也會收到Sketch通知，確保工做中使用的是最新組件。

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同窗完成組件驗收，還能幫助開發同窗快速查閱能夠應用的全部組件，瞭解其使用方式以及進行代碼調試。

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一致性項目建設，歡迎加入咱們！