從網上搜索設計組件，我們能找到各種對外公開的設計組件庫，同樣還有不少或概括或詳細的文章，手把手教你“如何搭建一個好的設計組件庫”，但這些方法論很少探討面對C端組件頻繁增改、設計規范動態調整，如何高效賦能業務設計交付的相關內容，但這恰恰是搜索業務面臨的關鍵問題。
搜索是一個“牽一發而動全身”的業務，每一個微小的設計細節都有可能影響各個業務的數據指標，一個“好的設計組件庫”需要以一種潛移默化的方式讓設計師掌握設計規范，完成合規的設計，從這個角度而言它應該比較
「好懂」
。
而作為服務于整個設計團隊的公用設計組件庫，面對每月數以萬計的調用次數，它必須保障最基本的易用性，應該非常
「好用」
。
同時，面對頻繁迭代，“好的設計組件”還需要保持最快的更新速度，為各個橫向團隊提供正確的樣式，從這個角度來說它還要
「好維護」
。
因此，
「好懂、好用、好維護」
是搜索設計語境下，對一個“好的設計組件”的定義。
接下來，我們將從這三個「好」入手，分享搜索設計組件庫在升級過程中的一些思考，希望能和大家共同探討。
“萬丈高樓平地起”，我們先來說說如何從零開始構建一個既符合設計規范又易于理解的設計組件。
首先，在搭建組件時，我們可以考慮采用
多層嵌套
的方式，即組件(Component)內部嵌套變體(Instance)。這種方式不僅能省去組件搭建和修改過程中的重復操作，甚至還能在解綁組件時，通過選中內部的子組件圖層進行解綁，大大簡化了搭建和使用雙方的操作流程。
在多層嵌套的思路下，我們可以進一步用
“底層靈活、上層收斂”
來指導組件的搭建。這意味著底層變體的形式足夠多樣，能夠支持大部分的狀態切換，而在上層組件搭建的過程中顯性地加強規范的指引(如規范中不允許使用的樣式不對外展示)，以降低超出規范設計的可能。
具體的搭建流程可以大致分為三步：
場景收集和分析、搭建基本變體組、拓展高階變體組
。
我們將通過視頻組件搭建的生動案例，具體介紹如何依據“底層靈活、上層收斂”原則來搭建組件庫，使得組件本身既足夠靈活，又能起到足夠的約束作用。
在著手搭建某類組件時，我們首先通過規范確認和場景遍歷，廣泛收集各類變體。隨后，從我們能想到的所有維度出發，對這些變體進行細致定義。這樣，我們就能得到一張詳盡描述組件變體性質的表格。表格的第一列依次列出變體1、變體2、變體3等，而第一行則羅列出各種維度，如寬度、比例等。通過這種方法，我們可以將原本零散、雜亂的組件變體描述，系統地歸納整理成一張清晰明了的表格。
表格通過不同維度來唯一確定一個變體，這些維度可大致分為兩個特性和一個共性。共性指的是所有變體在這一維度上均保持一致，常見特性則涵蓋了最常見的分類性質，如寬度、高度、數量和優先級等，而業務特性則與具體業務緊密相關。
在搭建組件時，我們可以遵循
「共性-常見特性-業務特性」
順序，這樣的順序有助于降低理解成本，因為最符合心智的分類被置于外層，同時底層的組件又保持了足夠的靈活性，便于切換各種變量。對于業務特性，我們可以根據實際情況靈活處理，既可以將其作為基本組件的延展，也可以不將其納入組件范疇。
-
-
-
自動播放情況與業務相關，但不一定需要在組件庫中呈現；
-
高階組件僅涉及少部分尺寸的組件，應在完成基本組件搭建后再進行。
據此，我們可以輕松梳理出視頻組件搭建流程的優先級：
-
-
基本組件尺寸和組合是最符合用戶心智的變體選擇，應緊隨其后；
-
值得注意的是，“封面槽位”是“播放狀態”中的一個圖層。根據“底層靈活、上層收斂”的原則，我們將其插入到搭建播放狀態之前。因此，視頻組件的最終搭建流程為：
-
-
-
-
完成對視頻組件搭建的分析，我們就可以有條不紊地開始搭建組件了。先搭建基本組件視頻組件，再用基本組件搭建高階組件。這一步驟雖然為大家所熟知，但仍需格外注意，如配置項的設置要力求合理，也可以融入設計規范和使用規范，同時還應將一些搭建過程中的零散組件集中收納避免被調用。關于這些具體的注意事項，我們將在后續部分進行詳細闡述。
至此我們完成了組件搭建的基本流程，一個達到及格線的視頻組件就誕生了。據統計，優化后每次調用視頻組件將節省至少10步的點擊操作！
完成了一個基本組件的搭建后，我們可以轉換視角，從使用的角度來審視并檢查這個組件。
我們期望，從插入組件變體、切換組件配置，再到最后的解綁組件，整個流程都能縱享絲滑且穩定可靠，確保業務設計師在使用過程中獲得最佳體驗。
我們可以一步步來審視組件的使用過程。首先是插入組件，據觀察，通常有三種方式，①在左側的資產面板(Assets)中直接找到對應組件并插入；②通過查閱設計規范，鎖定所需的變體后復制粘貼；③選中一個不需要的組件，通過右側的“切換變體”面板(Swap instance)切換成所需的變體。很明顯，在這個過程中依賴的是組件的精準搜索和快速定位。
為了提升搜索精度，我們可以從組件命名入手，采用中、英、數字結合的方式，實現模糊匹配；也可以在發布時隱藏不希望被調用的組件，以減少無用的搜索結果。如果組件是采用前文提到的“多層嵌套”方式搭建的，我們可以添加“Preferred”子組件，這樣在切換時會優先展示這些子組件，這個功能在切換圖標時尤為實用。
對于習慣邊查閱設計規范邊使用組件的設計師，我們增加了更多實際使用的正誤案例，這些案例直觀展示了組件變體的正確選擇和使用方式，進一步降低了規范的理解成本，有效輔助設計決策。同時，我們專門維護了一個固定區域，用于平鋪展示所有組件變體。為了確保能夠輕松點選，我們將變體放在最外層展示(即不在任何Frame、Group或Section中)。這樣能讓設計師一目了然地看到所有變體，從而快速選擇所需的組件。
在組件配置階段，有三項注意點能讓組件更加易用，即“重視組件的可視化效果、設置高效易用的配置項、貼心地保存修改”。
考慮到C端組件的多樣性和用戶的使用習慣，我們應避免使用過于復雜的分組方式。相反，應更注重組件的樣式展示，并盡量簡化組件的層級結構。這樣，設計師在使用時能夠更直觀地看到組件的外觀，而無需深入復雜的層級去查找。
另外值得注意的是，Figma會默認用組件集合中最左上角的組件生成預覽樣式，因此應當把視覺上最有代表性的變體放在左上角，這個效果在切換變體(Swap instance)時很重要，因為目前在該面板中沒法查看組件細節，只能靠縮略圖和名稱來推測是哪個組件。
其次對于配置項的設置也大有講究，業界有組件庫為了實現C2D2C，從源頭上將設計組件和前端組件的配置項打平，這是不錯的思路，但有可能會提升設計側的理解成本。針對搜索業務的特殊語境，我們還是選擇了從「規范理解」角度去設置組件的配置項，將所有允許自定義的配置盡可能外露，并清晰地說明修改限制，如字數限定、選項個數等，這樣能夠在使用的過程中強化業務設計師對規范的掌握。
另一個常常被忽視的關鍵點是選項和配置的排序問題。為了提高瀏覽和選擇的效率，建議對選項和選項之間，以及外層的不同配置項，都按照一定的邏輯順序進行排序。
最后一點，我們稱之為
“貼心地保存修改”
機制，這個針對的是文字修改的場景。
在實際操作中，使用一個組件可能需要對多個配置項進行修改。有時在修改完文字內容后再去調整其他配置時，已修改的文字會被重置。這時文本屬性(text property)的設置就顯得尤為重要，它能夠記憶并保存修改過的文字內容，從而免于重復輸入。
還有一些情況是，某個組件變體實際上并沒有與某個值相對應的組件(盡管Figma機制允許選擇該值)，用戶切換后就會發現組件完全變了，只能撤回。為了避免這類情況，建議使用另外的標記來表明組件某個設置項是不可切換的。
完成了組件的搭建和檢查，接下來讓我們聚焦于組件的日常維護。
這一環節可以從兩個維度展開，一是依托中臺的日常數據監控進行維護，二是通過團隊內部的緊密協同機制來保障。后者更多側重協作流程和機制上的建設，在本文中我們不做更多展開，重點討論前者。
數據監控的方式主要依托Figma中的組件數據看板(查看路徑：View libraries-Analytics)，看板中展示了各個組件的調用數和解綁數數據，這些數據不直接反映組件的優劣，但如果我們觀測到某個組件解綁率偏高，我們會考慮直接把它
作為模板
而不是創建成組件。
以上是百度搜索設計團隊在設計組件庫升級過程中的心得分享，包括搜索業務對于“好的設計組件”的訴求，以及一些搭建和優化組件的實用思路，核心是探討如何從組件庫建設的角度入手，成功助力團隊提升設計資產消費效率。
當前我們已經完成設計資產工程化的前序環節，我們對設計資產的升級和探索并沒有結束，未來我們將持續探索設計系統工具化的形態、與AI大模型結合的機會，通過豐富消費途徑，實現在業務交付的不同階段下全方位提效。這部分內容后續有機會也將會和大家見面，請大家期待！
感謝閱讀，以上內容均由百度MEUX團隊原創設計，以及百度MEUX版權所有，轉載請注明出處，違者必究，謝謝您的合作。申請轉載授權后臺回復【轉載】。
作者：百度MEUX鏈接：https://www.zcool.com.cn/article/ZMTY1MTYwOA==.html來源：站酷著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
