5000字干貨！如何快速完成B端設計規范落地？

一、B端設計規范的內容整理

不同項目的 UI 的設計規范雖然看起來都很像，但因為項目需求、設計差異，不可能一模一樣。所以雖然網上有很多規范案例，但新手很難直接照搬。所以我們首先要解決的問題是規范里有什么，如何應地制宜展開規劃，輸出符合項目實際情況的規范內容。

簡單解釋，在 B 端設計規范中，主要包含三個核心模塊，分別是：布局、樣式、組件庫，下面分別對它們進行說明。

1. 布局部分

即 B 端界面的主要框架、版式信息，比如使用了哪種響應式模式、柵格規格，還有全局組件導航欄、信息欄、內容區域的布局模式，以及浮層抽屜、通知窗口等元素的顯示方法，最后還有很多人會忽略的間距參數的應用。

布局部分的規范決定了整個項目的基礎版式和交互路徑，雖然內容不多，但卻是整個設計規范中最復雜也最難完整落地的部分，需要設計師具備扎實的基礎理論知識和一定的項目經驗。

2. 樣式部分

樣式通常指界面最基礎的視覺細節，UI 中最基礎的樣式內容就包含色彩、字體、圖標這三個大類。如果項目風格化強一點，那就還可以整理一些額外的內容，如投影、透明度、漸變、毛玻璃效果的具體參數和使用細節等。

樣式是規范整理中最簡單的部分，只有在字體整理上存在一定的認知歧義，需要設計師花比較多的時間去理清楚具體的參數和規則。只要樣式規范能整理并設置好，那么就可以快速應用到后續的項目設計中去。

3. 組件庫部分

組件庫就是項目中使用的控件、組件元素的合集，比如按鈕、開關、下拉菜單、導航欄等。我們需要把項目會用到的這些內容整理出來，并羅列它們的不同場景和狀態樣式。

不同項目中會用到的控件和組件不同，且同一個控件也會使用不同的設計樣式，所以每個項目的組件庫都是獨立的難以復用。

組件規范整理本身并不困難，但新手主要遇到的矛盾是如何對組件進行歸類，畢竟每個項目都會包含數十種控件、組件應用，如果沒有分類形式就會導致后續使用的混亂。

所以我們根據 Ant、TD、Arco 來簡單總結下 B 端組件庫的分類：

其中 “布局” 主要包含柵格、間距、彈性布局等內容，在開發語境中，它們也是代碼組件化的一部分，但在我們現在的語境里，它們是前面布局的內容而不是可視的組件元素，所以先忽略它。

下面分別解釋以下其它幾個分類主要包含哪些要素：

通用/基礎：主要是按鈕、鏈接兩個組成網頁的最基本交互元素

導航：包含導航菜單、分頁工具、步驟、錨點等，用于表示所處位置、狀態的控組件

數據輸入：包含輸入框、單選、多選、下拉選擇等用戶錄入數據的控組件

數據展示：包含頭像、徽標、日歷、卡片、表格等展示數據信息的控組件

反饋/消息：包含警告、提示、消息、引導等用于提示用戶的控組件

其它：一些難以歸類的組件類型

在我們項目中應用的大多數控件和組件，都可以根據這個通用的分類來整理。如果其中一些特定的組件內容、樣式非常多，也可以做成一個獨立的組件分類，比如表格這樣的組件。

有的項目會包含多種表格的類型和樣式，加上表格本身復雜的交互和狀態表現，需要有非常多的篇幅進行整理和展示，所以做成一個獨立的分類也是合理的。

再者，如果項目有一些比較特殊的業務模塊，比如自定義頁面、流程編輯、設備管理之類的，應用了一系列特殊的控件和組件，那么也可以根據這個模塊類型命名創建一個新的分類。

最后，組件庫還有個特殊的類型 —— 圖表庫。之所以前面沒有列舉，是因為常規項目極少會自定義圖表組件，都是調用第三方圖表庫生成的（Echart之類的），在這種情況下如果要輸出規范，就只能制定圖表的用色邏輯。

如果是完全自動圖表，那么就可以作為一個單獨的分類，每個圖表類型如折線、柱狀、扇形等再逐一進行整理和解釋。

以上就是 B 端設計規范中會包含的主要內容，下面我們就來分享如何進行具體的整理。

二、B端布局規范整理

布局是構成界面視覺框架的基本要素，包含頁面布局、柵格/響應式、浮層、間距四個部分的應用規則。

1. 頁面布局規范

頁面布局就是頁面的主要模塊排布，包括導航欄、菜單欄、內容區域三個核心模塊，還有頁腳、抽屜、頁簽欄（如果有做的話）等。

在我們自己的項目，就是把頁面的標準布局剝離出來示意，如下面的案例。

部分復雜的項目可能會在不同的模塊、頁面中使用不同的布局形式，這些布局自然也要整理，但這和開源框架中提供多種布局形式有本質不同，它們只是先把選擇提供出來用戶自己選擇，而我們的整理的是項目必須要用的類型。

2. 柵格/響應式規范

B 端項目往往會應用響應式布局，來支持不同規格的屏幕和瀏覽器窗口縮放。但和一般企業官網所使用的完整響應式規則不同的是，B 端通常應用的是響應式的 —— 簡化（閹割）版。

比如基本不會去適配平板、手機的尺寸，也不會支持太多斷點（BreakPoint）和多種布局，僅僅是讓內容區域可以根據屏幕寬度拉伸而已，比如下面案例：

在這種情況下，響應式的柵格系統也就變成擺設，用它作為寬度單位的意義已經不存在了（需要了解響應式的基礎知識）。

之所以這么簡陋是因為響應式開發涉及的開發量過大，收益卻不高。設計師需要先和前端開發商議后再做規范的定義，確定開發用柵格了再定義柵格的系統，如果不做就只確定最關鍵的幾個規則并做出示意。

包含：

1. 最小寬度：頁面支持的最小瀏覽器視圖寬，低于這個寬度不再適配
2. 響應模塊：會產生寬度適配效果的模塊，側邊導航通常不跟隨頁面寬度變化
3. 斷點支持：是否添加特定的斷點值，實現導航欄或其它側邊欄的隱藏。

3. 浮層應用規范

浮層指的是項目中各類懸浮控件、組件，包括提示框、通知、氣泡、抽屜、展開菜單等等，具體可以看我之前分享的浮層解析。

浮層規范要做的并不是直接開始整理并解釋這些視覺組件，而是確認它們的應用、布局邏輯，以及在模態環境下，背景遮罩層的規格。

簡單整理起來可以如下圖所示：

浮層一多，下一個問題就是層級，這些浮層共同出現時的疊加關系，所以還要簡單梳理 Z 軸的層級邏輯。具體的邏輯就不在這里展開，大家可以看上面分享的浮層。

4. 間距規范

間距是組成布局的重要依據，而我們要整理的就是項目中要準備應用哪些間距的規格。雖然下意識我們會選擇 4 的倍數間距，但這要看實際應用效果，必須以有效的設計稿為依據做整理，并明確規定幾個常見的間距應用數值。

這些間距場景包含：內容區域外邊距、模塊外邊距、模塊內邊距、標題副標題間距、圖標文字間距等。可以通過一兩個個有代表性的設計稿做標注來表示。

三、樣式規范的整理

樣式規范包含色彩、字體、圖標、風格四個組成部分，是最容易理解和整理的規范，但做好并應用起來卻不容易。

1. 色彩規范

色彩規范主要整理項目的主色、輔助色、中性色，對應的概念就不需要多做解釋了。要注意主色只能有一個，而不能將多個顏色作為主色。而輔助色除了品牌色外，主要包含功能性用色，比如警示、錯誤、正確等色彩應用，一些視覺化的運營圖、插畫、圖標用色是不需要作為輔助色整理進去的。

除了純色，漸變也可以做出對應的整理，包括固定的漸變色，或使用漸變的色彩過度規則、漸變角度定義等。

2. 字體規范

字體規是規范中最難定義的部分，常規情況下我們可以根據文字的應用場景將它們劃分成標題、正文、注釋、數字/英文等四個大類，每個大類下包含若干的具體樣式規格。

字體涉及的規范主要包含：字體類型、字號、字重、行高、字色等屬性，每一個字體樣式都具體定義了這些屬性值。因為前面定義過色彩規范，所以字色需要匹配色彩規范和命名，而不是給一套的新的十六進制色值。

另一個問題就是行高的定義，一般文本行高都用默認即可，但如果出現了大段文本的場景（比如文章），那么就要增加正文行高來提升可讀性，這種情況下就等于出現了兩種字體樣式，而不是一個字體樣式包含兩種行高。同時，大段文本的應用還要關注一個額外的文字屬性 —— 段間距，只需要在這類字體樣式上設置即可。

3. 圖標規范

圖標規范主要整理的是圖標的尺寸和樣式規格。

在一個項目中，最完美的圖標應用場景就是只定義一套風格一致的工具圖標，應用到項目的各個頁面和組件中去。

但有相當一部分項目需要設計多種風格的圖標，以提升視覺效果和滿足不同的應用場景，這就需要我們將這些圖標的規格整理出來，同時也需要將設計好的圖標置入到規范中，成為后續設計的引用元素。

4. 風格規范

風格規范就是視覺風格性要素的整理，包括圓角、投影、模糊、描邊等樣式的應用。只需要將用過的案例整理進來，并標注對應的參數即可。

四、組件庫的整理

組件庫即放置項目涉及的不同控件、組件元素，在初期我們可以根據前面總結的基礎、導航、輸入、展示、反饋、其它六個大類做區分，每個大類先創建一個獨立的畫布，將元素置入進去。

組件庫和樣式不同的是，里面的元素是可交互的，也就意味著它們會有不同的狀態用于反饋和示意。所以每個一個控、組件都要做出它們的不同交互狀態下的樣式。

比如按鈕會包含默認、懸浮、點擊、不可點，輸入框包含默認、懸浮、待輸入、輸入中、已輸入、不可用等狀態。這些交互狀態是開發中必不可少的部分，但我們無法直接在界面設計稿中完成，所以要在置入規范畫布后單獨對它們進行設計和展示。

而一些復雜的組件，比如表格、編輯器、圖表等，去表現它不同狀態是不可取的，因為它們包含了大量的視覺和交互細節，每個操作都畫個表格肯定是畫不完的。所以只需要表現幾個關鍵的狀態，然后將大組件拆分成若干小組件或控件進行獨立表示。

這些組件的整理方式 Ant、TD、Arco 等第三方框架都已經做的非常完善了，只要找規范的源文件（官網都有）并參考它們的做法即可。

理論上，設計界面的過程中，只要設計了新的控件或組件，將它們整理進畫布中再做出不同的狀態，就可以完成組件庫的創建。但這種做法的缺點是界面和組件的整理過程各做各的，處于割裂的狀態，很容易導致組件之間的樣式不夠統一。

所以我們在整理規范庫的時候，要有目的性的去建立組件之間的聯系，并盡可能的在組件庫整理的過程中反向提升設計的質量。下面分享一些相關的經驗和技巧。

比如按鈕和輸入框、選擇器等都是矩形元素，很多場景下都會并列需要使用相同的高度，所以我們可以在定義完按鈕以后去統一類似控件的高度。

并且按鈕也有不同的高度規格，這些高度可以繼承到其它控件或者細節中，比如步進器、通知欄、頭像、表格的表頭、步驟條等。

再上一級，比按鈕更大的矩形元素則是行類元素，比如菜單欄、表格行、列表行、模塊標題欄等，也可以將高度固定成少數幾個尺寸。

同理，圓形的控件也可以使用類似的思路統一，比如單選控件、滑動輸入、開關、徽標、輪播指示器等。

盡量先把常用基礎控件整理完，再去創建復雜的組件，因為復雜的組件都是由這些基礎元素組成，前期基礎元素整理的越完善，這些復雜組件的設計就會越容易。

總結起來，想有效的整理組件庫，就是先從按鈕作為整理起點，再拓展至所有矩形類控件的定義，然后定義圓形類控件。整理完常見基礎控件以后，再慢慢整理復雜的組件，直至將所有組件整理完畢。

同時，作為項目自用的組件庫，不建議花大量的時間去折騰軟件內的變體和處理規范展示本身的布局，這會耗費大量的時間，而且不會對后續設計效率產生多少正面影響（甚至是負面的）。

在這個整理過程并沒有什么技術難度，考驗的是大家的耐心和對細節的重視度。

下面是整理的：

結尾

以上就是基于普通項目創建 B 端項目規范的分享，雖然我沒有太花篇幅演示規范具體應該設計成什么樣，但它們并不重要，只要思路是正確的你們可以隨意發揮。

如果有別的疑問，就可以在我們自己的社群里提出來，今天就分享到這里。

我們下篇再賤~

歡迎關注作者的微信公眾號：「超人的電話亭」