FW:移動端UI一致性解決方案
1. 背景
1.1 行業現狀與問題
很多技術同學都知道，移動端往往比較側重業務開發，這會導致人員規模不斷擴大，專案複雜度也會持續增長。而為了滿足業務的快速上線，很難去落實統一的設計規範，在開發過程中由於UI缺乏標準導致的問題不斷凸顯，具體體現在以下4個層面：
- 設計層面：由於UI缺乏標準化設計規範，在不同App及不同開發語言平臺上設計風格不統一，使用者體驗不一致；設計資源與程式碼均缺乏統一管理手段，無法實現積累沉澱，無法適應新業務的開發需求。
- 開發層面：元件程式碼實現碎片化，存在多次開發的情況，質量難以保證；各端程式碼API不統一，維護拓展成本較高，變更主題、適配Dark Mode等需求難以實現。
- 測試層面：重複走查，頻繁迴歸，每次發版均需驗證元件質量。
- 產品層面：版本迭代效率低，版本需求吞吐量低，不具備業務的快速拓展能力。
1.2 外賣移動端UI一致性情況
近來年，美團外賣業務開始由發展期走入成熟期，這更要求對細分場景的快速迭代。目前，外賣平臺承載了餐飲、商超、閃購、跑腿、藥品等多個業務品類，使用者入口則覆蓋了美團App外賣頻道、外賣App、大眾點評外賣頻道等多個獨立應用。由於前期側重需求的快速上線，設計層面缺乏標準化的規範約束，UI設計風格不統一，也存在多次開發的情況，目前的維護成本較高，在開發過程中逐漸暴露出一些問題，主要體現在以下三個層面。
指標一：移動端UI問題統計
在Ones（美團內部研發需求管理工具）中，單個版本的UI適配問題佔比超過總Bug數的11.82%，亟待優化；互動適配問題在絕大多數版本中均有出現，一定程度上反映了其發生的普遍性。
指標二：需求承接率資料統計
使用者側UI需求吞吐率達18.3%，目前使用者側UI需求吞吐率較低，亟待解決。
指標三：需求入版情況統計
目前各版本UI同學都會提出一定數量的視覺優化需求，但實際入版量僅為三分之一左右，未上線的原因均為RD開發時間不足。
從長遠角度來看，隨著固有業務滲透率的不斷飽和，未來一段時間內，美團外賣還有開拓新業務、進入新市場的需求，如國際化App、閃購App等，需要移動端能夠高效地組建新業務App。在此背景下，移動端具備快速調整適應的UI展現能力是重中之重。為了達到上述目標，需要PM/UI/RD共同維護一套設計規範，在產品上統一風格，在源頭上做到統一設計，並在程式碼中統一進行實現。
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模型之前開發流程而通過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一致性專案建設，歡迎加入我們！
本文來自部落格園，作者：Slashout，轉載請註明原文連結：https://www.cnblogs.com/SlashOut/p/15430231.html 關注公眾號：數字化轉型