2021-10-9 資深UI設計者
以設計師的角度，基于覆蓋面的廣度，組件庫可以從小到大分為三個層次：
第一個層次的組件庫要解決的是單個項目內的復用，同時也能保證整個項目的設計統一性。如果同一個項目下如果有多個設計師，為了保證各個頁面的交互和視覺一致性，一個統一的標準就更有必要了，而組件庫可以說是這個標準的具化，不同的設計師使用同一個組件，可以有效保證頁面的一致性，同時也提高了工作的效率。
那，這個時候就一定必要創建組件庫嗎？恐怕也不盡然，如果這個項目需要快速開發上線進行驗證，后續發展路線也很模糊，那犧牲部分一致性，容忍不同頁面的相對差異，或者用類似復制粘貼這種粗暴方式等等來達到目的，也許性價比更高。
第二個層次的組件庫，其價值在于多個項目間保持統一性，解放設計師重復性的工作。這個價值有一個前提，就是這些項目之間是需要保持一致性的。
第三個層次的組件庫，則是為了更廣泛的提高效率，它已經跳出了設計師這個范圍，和其他職業產生了聯動，涵蓋了研發技術甚至更多專業人員，也被稱作業務型組件。雖然同樣的模塊不用再重新設計也不用再重新開發很吸引人，但這些組件的設計是否能被使用方認可？原有支持的技術棧是否與使用方需要的一致，學習和推廣這些組件的成本是否能夠得到同等回報？相關的公司流程、規則和資源是否方便對組件進行學習、推廣和使用？都是需要考慮的問題。
這三個層次的組件庫層層遞進，每上升一個層次，聽起來就越吸引人，所耗費的精力卻越大。
做到最好的，諸如谷歌、微軟、蘋果、阿里等等，在業務上也有同等布局，比如需要開放給廣大的開發者形成生態平臺。這個時候，組件向外部賦能，不再局限于公司內部，所發揮的價值已經遠遠大于其所耗費的精力。
但作為一個新的組件庫，我們首先需要根據自己的實際情況來確認要不要創建組件，而不是僅僅因為它美名在外。不做組件庫，或者使用第三方的組件庫，都是一種選擇。而不是為了做組件庫而做組件庫。當確認這個組件庫在當前的實際情況下依然有創建的價值，我們就要把這個價值更具像化，成為切實可行的目標。
進入公司的第二年，我開始基于我涉及到的三個 B 端產品來創建組件。
每一個 B 端產品其實都是一個系統，是平臺+應用的結構，數據信息在這兩者之間運轉。雖然看著挺龐大，但首先，這三個產品體系都是基于一個統一的產品價值（AR 技術）來映射到不同應用場景（遠程視頻、巡視檢查、展覽展示）的。其次，在人力資源的配備上，三個系統的產品、研發和設計負責人都同屬于一個團隊，團隊優先級一致。另外，雖然主次分工不同，但同一個產品經理或設計師都會同時涉及到三個產品線的定義中。
所以，在建設組件庫的時候，我直接提煉了三個產品線的相同功能模塊，給出了包含多個頁面和多個交互邏輯組合而成的功能模塊，對于市面上大多組件庫會包含的按鈕、提示、彈窗等也沒有專門羅列，只將 AR 眼鏡上有過特殊交互說明的模塊給標示了出來。
來源：公司內部 Guidelines 文檔
可能由于恰好符合實情，在沒有費很多力氣推廣的情況下，研發團隊就形成了登陸和首頁列表 2 個模塊，其中的登陸模塊，更是一直沿用到了現在。
但隨著探索期的深入，產品對接的業務場景迅速擴大，加上架構調整，公司布局更新，組織使命調整，想要一次打通形成第三層次的組件很快就行不通了。雖然后來我也針對這個現象做過一些調整，但收效并不明顯，之前一直認定主要原因是時間和精力不夠，直到組織設計團隊完成了一場 workshop 后我才發現，沒有聯系實際情況設定切實可行的目標，可能才是收效甚微的主要問題。
現在的實際情況是怎么樣的呢？
于我所在的組織來說，三個部門分別負責了 1-3 個業務線，每個業務線都對應不同的用戶場景和產品需求，需要用實際的落地業績和財務收入迅速證明自己所在業務線對于公司的價值，所以即使我能看到不同業務間存在復用的可能，想要像之前一樣，直接形成第三層次的組件也很難。
這個時候，借鑒 OKR 思維，設定更具有實質性意義的 KR 目標，然后讓組件庫如同產品一樣去迭代，確保每一次迭代都是關鍵和有效的。
比如，我認為創建的組件庫要到第三層次才是它基于現狀能獲得最好的價值體現，那就可以把這個設定為 O。這個 O 的設定是由戰略指引的，需要對齊公司或部門的目標，也就是我們在第一步明確的價值。
接著，我們來設計子目標，也就是 OKR 里的 Key results，可衡量的關鍵結果，以終為始，形成這個組件庫的目標體系。
對應我這個例子，就可以從用戶群的不同分為兩類，一個是針對設計師而言有用，一個是對協作部門來說有用，以年度為周期，可以形成兩個關鍵結果：
如果再往下細分，還可以把年度周期拆分為季度周期甚至月度周期，設定更小的 OKR 目標體系，使結果得到更及時的追蹤和復盤。
因為我們的項目幾乎都是 To B 的業務線，每個產品無論大小都是一個體系，即信息在前端和后端之間傳輸，用戶至少包含 2 個及以上的職業角色，最簡單的是 1 個 Web 平臺+1 個 AR 終端應用，所以要達到前面的 2 個關鍵結果，這個組件庫從一開始就需要支持至少 2 個終端。
最開始由于幾乎是單推我們自研的 AR 眼鏡作為應用終端，在設計組件分類的時候，我選擇優先羅列了組件，再在每個組件下區分終端。
這種形式和 Material design 的組件庫相似，基于一種終端衍生到其他平臺。在目錄上，你會首先看到組件列表，再看到每個組件支持平臺。
來源：Google Material design
但很快，這種推廣模式就被改變了，除了 AR 眼鏡，機器人、邊緣算法盒子、工業 PDA、帶 CV 模組的相機等都納入了不同的業務線，以形成更貼合場景的方案構成。雖然它們都圍繞計算視覺為核心技術，但在界面層的表現上就大不一樣了。
而這個時候，我還是以之前的形式組織著這個組件庫。導致使用的時候，必須得先看一看每個組件長長的目錄，才能找到當前所需要的對應終端資源。
來源：公司內部組件介紹頁面
在組織過那場 workshop 后，我開始廣泛的研究行業內其他優秀的組件庫。其實大多數優秀的組件庫都有對應明確的、單一的終端，比如 Ant 組件是對應 web 終端，Hololens 的組件是對應 AR 眼鏡的，即使蘋果這樣跨平臺多設備的廠商，也分移動設備、電視設備、手表，輸出了不同的組件庫。
出于種種考慮，我將原本處于二級目錄的終端分類提升到了一級，給設計師使用的 Sketch 組件也按終端劃分成單獨的文件。然后，再根據當前的業務情況，聚焦到 2 個主要的終端上：Web 網頁和 AR 眼鏡。
由于有了聚焦的終端，在借鑒其他組件庫時，也就可以在之前廣泛研究的基礎上縮減范圍，得到更有參考意義的結果。
比如，針對 AR 眼鏡終端，Windows 的 Hololens 和 Magic leap 的設計就比 Material design 更具有參考意義。
來源：Magic Leap 設計 & Windows Hololens
即使具有參考意義，但由于每一個組件庫所面臨的實際情況都不一樣，生成組件庫時依然需要做對應性的更改。
以我這里創建的 AR 眼鏡 UI kit 為例，因為最終要落入不同業務線的各個項目中，應對的客戶和場景很難統一，所以，色調統一就不需要作為該組件庫生成時一定要滿足的條件。如果要保證一致性，Sketch 里的圖層樣式，甚至顏色變量都可以作為解決方案放到組件庫里。
來源：公司內部 Sketch 頁面
過硬的設計技能和專業能力，對建設一個優秀的組件庫必不可少，但我認為一個優秀的組件庫，必然首先是一個實用的組件庫，在被它的光環吸引的同時，緊緊的扣住當前環境的實際情況，依時而定、依時而變，不被自身的專業角度限制，才能夠發揮它本來應該給團隊或公司帶來的價值。
按照實際情況調整，這句話說來簡單卻最是困難，因為它就像這個組件庫的土壤，土壤變了，上面就要跟著變化。這 3 個步驟，首先是在確認有這樣一片讓它生長的土壤，然后分析土壤當前和未來可以提供個組件庫的養分，最后，才是動手開干，讓組件庫在這片土壤上開花結果。
因為土壤不一樣，同樣的方法，最后生成的組件庫可能會完全不一樣，但并不妨礙它成為助力協作，提高效率的一個好的組件庫。
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( m.ssll180.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務