作者：ZYUN（20190401）
預計閱讀時長：14m 42s（5080 字；10 圖）

前言

本文旨在記錄和分享我在有車以后嘗試為我們的后臺產(chǎn)品創(chuàng)建一個設(shè)計系統(tǒng)的探索過程，以及其中的不足與反思误算。同時般码，也是借此機會對這兩年的后臺產(chǎn)品設(shè)計工作進行回顧和總結(jié)束倍。

全文內(nèi)容共分為三篇被丧，第一篇（本篇）主要介紹此設(shè)計系統(tǒng)的創(chuàng)建背景盟戏、必要性和價值绪妹，第二篇主要記錄此設(shè)計系統(tǒng)的創(chuàng)建過程、具體內(nèi)容和實際應用柿究，第三篇是相關(guān)設(shè)計工具邮旷、技巧，以及相關(guān)文章蝇摸、書籍等資源的推薦婶肩。
全文內(nèi)容結(jié)構(gòu)如下圖所示：

此設(shè)計系統(tǒng)的記錄文檔已存放在語雀和 Gitbook 上，點擊 Singularity Design System（語雀） 或 Singularity Design System（Gitbook） 即可查看貌夕、搜索所需內(nèi)容律歼，并下載源文件。
除此之外啡专，也可以直接前往騰訊微云?下載源文件险毁，以使用或參考。

本文及此設(shè)計系統(tǒng)的內(nèi)容都仍存在許多不足之處们童，且僅代表我個人在面對特定產(chǎn)品畔况、項目和團隊時所用的工作思路和方法，并非放之四海而皆準慧库，但如果能為你帶來一點點的參考價值跷跪，那就太好了～如果有什么疑問或建議，可以在評論區(qū)告訴我齐板，一起討論吵瞻、學習啊～提前感謝你的閱讀～

背景

產(chǎn)品特點

由 2017 年三月開始至今，我共參與了有車以后內(nèi)部近 10 個后臺產(chǎn)品的設(shè)計甘磨。其中听皿，少數(shù)幾個產(chǎn)品是從零開始進行設(shè)計，多個項目則是對原有產(chǎn)品進行改版后繼續(xù)更新迭代宽档。

這些產(chǎn)品都是基于網(wǎng)頁的數(shù)據(jù)密集型產(chǎn)品尉姨，集成了很多的功能和信息，本身的業(yè)務(wù)吗冤、交互邏輯都比較復雜又厉，并且長期在沒有設(shè)計標準約束和指導的情況下進行迭代九府。久而久之，視覺表現(xiàn)覆致、交互體驗上的問題都開始突顯出來并愈演愈烈侄旬，流程變得復雜，信息架構(gòu)變得混亂煌妈，系統(tǒng)越來越龐大臃腫儡羔。加之一些歷史遺留問題，整體使用體驗較差璧诵，也不利于后續(xù)的迭代和維護汰蜘，因此需要進行改版。

此外之宿，由于前期缺乏統(tǒng)一有效的設(shè)計規(guī)范和組件庫族操，這些產(chǎn)品在視覺風格、交互體驗上存在較大的差異比被。為了保證同個產(chǎn)品的一致性色难，延續(xù)產(chǎn)品原來的風格，設(shè)計師在設(shè)計時需要牢記和區(qū)分不同產(chǎn)品對應的設(shè)計模式等缀，如顏色枷莉，字體，間距尺迂、控件樣式等等笤妙，前端開發(fā)工程師則需要根據(jù)不同的設(shè)計稿標注去進行開發(fā)，這無疑增加了設(shè)計枪狂、開發(fā)和團隊協(xié)作的成本危喉，產(chǎn)生了大量冗余的工作。再者州疾，由于難免會有疏漏辜限，產(chǎn)品最終上線時的設(shè)計還原度也常常得不到保證。

從產(chǎn)品類型來看严蓖，多個產(chǎn)品都是 CMS 產(chǎn)品薄嫡，我們通過這些后臺系統(tǒng)對不同的前端產(chǎn)品進行管理，同時颗胡，也有像「有車號平臺」毫深、「經(jīng)銷商平臺」這樣的平臺級工具產(chǎn)品。
另外毒姨，我們還有從這些產(chǎn)品中衍生出來的定制化產(chǎn)品哑蔫，客戶購買我們的產(chǎn)品以對特定的業(yè)務(wù)進行運營、管理。因此闸迷，我們需要根據(jù)客戶提供的品牌 VI嵌纲，調(diào)整、更換產(chǎn)品的 logo腥沽、界面配色逮走、UI 元素風格等等。在沒有建立統(tǒng)一組件庫的情況下今阳，這樣的定制化需求常常給我們帶來大量的設(shè)計修改和開發(fā)工作师溅。

開發(fā)流程特點 / 人員架構(gòu)特點

產(chǎn)品項目多、更新迭代快盾舌、人力資源不足墓臭，這都要求設(shè)計和開發(fā)必須具備高效輸出的能力。尤其是矿筝，我們的研發(fā)團隊中沒有「交互設(shè)計師」一職起便，我是唯一參與后臺產(chǎn)品設(shè)計的設(shè)計師棚贾，需同時兼顧交互和視覺設(shè)計窖维。因此，我常常會在視覺效果圖上進行交互細節(jié)的標注妙痹，然后輸出給前端開發(fā)工程師铸史，以節(jié)省時間。但有時候怯伊，產(chǎn)品經(jīng)理也會直接將產(chǎn)品原型圖交付給前端開發(fā)工程師進行開發(fā)琳轿，最終導致控件使用不規(guī)范、遺漏交互細節(jié)等問題耿芹。

此外崭篡，我們的后臺產(chǎn)品基本都是業(yè)務(wù)驅(qū)動的，常有為了解決某個問題而提出的緊急需求吧秕。這種情況下琉闪，通常會安排新的開發(fā)人員臨時接手項目。但由于沒有統(tǒng)一的設(shè)計規(guī)范和組件庫砸彬，新的開發(fā)人員在接手項目后颠毙，無法快速了解、熟悉項目砂碉，和產(chǎn)品經(jīng)理蛀蜜、設(shè)計人員、其他開發(fā)人員之間的溝通成本也因此增大增蹭，開發(fā)效率滴某、整體工作效率都會因此下降。
而在平時的開發(fā)工作中，缺少統(tǒng)一的組件庫也常常導致開發(fā)工程師重復開發(fā)霎奢，協(xié)作效率低下偏瓤。

使用人群特點

由于這些產(chǎn)品居多是內(nèi)部 CMS 產(chǎn)品，所以我們的主要用戶就是我們公司內(nèi)部的同事椰憋，例如內(nèi)容編輯厅克、美術(shù)編輯、運營人員等等橙依，這些同事常常需要配合使用多個后臺系統(tǒng)去完成日常工作任務(wù)证舟。基于這一點窗骑，這些產(chǎn)品之間的體驗一致性就顯得尤為重要女责。譬如，如果不同產(chǎn)品中類似的操作卻有著完全不同的反饋创译，就很容易讓人一頭霧水抵知，甚至操作出錯。
讓我們的同事去適應不同視覺風格和交互方式的界面將會使其工作質(zhì)效下降软族。

痛點

通過以上的背景分析刷喜，我梳理得出我們在后臺產(chǎn)品設(shè)計中存在的痛點如下。

設(shè)計師

花費很多精力去記住和區(qū)分不同產(chǎn)品對應的設(shè)計模式立砸，無法有效復用設(shè)計資源掖疮，無法高效輸出標準化的交互稿和視覺稿。

開發(fā)工程師

存在大量重復開發(fā)的工作颗祝，接手新項目時無法快速了解浊闪、熟悉項目，設(shè)計還原度不可控螺戳。

團隊

溝通成本大搁宾，協(xié)作效率低下，無法快速響應客戶的定制化需求倔幼，并且這些問題會隨著團隊規(guī)模的擴大而愈發(fā)突出盖腿。

產(chǎn)品

產(chǎn)品設(shè)計缺乏統(tǒng)一的設(shè)計標準指導，同一產(chǎn)品內(nèi)凤藏、多個產(chǎn)品之間的體驗一致性受影響奸忽，并且這些問題會隨著項目規(guī)模的擴大、功能復雜度的提升愈演愈烈揖庄，最終難以解決栗菜。

用戶

不得不去適應不同內(nèi)部產(chǎn)品的不同視覺和交互體驗，學習成本大蹄梢，操作效率低疙筹，導致工作質(zhì)效下降富俄。

解決方案

明確目標

基于以上背景，我開始思考如何制定一個具體的而咆、切實可行的計劃霍比，以解決這些痛點。

作為設(shè)計師暴备，我們很容易就陷入以設(shè)計為中心的解決方案中悠瞬，譬如，立馬打開 Sketch涯捻，創(chuàng)建一份完美的設(shè)計規(guī)范文檔浅妆。
然而，根據(jù)以往的經(jīng)驗障癌，我們的 Style Guide 雖然對配色凌外、字體、圖標等元素進行了風格定義涛浙，但最終也只能躺在我們的電腦硬盤里康辑，無助于維護設(shè)計模式的一致性，無法為團隊帶來實用價值轿亮。 其原因在于：
1）查詢極不方便疮薇，無法直接調(diào)用相關(guān)設(shè)計元素，設(shè)計師最終都是憑記憶去使用哀托，容易出錯惦辛；
2）調(diào)整劳秋、修改規(guī)范后仓手，常常無法及時更新文檔并同步給其他相關(guān)人員；
3）文檔中未詳細記錄相關(guān)設(shè)計元素的設(shè)計原則玻淑、使用方法嗽冒；
4）僅由設(shè)計師創(chuàng)作完成，實際上只是一份視覺風格指南补履，內(nèi)容缺乏團隊層面的普適性添坊；使用的仍是設(shè)計師的語言，無法在設(shè)計師箫锤、開發(fā)人員和產(chǎn)品經(jīng)理之間建立起一套共同的語言贬蛙。

有鑒于此，我們需要站在產(chǎn)品谚攒、團隊的整體層面阳准，用系統(tǒng)化的思維去探索新的解決方案。
恰逢此時馏臭，通過對 Ant Design 等一系列在線設(shè)計體系的學習野蝇，我開始了解到一種基于原子化設(shè)計理念的解決思路：基于標準化的設(shè)計語言，提供配套的代碼組件庫和設(shè)計文檔，以模塊化绕沈、體系化的方式推動設(shè)計和開發(fā)流程锐想，在解決實際需求的同時也具備良好的可維護性。

但是乍狐，我們的目標不是創(chuàng)建出和這些設(shè)計體系一樣完善的設(shè)計系統(tǒng)赠摇，實際上我們也沒有能力和資源實現(xiàn)這一點。我們的目標浅蚪，是學習和借鑒“標準化蝉稳、模塊化、體系化”的思路掘鄙，結(jié)合我們的產(chǎn)品耘戚、團隊特性，創(chuàng)建一個簡單適用的設(shè)計系統(tǒng)操漠，幫助產(chǎn)品經(jīng)理收津、設(shè)計師、開發(fā)人員規(guī)范工作流程浊伙，使產(chǎn)出撞秋、協(xié)作更加標準化，提高產(chǎn)品設(shè)計和開發(fā)效率嚣鄙，解放出更多的精力用于設(shè)計思考吻贿，并最終提升產(chǎn)品在視覺表現(xiàn)、交互等層面的一致性哑子，進而提升產(chǎn)品的用戶體驗舅列。
另外，在解決痛點的同時卧蜓，也希望隨著設(shè)計系統(tǒng)的構(gòu)建和實踐帐要，設(shè)計團隊在公司內(nèi)的專業(yè)度與影響力能得到提升。

可行性

1. 基于真實產(chǎn)品構(gòu)建

在開始構(gòu)建設(shè)計系統(tǒng)之前弥奸，我們已經(jīng)有了近十個后臺產(chǎn)品的設(shè)計經(jīng)驗榨惠。我們可以從這些產(chǎn)品中提煉出穩(wěn)定且高復用的內(nèi)容形成組件庫，并在不斷解決真實問題的過程中盛霎，總結(jié)出規(guī)范化赠橙、標準化的設(shè)計指導原則。這很大程度上保證了愤炸，構(gòu)建出來的設(shè)計系統(tǒng)能滿足我們的需求并應用于我們之后的產(chǎn)品項目中期揪。
相應地，我們構(gòu)建的設(shè)計系統(tǒng)應用在這些產(chǎn)品或者新項目上摇幻，經(jīng)過真實數(shù)據(jù)横侦、內(nèi)容的測試挥萌、迭代，也可反過來推動設(shè)計系統(tǒng)的持續(xù)完善枉侧。

2. 設(shè)計工具賦能

開始接手后臺產(chǎn)品的設(shè)計工作時引瀑，我使用的主要設(shè)計工具正好從 Photoshop 轉(zhuǎn)成 Sketch，當時對于 Sketch 還不太熟悉榨馁，軟件本身的各項功能也還不像現(xiàn)在這么完善憨栽，因而無法高效地建立、應用翼虫、共享組件庫內(nèi)容屑柔。
經(jīng)過這段時間的摸索，對 Sketch 的運用較之前熟練了一點兒珍剑，同時 Sketch 的各項功能掸宛、插件也都相當完備，譬如招拙，Library 功能唧瘾、Anima Toolkit 的自動布局功能等等（更多使用技巧可在第三篇中查看）。這無疑為設(shè)計系統(tǒng)别凤、組件庫的落地奠定了基礎(chǔ)饰序。

推動執(zhí)行

在構(gòu)建和推動設(shè)計系統(tǒng)的過程中，難免會收到來自產(chǎn)品經(jīng)理规哪、開發(fā)人員的質(zhì)疑求豫，譬如：

• 為什么不使用 Style Guide 代替設(shè)計系統(tǒng)？
  如上文所述诉稍，Style Guide 作為靜態(tài)文檔蝠嘉，在調(diào)用、維護均唉、協(xié)作等方面都存在一定的缺陷是晨，而設(shè)計系統(tǒng)則更具實用性和時效性，它能幫助我們解決 Style Guide 在實踐中的問題舔箭。

• 為什么不使用現(xiàn)成的開源設(shè)計系統(tǒng)？
  網(wǎng)絡(luò)上確實有非常多現(xiàn)成的設(shè)計系統(tǒng)可供使用蚊逢，但大部分設(shè)計系統(tǒng)所提供的 Sketch 文件都沒有將顏色层扶、字體、圖層樣式等設(shè)置為共享樣式烙荷，這意味著镜会，如果我修改了某個顏色，字體终抽、圖層戳表、組件的顏色都無法隨之更改桶至，即，無法做到原子級的全局響應匾旭。
  同時镣屹，文件中的組件也沒有考慮內(nèi)容的自適應，對 symbol 進行覆寫后价涝，其樣式可能出現(xiàn)錯亂女蜈，導致我們無法直接、快速地將這些組件應用到我們的業(yè)務(wù)場景中色瘩。
  因此伪窖，這些設(shè)計資源對于設(shè)計師來說，使用價值相對有限居兆。

• 創(chuàng)建覆山、維護設(shè)計系統(tǒng)會不會為開發(fā)人員帶來大量不必要的工作，成為長期的技術(shù)負擔泥栖？
  我認為汹买，同時具有「設(shè)計」和「代碼」組件庫的設(shè)計系統(tǒng)才是最有效的設(shè)計系統(tǒng)。所以聊倔，針對這個問題晦毙，我們可以和開發(fā)人員進行溝通，一起討論如何花較小的開發(fā)成本來實現(xiàn)設(shè)計系統(tǒng)的最大價值耙蔑，共同尋找解決方案见妒。

當然，除了以上例子甸陌，可能還會有其他各種各樣的問題须揣。在構(gòu)建之前、構(gòu)建的過程中钱豁、投入使用后耻卡，我們都需要不斷地進行溝通，達成共識牲尺。
設(shè)計系統(tǒng)是為了解決問題而存在的卵酪。只有在大家認同它、使用它之后谤碳，它才能發(fā)揮出應有的價值溃卡；也只有令更多的人參與進來、使用起來蜒简、發(fā)現(xiàn)問題瘸羡、提出問題，我們才有可能不斷地完善它搓茬，使它趨于更適用犹赖、更高價值队他。
否則，我們有可能花費很大的成本卻創(chuàng)建出一個過于僵化或者復雜的系統(tǒng)峻村，它將成為我們團隊共同的枷鎖麸折，限制住我們的思維。這比沒有設(shè)計系統(tǒng)更糟糕雀哨。

寫在最后

此設(shè)計系統(tǒng)的 Sketch 組件庫與后臺產(chǎn)品的 Sketch 設(shè)計模板都已在今年三月份創(chuàng)建完成并運用在實際的設(shè)計工作中磕谅。同時，我在語雀上整理雾棺、記錄了這些組件相應的使用指南和規(guī)范膊夹，并將通用行為與流程的設(shè)計約定、交互自查表等內(nèi)容納入了系統(tǒng)捌浩。設(shè)計系統(tǒng)的詳細內(nèi)容可在第二篇中查看放刨。

需要特別指出的是，除了提煉尸饺、總結(jié)自我自己的實際工作进统，記錄文檔中的部分內(nèi)容也參考、引用了 Ant Design 的內(nèi)容浪听，非常感謝 ANTD 團隊～
另外螟碎，在創(chuàng)建組件庫、構(gòu)建設(shè)計系統(tǒng)的過程中迹栓，我還參考很多相關(guān)的文章掉分、設(shè)計系統(tǒng)，都已一并在第三篇中列出克伊，非常感謝這些作者和團隊～

以設(shè)計系統(tǒng)的形式整理這些內(nèi)容酥郭，一是希望以此作為我們后臺產(chǎn)品的設(shè)計指南，二是以此作為我個人的工作總結(jié)愿吹、學習筆記不从，并期待能借此機會向更多的小伙伴們學習，一起探討中后臺產(chǎn)品在設(shè)計犁跪、前端開發(fā)上的更多解決方案椿息。

相關(guān)鏈接：
后臺產(chǎn)品設(shè)計體系的創(chuàng)建過程回顧二：創(chuàng)建過程及內(nèi)容
后臺產(chǎn)品設(shè)計體系的創(chuàng)建過程回顧三：工具與資源分享
SDS 的記錄文檔（語雀）
設(shè)計約定記錄文檔（語雀）
SDS 的記錄文檔（Gitbook）
源文件下載（騰訊微云）