久久久久无码精品国产app,日本高清二区视频久二区

搜索

APP

起點課堂會員權益

職業(yè)體系課特權

線下行業(yè)大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業(yè)技能直播

會員專屬社群

榮耀標識

發(fā)布

注冊 | 登錄

如何規(guī)避Design System架構設計中的邏輯陷阱

我是芝士

2018-06-08

1 評論 2749 瀏覽 12 收藏

12 分鐘

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

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

組件庫與設計規(guī)范

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

兩者的功用及關聯(lián)性就是這樣一目了然；兩者的架構設計在很大程度上具有共通性。大體上，組件庫與設計規(guī)范的架構體系在顆粒度較小的層面通常可以做到一致；但設計規(guī)范也會有其特定的目標及作用范圍，當涉及到“設計模式”等層面，顆粒度往往會超過組件庫所能承擔的范圍，此時也無需追求全面一致。

“原子化設計”不錯

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

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

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

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

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

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

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

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

問題的根源

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

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

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

一些原則

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

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

原則一

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

原則二

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

原則三

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