設計的組件化

01-27

我們在設計一個系統的時候會不可避免的與各個不同的角色互動：不同的設計師、不同的前端工程師，這其中不可避免的會出現大量的溝通和協作問題，如何在這類多角色互動中提高效率，降低溝通損耗就不可避免的成為一個問題。「組件化」可以在某些層面幫助我們更好的解決這個問題。在復用和設計過程中，與 Brad Frost 提出的 Atomic Design 有相似之處。

什麼是組件？

組件是一個個不可再被拆分的基本設計元素，例如一個 Button、一個 Input 等。每一個組件都應該有自己的迭代和設計過程，組件屬於平台設計的一部分，與業務設計互補，每次設計迭代也正是在迭代這一個個組件。

組件化的好處是什麼？

良好的組件化在應用時能夠帶給我們三個好處：

復用

我們可以以非常低的成本得到一個完整功能的組件，組件本身與業務邏輯無關，產品設計師無須過多關心組件本身的邏輯。以 Button 組件為例，我們設計了 2 種樣式，分別適用於默認場景（.Button）、主要場景（.Button-primary），產品設計師只需要針對不同的場景分別使用適合該場景的 Button 即可，他不需要關心這個 Button 自身的 padding、margin、size 等。

一致

這種高復用可以讓整個系統一致性更好，當我們想要修改 .Button 的 padding 時，所有使用了 Button 組件的位置都會變更。之前開玩笑說判斷一個網站的組件化做的是不是足夠好的方法是：你能否用 StyleBot 很快的幫它換一個皮膚，同時在它之後的迭代中不會出現本該一致的地方卻不一致的問題。這種一致性會直接反饋到用戶的使用中，不會被各種不一致的操作迷惑。

效率

高復用和一致性最終產生的結果就是設計和開發效率的提升，我們可以通過搭積木的方式很快的得到一個基本可用的界面，產品設計師可以更加專註在問題的解決上，而不是花了大把時間在基本組件的設計上。同時開發也可以直接利用已經做好的組件進行開發，開發效率直線提高。甚至我們可以直接基於瀏覽器設計，使用組件庫可以更快的得到一個可交互的高保真的設計稿。

針對平台設計的好處有二：

平台設計迭代落實到人

基於不同特性的組件可以交由不同的設計師進行維護，例如 Animation 組件會對動畫更有要求、TextEditor 需要對富文本處理更有了解、icon 部分則需要對不同瀏覽器 icon 解決方案有研究，這樣每個人都會負責一部分組件的迭代，不會出現設計很久沒有被迭代過、一個組件被隨意設計未經全面考量等等。

組件迭代更系統

基於不同的組件特徵將他們分配給不同的設計師，這些設計師可以站在更高的平台角度而非業務角度來思考這些組件應當被如何設計。可以更加全面的思考一個好的組件應該是什麼樣的、當組件無法滿足業務需求時進行更加完整的擴展和升級。更系統的迭代不代表脫離業務，大部分的組件設計師同時也是業務設計師，他們會更了解業務的需求是什麼，在此基礎上抽想出更加通用的組件設計。

組件的類型和粒度

一個組件一般有三種狀態，例如同樣的一個 Button：

默認：最常見的一種狀態，純界面區別。如 .Button、.Button-primary
交互：交互後發生的變化，與該組件交互後的狀態一般有兩種實現方式：1、樣式（.Button-primary.is-active）；2、偽類（:focus），可根據不同的需求採用不同的實現方式。
子組件：該組件是其他組件的一部分，如果該組件作為其他組件的一部分時樣式有所變化，則需要單獨定義樣式，如 TopNav--AddQuestionButton、TopNav--SigninButton。

當該組件可能會成為另一個組件的一部分時，需要明確該組件的子組件狀態和常規狀態時的區別和聯繫是什麼。下面是一個常規的 input 組件：

.input {n padding: 8px 10px;n font-size: 13px;n line-height: 15px;n box-shadow: 0 1px 1px rgba(0,0,0,.1) inset;n border-radius: 3px;n background: #fff;n border: 1px solid #ccc;n color: #222;n box-sizing: border-box;n}n

當我們在一個新的 dialog 中使用到了這個 input 組件，但在場景下 input 有些許變化，這時需要明確幾個問題：

變化是否有必要：大家都喜歡拋棄舊的搞新的，這樣沒有歷史包袱，但這種變化對於整個系統而言並不一定是好事。
input 之間是否還有關係：1、兩者的使用場景分別是什麼；2、哪些樣式會被共用。
變化幅度有多大：基於之前的共用樣式範圍，一般有兩種情況：1、少量樣式不共用；2、大量樣式不共用。第一種情況一般會復用舊的樣式，同時寫新樣式覆蓋掉原來 input 中不需要共用的部分，例如.Input.DialogInput。第二種情況的少量樣式共用，比如只有 border 一樣，其他的都不一樣，那基本上會重寫整個組件樣式。

我們在組件開發和設計前明確清楚兩個組件的關係是什麼，這樣可以降低設計和開發成本，提升迭代效率。

組件設計應該如何迭代

兩個大原則：1、組件迭代不應該 block 業務迭代；2、任何組件改動都應由該組件負責人負責跟進。

當現有組件無法滿足業務需求時，業務設計師應及時與組件設計師及時溝通確認需求，如果可以在當前方案中快速調整適應業務需求，則在組件調整完畢後使用新的組件方案；如果存在折衷方案：折衷方案如果違背組件設計意圖，則不能使用該方案。如果不違背設計意圖，則可以採用該方案。如有必要，組件設計師需要事後重新調整組件方案兼容該需求。

每次組件迭代應該關注以下幾點：

視覺表現：是否與平台主視覺一致
業務兼容、擴展性：當前已知的業務需求能否在該組件下被良好滿足，是否有足夠好的擴展空間而不至於迭代時需要重新設計
邏輯一致性：該組件在不同設備下的操作邏輯是否一致和友好（可根據平台特性有所變更）
極端情況表現：文案過長、屏幕過寬、空狀態…
視障用戶友好：使用鍵盤 tab 時友好、樣式正常、色盲用戶友好…
瀏覽器和性能限制：微信瀏覽器滾動過程中無法執行 JS、儘可能不要用 JS 動畫…

如何管理和呈現組件？

採用 Sketch Shared Style（Text Style & Layer Style）維護設計組件樣式，Symbol 維護 icon 和大型組件，Symbol 內可以嵌套 Shared Style，採用 Git 協作。每一個組件需要包含如下內容：

組件使用規範

視覺樣式（組件規則：size、padding、margin 等）
狀態變化：hover、disable 等；內容變化：空狀態、報錯等
交互邏輯（界面變化時的轉場邏輯：切換、出現消失）
動畫（CSS 和效果展示：需要附上關鍵數值）

迭代歷史：每次組件迭代時遇到的問題、思考過程、最終方案、數據表現（如果有）
最佳實踐和注意事項：該組件的正確用法、最佳實踐和目前已知的缺陷。

將組件以目錄形式組織在 Git 中，每個組件單成目錄包含上述內容，每次迭代另開分支，不應該在 Master 上直接修改，修改完主模板文件並測試通過文檔補全後再合併進 Master 並周知其他設計師全平台升級。

-----

最後知乎設計團隊在招人喲，實習全職均可！有興趣的老師請快聯繫我！

當然我們超酷的前端團隊也在招人，如果你是一個強而有力的前端工程師請火速發簡歷給我呀！今天投簡歷明天就上班兒！