上周說到了《像做產(chǎn)品一樣對Design System進(jìn)行前期規(guī)劃》，包括目標(biāo)、原則、范圍與架構(gòu)，這四個(gè)方面。本周在最關(guān)鍵的部分深入推進(jìn)一步，聊聊“架構(gòu)”當(dāng)中的一些問題。

需要再次說明，這些內(nèi)容多數(shù)來自于我日常的工作日志，更像隨筆，且僅代表我個(gè)人在面對特定的產(chǎn)品/項(xiàng)目/團(tuán)隊(duì)時(shí)所用到的工作思路和方法；事情只有特定的最優(yōu)解，而非唯一答案；希望為各位帶來一定的參考價(jià)值。

組件庫與設(shè)計(jì)規(guī)范

記得之前看到一篇文章，比喻得非常漂亮 – 僅就相對狹義的、以組件庫與設(shè)計(jì)規(guī)范為主要組成部分的Design System而言，你可以將其想象成宜家家具 – 組件庫是以零件形態(tài)呈現(xiàn)的家具產(chǎn)品，而設(shè)計(jì)規(guī)范便是指導(dǎo)你完成組裝的說明手冊。

兩者的功用及關(guān)聯(lián)性就是這樣一目了然；兩者的架構(gòu)設(shè)計(jì)在很大程度上具有共通性。大體上，組件庫與設(shè)計(jì)規(guī)范的架構(gòu)體系在顆粒度較小的層面通?？梢宰龅揭恢拢坏O(shè)計(jì)規(guī)范也會有其特定的目標(biāo)及作用范圍，當(dāng)涉及到“設(shè)計(jì)模式”等層面，顆粒度往往會超過組件庫所能承擔(dān)的范圍，此時(shí)也無需追求全面一致。

“原子化設(shè)計(jì)”不錯(cuò)

有過相關(guān)經(jīng)驗(yàn)的朋友或許都知道，組件庫初期的架構(gòu)設(shè)計(jì)工作是最消耗時(shí)間與心力的過程，特別是對于大中型“成熟”產(chǎn)品而言，太多的功能流程及相應(yīng)的組成頁面，太多的不一致性問題 – 以怎樣的規(guī)則去梳理可復(fù)用的組件，以怎樣的顆粒度去劃分組件層級，怎樣確保劃分方式具有足夠的靈活性與實(shí)用性 – 推進(jìn)過程往往是慎之又慎、舉步維艱的，每一個(gè)步驟都嚴(yán)格以上一個(gè)步驟為基礎(chǔ)。

對于組件的顆粒度劃分，目前最經(jīng)典的理論是“原子化設(shè)計(jì)（Atomic Design）”，我們之前在一些文章當(dāng)中也有介紹；可大致理解為：

• 原子：最基礎(chǔ)的、不可分割的設(shè)計(jì)要素，宜家家具的零件單元，一塊樂高積木，等等。通常包括顏色、文字、柵格體系等樣式風(fēng)格要素，以及圖標(biāo)、按鈕、文本輸入框、切換等功能性的界面基礎(chǔ)要素。
• 分子：由原子組成的、具備獨(dú)立功能性的最小可復(fù)用單元，例如一個(gè)包含了文本輸入框、占位符文字及按鈕等元素的搜索欄，或是一個(gè)包含了用戶頭像、用戶名、用戶評論內(nèi)容及點(diǎn)贊按鈕的列表單元（Table View Cell）等等。
• 有機(jī)體：由單一/多種類型的分子組成的信息/功能性模塊。

至于“模板”和“頁面”，個(gè)人看來對于組件庫架構(gòu)設(shè)計(jì)的意義不大；或可從“視圖”的角度理解“模板”，這個(gè)再議。

但會出現(xiàn)很多問題

然而在很多時(shí)候，當(dāng)你準(zhǔn)備以原子化設(shè)計(jì)的思路規(guī)劃整個(gè)組件庫的架構(gòu)時(shí)，往往會發(fā)現(xiàn)實(shí)際狀況絕非如此層次分明、符合邏輯；原子級別的要素大體還好，一旦進(jìn)行到“分子”和“有機(jī)體”的層面，時(shí)常感到難以判斷和區(qū)分。

梳理架構(gòu)的第一步通常是UI清查，這是一項(xiàng)枯燥和冗長的工作，你需要將現(xiàn)有的典型頁面（截圖或設(shè)計(jì)源文件）整合在一起，提煉出各類典型元素，進(jìn)行相對松散的歸類，判斷組件庫的大致架構(gòu)；期間可能遇到的典型問題包括：

• 對于一些模棱兩可的元素，應(yīng)該按照相似的樣式進(jìn)行歸類，還是按照功能做區(qū)分？譬如樣式上均屬于“標(biāo)簽（Tag）”的元素，從功能角度，某些是真正意義上的屬性標(biāo)簽，某些則是選項(xiàng)列表的組成部分；這時(shí)是否應(yīng)該將它們歸為一類？
• 多數(shù)涉及“內(nèi)容”的產(chǎn)品，內(nèi)容類的“分子”或“有機(jī)體”占據(jù)著很大的組成部分，且自身的組成元素往往會根據(jù)不同的頁面環(huán)境而有著大大小小的不同，包括商戶、商品、評論、內(nèi)容Feed等。對于這些內(nèi)容，是否有必要封裝成可復(fù)用的組件，封裝之后是否反而會影響實(shí)際設(shè)計(jì)時(shí)的靈活性？它們與其他“功能性”的組件在邏輯上有怎樣的不同？
• 除了主色盤及基本樣式以外，產(chǎn)品當(dāng)中往往會四處出現(xiàn)用途比較單一或邊緣的配色、文字及圖形樣式，這些樣式是否有必要進(jìn)行嚴(yán)格的定義？如果定義，如何避免樣式庫與組件庫的過度復(fù)雜；如果不定義，如何確保這些“非主流”元素在未來設(shè)計(jì)過程中的一致性？

問題的根源

個(gè)人認(rèn)為，通過原子化設(shè)計(jì)的思路進(jìn)行UI清查和架構(gòu)設(shè)計(jì)時(shí)遇到的一系列問題，其根本原因在于，“原子化設(shè)計(jì)”本身更像是一種開發(fā)思路，它是事物構(gòu)成的基本規(guī)律與方式，但未必適于“認(rèn)知”和“使用”層面的心智模型。

你可以遵循嚴(yán)格意義上的原子化設(shè)計(jì)思路去到Sketch當(dāng)中逐層進(jìn)行樣式定義與Symbols嵌套，但最終的產(chǎn)出未必是對設(shè)計(jì)師實(shí)際有用的組件庫。

如前所述的一系列問題、矛盾，本質(zhì)上是用戶（設(shè)計(jì)師）的心智模型與產(chǎn)品（組件庫）的實(shí)現(xiàn)邏輯之間的沖突。當(dāng)你自身是設(shè)計(jì)師，同時(shí)又是組件庫/設(shè)計(jì)體系的制作人員時(shí)，你會不經(jīng)意間在“設(shè)計(jì)師”與“產(chǎn)品開發(fā)人員”這兩個(gè)角色之間交織互換而不自知。

一些原則

對于組件庫/設(shè)計(jì)體系這樣復(fù)雜的事物而言，任何單一的邏輯與標(biāo)準(zhǔn)都未必行得通；最終還是要從我們在上一篇當(dāng)中聊過的“目標(biāo)”和“原則”出發(fā)，結(jié)合用戶的認(rèn)知模型與產(chǎn)品自身的實(shí)現(xiàn)邏輯，找到相對折中的方式進(jìn)行推進(jìn)。

對于實(shí)際“用戶”，即設(shè)計(jì)師而言，組件庫/設(shè)計(jì)體系的目標(biāo)在于解決表現(xiàn)層面設(shè)計(jì)工作中的痛點(diǎn)，提高執(zhí)行效率與產(chǎn)出的標(biāo)準(zhǔn)化。圍繞著這樣的目標(biāo)，我給自己制定了幾點(diǎn)原則；每當(dāng)在組件庫架構(gòu)規(guī)劃中遇到問題和矛盾時(shí)，通?？梢詤⒖歼@些原則，以實(shí)際結(jié)果為導(dǎo)向進(jìn)行判斷，避免陷入邏輯陷阱：

原則一

對于組件庫架構(gòu)設(shè)計(jì)與庫文件的制作方式，在大方向上要符合原子化設(shè)計(jì)思路，即顆粒度從小到大，從簡單到復(fù)雜；特別是在Sketch Library文件的實(shí)際制作過程中，從技術(shù)角度嚴(yán)格遵守層級思路是必需而非better to have。原子化設(shè)計(jì)的思維方向無錯(cuò)，解決問題的關(guān)鍵在于結(jié)合使用者的心智模型，即原則二。

原則二

難以確定組件顆粒度/復(fù)用性/在架構(gòu)中所處的類別時(shí)，避免陷入過于嚴(yán)格的邏輯思維模式，而要考慮設(shè)計(jì)師的實(shí)際所需，考慮設(shè)計(jì)師在組裝界面時(shí)的直覺與思維模式，考慮設(shè)計(jì)師在典型的需求中預(yù)期得到哪些零件，他們/我們對這些零件通常是如何歸類的，哪些屬性是他們/我們需要頻繁訂制的，哪些是很少/不會觸及到的。對于使用Sketch進(jìn)行界面設(shè)計(jì)的團(tuán)隊(duì)，組件庫最終的產(chǎn)出將體現(xiàn)在一個(gè)個(gè)Symbol和Shared Style當(dāng)中，而非設(shè)計(jì)規(guī)范中描述的設(shè)計(jì)模式或是開發(fā)側(cè)的代碼包；這些Symbol和樣式能否被設(shè)計(jì)師快速發(fā)現(xiàn)、理解和調(diào)用，才是最重要的，無論它們在實(shí)現(xiàn)邏輯上是否符合這樣或那樣的設(shè)計(jì)思想理論；其他都是浮云，實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)。

原則三

充分分析和參考現(xiàn)有的任何設(shè)計(jì)規(guī)范/標(biāo)準(zhǔn)，運(yùn)用你的基礎(chǔ)開發(fā)常識（如有）去理解開發(fā)側(cè)的代碼組件架構(gòu)；所有這些文檔都能在一定程度上映射出產(chǎn)品的信息與功能架構(gòu)。此外，相比于埋頭在繁冗的UI清查工作當(dāng)中難以自拔、糾結(jié)邏輯，不如多花些時(shí)間與一線設(shè)計(jì)師進(jìn)行溝通，了解他們/我們當(dāng)前是否有著組件化的、非正規(guī)但有效的解決方案。將所有這些“現(xiàn)有”的應(yīng)對方案進(jìn)行匯總，再沿著原子化設(shè)計(jì)的大方向，結(jié)合自己的UI清查，逐漸梳理出一套即在一定程度上符合邏輯，又充分適用于實(shí)際需求的組件庫架構(gòu)框架。

相關(guān)閱讀

像做產(chǎn)品一樣對Design System進(jìn)行前期規(guī)劃

原文作者：Marcin Treder

原文地址：https://heydesigner.com/blog/minimum-viable-design-system/

譯者：C7210（微信公眾號：Beforweb（ID：beforweb）），交互設(shè)計(jì)師、UX設(shè)計(jì)熱愛者、VR探索者、譯者、貓奴、吉他手、鼓手，現(xiàn)就職于騰訊上海，

譯文地址：http://beforweb.com/node/970

題圖來自 Pexels，基于 CC0 協(xié)議