B端設計規范搭建，有了嫻熟的軟件基礎，理解并使用設計規范應用邏輯并不難。本文詳細介紹了從0開始進行B端設計規范搭建的思路和步驟，幫助設計師從理解項目環節到完成設計規范搭建，希望對關注B端設計的你有所幫助。

設計規范的應用邏輯很簡單，但需要有非常嫻熟的軟件功能使用基礎，所以之前花了很長的篇幅講解了和規范相關的軟件功能應用，就是為了現在這篇做準備。

下面開始正文：

一、項目規范的整理準備

1.項目規范的制作流程

項目設計規范的制作是一個 “龐大” 的工程，不是設計師依靠直覺平推就能做好的。所以需要先了解必要的環節，根據自己項目的實際情況做調整，再開始執行。

基礎項目設計規范的完整流程，大致包含下面這些步驟：

1. 構思項目的視覺方向和風格樣式
2. 對主要頁面進行具體的視覺設計和定稿
3. 進行規范內容的具體分析和規劃
4. 梳理全局框架和交互規范
5. 整理基礎視覺樣式規范
6. 整理控件和組件規范
7. 規范內容評審團隊對齊
8. 規范文件整理和導出應用
9. 后續的更新和維護

很多人錯誤的把開始使用設計軟件生成具體的樣式和組件當成設計規范的起點，這是非常錯誤的想法，那已經是中后期的工作了。

一套專業有效的規范，不可能憑空制定出來，必然要包含前期的準備、分析、測試和評審，最終定義出來的規范細節只是對前面設計工作的 “總結&補充”，而不是再造出新的內容出來。

所以，前期的工作步驟非常重要。首先就是在獲取產品原型、需求以后，根據項目的實際情況去構思設計的風格了。換句話說，就是要構建你項目的情緒版，是要設計得比較政務國企風，還是商務穩重、科技多元。雖然 B 端項目的視覺并不像 C 端設計這樣差異巨大，但依舊是得做出選擇的。

初期情緒版的制定只是設計意圖，所以我們需要通過部分頁面的設計來落實。

尤其是在前期可能拓展了多個設計方案的情況下，更需要通過輸出多套飛機稿 Demo 的方式來選擇最合適的一版。所以這個階段需要輸出的頁面數量不用多，只要能評估頁面視覺風格的3-5 個關鍵頁面即可。只有視覺方案在團隊內部定稿，我們后面的工作才是具有確定性的。

因為規范可以做的東西實在太多，但每個項目的實際需要又不一樣，而且留給我們制定規范的時間也不一樣，使用的環境也有區別，所以我們需要在前期制定規范的層級結構和內容列表。這約等于制定一個項目的待辦清單，讓我們可以更好的控制進度和輸出質量，這在下一小節就會展開解釋。

完成上面兩步，才到了具體使用設計軟件進行規范制作的過程。也就是創建視覺樣式，制作組件庫的環節，這是要耗費精力最多，花費時間最長的步驟。但和你們想的不一樣的是，這恰恰是整個流程里最簡單的一步。因為樣式、組件的整理方法是死的，但怎么落地、應用、維護規范卻是活的，非?？简炘O計師的團隊協作能力和項目經驗。

我不會建議大家一口氣就把所有規范內容全部做完，而是先把每個模塊的內容制定一部分以后，就進行規范的內部評審。主要評審規范的展示形式、引用方法、制作規范，統一設計團隊內部的意見和引用，以及和開發協商如何有效進行組件化快發，保障規范在實際開發過程中被有效利用。只有這些條件都滿足以后，再完成后續的所有內容制作與輸出。

不要一廂情愿認為只要做了設計規范出來，其他人就一定會配合你的工作。沒有經過團隊內部評審交換意見后輸出的規范，只是強加給其他團隊成員的 “枷鎖“，無法成為他們日常工作中的 “標準“。

2. 項目規范的整理準備

從構思情緒版到設計定稿，我就不在這里開展。從風格定稿以后，我們就要進行制作規范準備工作了。需要花至少半天以上的時間進行分析，應該做一套什么樣的項目設計規范出來。

簡單來講，就是給自己提出幾個關鍵的問題，并給出對應的分析結果。比如：

• 你有多少時間來整理這套規范？
• 使用第三方庫還要定哪些規范？
• 規范主要的應用場景在哪里？
• 規范的載體用哪種形式？
• 項目的前端配合程度有多高？
• 有哪些控件組件要做規范？
• ……

具體要提出哪些問題是開放性的，因為每個項目擺在我們面前的阻力是不一樣的，分析的側重自然也不一樣。

就比如時間這一條，如果留給我的時間特別短，以及除非我想無償為企業做奉獻，那么必然會考慮怎么降低規范的制作規格，刪減不必要的細節，思考最低配輸出的底線是什么。

再比如應用場景，有的項目設計規范不管我們接不接受，確實就是擺設。給領導看的、給投資人看的、給甲方加錢的，它最后就沒有落地的條件。那自然做樣子也就有做樣子的玩法……

不同分析的結果對后面的工作內容影響是巨大的，所以考慮得越全面越好。然后就要根據分析的結果，使用思維導圖工具來梳理規范中要包含的內容，整理的順序遵循由上而下，從宏觀到微觀。

上面是個簡單的示例，例舉了規范中常見的一些模塊內容，前面的框架、樣式規范內容比較穩定，所有項目基本都會包含，工作量也小。而組件庫的內容就非常靈活了，需要你們自己根據項目的情況去制定。

比如，Ant 這類開源的組件庫里包含了大量的組件，有相當一部分組件在我們的項目中壓根不會出現，所以就不用考慮它們。也因此，每個項目的組件庫都是獨一無二的，你需要根據產品的原型來判斷會應用，以及需要整理出來的組件。

這個目錄就是你制作規范的任務清單，雖然第一版還可能有缺漏，但只要大框架有了，后面再在實際的設計推進中進行補充即可，我們就可以開始具體的設計規范制定了。

二、規范中的原則制定

設計規范整理的第一步，就是明確 —— 設計原則。用互聯網一點的話術，也叫 “設計價值觀”。

So，啥事沒干就開始上價值觀整活了？

理論上，優秀的系統必然會包含某些固定的內核，比如企業文化、小說宗旨、宗教思想……整個系統的表象和細節都是受這些內核影響延伸出來的。比如包豪斯學派的設計，是以實用性為核心主旨進行實踐的。

所以這類設計崇尚構成主義、標準化、極簡。以這個價值觀完成的設計，是不可能做出荒誕、繁雜、浮夸、喧囂的設計的，和以消費主義為內核的波普風格是截然相反的。

藝術看起來離我們很遠，再換個例子，不同的人，不同的價值觀，就會構建他們不同的穿衣風格和氣質。對外在只希望簡單舒適和極度渴望他人注意的人，就會對不同的品牌風格感興趣，花不同的時間進行打扮，并表現出顯而易見的差異。

這些都是價值觀的作用，設計本身的價值觀也沒什么特殊的，就是反應制定者對這套規范作用的預期，也就是通過制定價值觀讓整套規范的實踐發展符合指定的方向。比如，Arco 的設計價值觀中，使用了清晰、一致、韻律、開放四個詞條，他們分別有如下的解釋：

清晰：……設計中減少不確定的因素,減少用戶判斷次數，明確信息層級導向，讓用戶操作的目的性更明確

一致：……高標準的一致的設計體系,給用戶帶來品牌信賴感同時還能夠通過一致的重復降低用戶反復學習成本

韻律：……產品使用中的韻律反應了用戶習慣,富有韻律的設計讓用戶的操作仿佛本該如此，減少理解記憶負擔

開放：……中后臺產品復雜的業務場景很難以一套固定的設計體系去涵蓋,只有開放包容的體系才能適應復雜的業務場景

可以看出，每個關鍵詞其實都指向了解決某些具體的項目問題。所以明白了嘛，項目規范的原則就是從解決問題出發，通過找出或預判項目面臨的重要問題，然后構想一個 “大概” 的解決方案，再提煉成關鍵字……

要注意，這里的價值觀關鍵字和情緒版的關鍵字不一樣，情緒版是定位視覺風格的詞匯，范圍更小更抽象，而價值觀的關鍵字更宏觀更具體（解決問題）。給規范上價值觀制定是考驗設計師本身的全局思路和遠見的，需要通過大量的項目去做積累，才能確保制定出來的內容具有說服力，不會讓其他人看著尷尬……

雖然沒有輸出它也不會直接影響規范在項目中的作用，但建議新人從第一次接觸開始就可以做嘗試，慢慢去過體會其中的區別。

三、框架布局規范的制定

1. 全局框架版式的制定

除了價值觀外，規范中層級最高的東西，就是全局框架了。在前面的分享中我們已經解釋過它是什么了：

全局框架：項目的主要模塊排版和布局，產品使用的主要依據和步驟

全局框架的制定確定了整個產品的基本交互形式，它既是交互的要素，也直接影響界面的設計框架。主要制定的內容包含下面幾個要素：

• 主要頁面布局
• 不同類型頁面
• 全局組件應用

（1）主要頁面布局

決定頁面的核心組件布局和交互方式，包含導航欄、工具欄、菜單欄、內容區域等絕大多數頁面都會出現的組件。

比如下面案例就使用了完全不同的布局結構：

但是，項目中往往會出現一些非常規性的頁面，比如演示、會員付費、官方活動頁等，我們也要在這個階段中盡量考慮進去，描述包含哪些特殊的布局，應用到哪些場景。

（2）不同類型頁面

然后進行細化，解釋幾種常用頁面類型的應用和設計方向，包含展示類型和頁面類型。展示類型就是頁面的展示載體，如獨立頁面、彈窗、抽屜形式。

頁面類型是頁面的功能類型，比如常見的表盤頁、列表頁、表單頁、詳情頁等等，同類頁面雖然在不同業務場景會有不同的字段，但它們會包含結構上的共性，是可以在前期進行整理提煉的。

比如表盤頁，統一采取卡片模塊拼接的模式。表格頁面，統一篩選模塊和表格模塊的布局位置。包擴業務特有的一些頁面，也可以進行整理，提升后續設計的統一性和效率。

（3）全局組件應用

最后，就是除了基本框架外的全局組件應用規則，例如全局提示彈窗、消息窗口、固釘等元素。雖然在 Ant、Tdesign 等開源框架是在組件章節才去解釋這些組件，但這和全局組件說明還是有差異的。

在我們自己的項目中，要在全局類別下完成對它們的布局說明。例如，包含幾種通知類型，窗口對應出現的位置，觸發的條件?；蛘?Saas 的客服&幫助固釘，要懸浮固釘在頁面的哪個地方，受不受其他模態遮罩影響等。

這些元素對后續的界面都會有一定的影響，所以需要我們提前進行解釋。同時，這些解釋并不是深入到組件本身的說明上，僅僅是描述它們 “全局下的應用”。具體的組件本身的設計、狀態、交互細節都可以在后面的組件部分進行說明。

2. 柵格響應規范的制定

可能有人會認為柵格才應該是框架規范中的第一步，這也是誤解。

因為——柵格是為框架服務的，而不是框架根據柵格來制定。

比如常見的導航欄位于左側的設計，導航本身是排除到柵格區域外的。如果應用了可以展開的雙列導航，那么柵格的區域還會被壓縮。這在我們過去的 B 端柵格介紹中也有提及。

即使使用了 Ant 等開源框架的柵格系統，我們也要做柵格的規范制定。因為官方只是提供了一套自定義柵格工具，并對它的開發使用做出說明。

這對于我們項目設計來講等于什么都沒說，所以需要我們進一步確認柵格中運用的參數，并在規范中進行確認，保證開發和后續的頁面使用固定的參數完成。要重點關注參數如下：

• 列數 Column：柵格總共使用的列數，常見 12、16、24列
• 間距 Gutter：柵格格線之間設置的間距數值，一般為 8-16px
• 間距 Margin：整個柵格區域兩側的預留外邊距
• 空間 Space：柵格作用的區域，如前面不包含側邊導航或右側展開面板等
• 范圍 min-max：柵格支持的最小寬度和最大寬度區間

這幾個參數是柵格系統中最重要的說明，其它的細節如列的兩側邊緣添不添加間距、Flex 流動，都可以另外和開發商量。很多 B 端設計師會錯誤的把列寬 Column Width 數值標注進去，這就代表他們依舊沒有理解柵格是什么。列寬根據頁面寬和上方參數被計算出來，它是個 “變量”，沒有固定的寬度值，它是響應式中模塊布局寬度變化的參照對象。

3. 間距數值應用

布局還有個不是太起眼，但是非常重要的地方，就是間距的應用。包含模塊間距、標簽列表間距、模塊內間距、按鈕內間距等等。間距的應用是構成整個頁面穩定性的核心要素之一（另一個是對齊），要盡可能將整個項目的間距控制在幾個固定的間距數值之中。比如 TDesign 中的間距制定：

對于我們自己的項目，間距的數值不需要和它們完全一致，但是只像它一樣列幾個參數顯然也太蒼白了。所以需要對每個間距數值的應用給出一定的示例，確保內部對間距應用思路保持一致。

4. 軸層級關系制定

全局的最后一個模塊，就是針對 Z 軸層級進行制定。它用來表示頁面中元素的上下順序和疊加關系，類似設計軟件中圖層的順序。

要確定的內容除了上方這種固定的 Z 軸順序以外，還包含活動的層級，在原有圖層上 +1 級的高度。如：

• 下拉菜單
• 文字氣泡
• 操作氣泡

除了在后續設計中讓我們直接進行覆蓋以外，Z 軸作為一種空間關系，被越來越多的設計規范結合到投影的使用上。比如 Android Material Design 2 中，不同 Z 軸高使用不同的投影參數。

如果項目中要應用投影，就可以把它關聯到 Z 軸的應用中，給對應層級分配固定的投影類型，保證空間感的一致。以上就是關于全局框架中需要記錄內容的解釋了，具體的描述文案、內容，可以參照 Ant、TDesign、Arco 的相關說明，并自行優化。

四、基本樣式規范制定

1. 色彩規范的制定

進入樣式的規范制定中，首先就圍繞顏色展開。顏色規范主要關注幾個固定的色彩類型，并通過一個畫布進行記錄和展示。

• 主色：項目的主要用色，以及主色的相關變體
• 輔助色：用來配合主色提升項目內容辨識度和權重的色彩
• 中性色：項目中黑白灰的不同灰度值應用
• 遮罩：相關遮罩層的色彩和透明度設置
• 漸變：應用漸變色的相關角度、漸變跨度或固定漸變值

這里我要提個和大多數網上色彩規范分享不同的觀點，就是一個項目里，色彩應用數量是越少越好的。99% 的項目壓根不需要制定完整的多色相衍生色板。

這在實際設計和開發環境下就是純粹的負擔，因為我們每次選色都面臨著大量的選擇對象。而且這種情況還需要我們處理對應的 Color Token 命名，和開發對齊規則應用方式，投入是遠遠低于產出的。

如果想要實現類似按鈕懸浮、點擊之類的不同狀態的顏色調整，就可以通過黑色、白色遮罩的應用來關聯不同交互行為。

要是項目確定使用了某套開源框架，且沒有固定的品牌色。那么就建議所有顏色都從官方的色卡選色，然后在色彩示例種備注對應的顏色名稱（不是 Token）即可。比如使用上方的色彩規范展示案例，直接替換成 TDesign 色卡中應用的色彩和名稱：

2. 字體規范的制定

色彩之后，就是字體的規范了。同樣，我們字體規范就是從完成界面中整理出對應的字體規格，包含標題、正文、注釋三個大類，以及特殊的英文、數字等類型。每個類型要反應字體、字號、字重、行高這幾個核心參數。因為設計軟件中可以直接查看，所以今天我們在處理規范的時候往往在畫布上把字體放上去就可以，往往不用獨立標注。

其中，主要字體定義通常不會只有一個，會包含多個字體選項，根據打開網頁的系統環境進行匹配。所以，我們要篩選出對應的字體范圍進行說明。字體和色彩類似，規格數量一樣是越少越好，多了即不能提升實際的效果，還會拖累項目效率。

3. 圖標規范的制定

在項目中圖標也是基本的組成要素，我們過去關于圖標的分享做了不少了，相信大家都知道圖標本身是具有一定繪制規范的。雖然 Ant 它們都有一些自帶的圖標柵格系統，但即使我們應用了它們提供的圖標苦，這些柵格對于我們來講也毫無意義。

因為那是他們畫圖標的標準，關我們的規范什么事……首先我們要明確項目中不可能只使用完全相同參數的圖標，最起碼在尺寸上會有不同，所以項目里就必然包含多套圖標。

所以即使我們用了類似 iconpark 的圖標庫，依舊要做幾個關鍵的規范要制定的，比如圖標的尺寸，對應的粗細設置等。

如果沒有用圖標庫，完全由自己設計，那么就需要提供更豐富的規范內容了。尤其是盡量包含不同規格下的柵格模版，因為柵格的制定在不同尺寸下是會有不同細節調整的。

4. 圓角模糊等細節制定

樣式中最后一步，就是視覺細節的總結了，包括圓角、背景模糊、線段、圖形比例等。我們需要總結在項目設計中運用到的可以總結出來的細節特征，并加以記錄和統一，防止在后續的設計中不斷膨脹出新的規格。

這些細節是構成界面樣式豐富性的主要因素，也是最容易破壞項目視覺統一性的東西。比如圓角的設置，一些初級 B 端設計師輸出的項目，就可以包含無數種規格，且圓角的大小并沒有清晰的使用邏輯，這是嚴重降低設計質量的表現（當然也是能力問題）。

我們在歸納細節的時候就是防止不同設計師（尤其是剛入門的新人），在后續設計中放飛自我。每個項目都會有不同的細節內容和特征，就需要設計師自己去思考和總結出來了。

以上就是關于視覺部分樣式的說明，每個類型可以在軟件中制作一個獨立的畫板，并放置對應示例，并且只需要針對軟件面板中無法反應的規則做注釋說明，不要事無巨細把所有參數備注都寫出來。以及可以添加到軟件樣式表中的，也在這個階段中完成，然后再開始整理后續的組件庫，確保組件庫中的屬性已經完全關聯到對應樣式上。

五、組件和控件規范制定

1. 控件和組件規范記錄的標準

再強調一遍名詞的概念，控件在這邊指基礎的交互元素和單位，組件指包含復合操作的業務模塊，雖然本質上它們都是 “組件 Compoent/Symbol/Kits”，但因為復雜度不同，在規范的制作上自然會有一定的差異，這會再后面具體提及。

它們反而是整套設計規范中最簡單的部分，因為 Ant 等框架對于組件的說明和展示也已經足夠完善，都是現成的參考案例。所以，我不打算像其他人分享的內容一樣，逐一具體控件和組件進行簡單介紹。

制作組件庫和規范的主要難點，在我看來是怎么讓它們可以高效的被利用起來，所以這需要一個清晰的內容索引機制。

Ant 等主流組件庫，如果有引用過它們組件庫直接做設計的同學應該都會發現非常痛苦，不僅僅只是使用了各種編組和自動布局的關系，還包含想要找到自己想要的組件得找很久。原因就是因為這些組件庫不是他們團隊真實的項目庫，只是 KPI 和任務。所以并不會太多考慮實際應用難上的困難，直接使用英文排序來羅列組件，或者沒有任何規則。

比如下圖是 Ant 在即時中的組件存放面板（內容應該不完整…），一個大分類下堆滿了不同的組件，查找起來非常的低效。

所以針對我們自己的項目，就不能照搬這種模式。要充分利用軟件的頁面 Page、畫板 Artboard、鏈接 Link 功能來完成組件的索引和存放。首先再回到前面準備工作中的思維導圖，我們通過思維導圖記錄了一些會出現的組件內容，這里我們要進一步分類。

每個二級分類對應軟件中的頁面 Page，三級分類對應畫板 Artboard，四級分類對應畫板中存放的組件內容。整體遵循分類和層級清晰的原則，避免在同一畫板中堆砌沒有關聯性的組件，同時針對一份完整規范的要求，還要在前面添加引導頁 Guide Page，樣式頁 Style Page 即可。

完成結構的創建以后，后面的組件內容擺放就根據這個目錄來完成，雖然這個思維導圖大綱還是第一版，必然是不完善的。但只要前期這個框架形成體系，那么后面添加的內容自然會根據這個結構來補充。每個畫板下方內容怎么放，會在后面的兩個小節做解釋。

這里重點說下第一個引導頁面 Guide page，它作為打開規范看到的第一個頁面，是要承載一些必要的信息的，比如設計的原則、規范的使用說明、版本的更新之類的解釋。

一定要牢記 “必要信息” 這個關鍵詞，不是鼓勵你們在首頁寫幾萬字的內容進行自我感動，而是在一個畫板內用最精簡的文字把該放的信息放進去即可。比如以 Arco 的說明作為參照，大概就是這樣：

除此以外，首頁還有個最重要的功能，就是 “內容目錄”。一個有效的索引機制可不僅僅是讓我們手動查找，而是會創建一個用來快速跳轉的內容明細目錄。

原理就是可以選中畫板、圖層右鍵復制它的鏈接，然后再在對應圖層中添加這個鏈接，就可以讓這個圖層成為跳轉到剛才元素位置的按鈕。

理解原理，之后就是創建目錄了。我們依舊可以使用自動布局的功能，并根據剛才的結構劃分，快速創建出一個可以自由調節并支持跳轉的目錄出來，比如下面的這樣的案例：

在這個引導頁中，目錄是權重更高的模塊，因為其它信息一般看一兩次就夠了，沒有特別的事情不會再看它，而目錄才是每次進入這個頁面的價值所在，所以放的位置要顯眼，不要讓其它文本信息過度占據頁面的內容。

完成目錄后，就可以在左側頁面 Page 列表創建對應的組件分組，并進行下一步工作了。

2. 基礎控件規范制定要點

基礎控件因為太簡單，所以不需要用太多的文字內容做解釋，單個解釋面板下包含的內容只需要有：

• 標題簡介：簡單描述這個控件是什么，有什么作用，最多幾十個字就夠了
• 樣式展示：把這個面板下包含的不同控件類型先統一展示一遍，然后使用簡單的文字備注
• 狀態展示：把每個類型控件會出現的狀態羅列出來，對需要備注的地方進行說明

一定要牢記，自己的項目和線上的開源框架解釋是不同的，內容不要太含糊。就比如上面的按鈕，我在項目中使用過幾個不同的高度和類型，那我一定會把它們都列出來，而不是簡單放一個樣式和狀態就結束。

因為規格不同，就肯定沒辦法用一個按鈕的變體組件來完成項目的全部按鈕設計，所以肯定要生成多個組件和變體。然后在狀態展示的部分，就可以直接將變體放進去，并且給出對應的注釋即可。

3. 進階組件規范制定要點

組件比控件復雜，復雜不只是視覺而已，而是更復雜的交互和業務邏輯，既然我們梳理規范了，那自然應該把重要的交互解釋放進來。當然，組件也分一般的基礎組件和復雜的業務組件?；A組件如下拉菜單等沒有交互說明必要的和控件的做法別無二致，麻煩的是復雜的業務組件記錄和說明。且因為業務組件的特殊性，盡量在一個畫板中只展示一個組件，而不是硬湊到一起去。復雜的業務組件的面板應該包含的內容如下：

• 標題簡介：簡單描述組件是什么，以及對應的用途
• 樣式展示：展示同一組件的主要狀態和樣式
• 交互說明：對組件的交互創建連線和基本說明

這里還延伸出一個問題，就是關于項目交互文檔的問題。在我們前面發過的分享中有專門解釋，一套完整的交互文檔會囊括非常全面的內容和信息，但是正常的項目中，交互文檔一般只對應一個版本和迭代，很難去維護一份總的交互文檔，來反應項目中最新的交互內容。

所以，在組件庫整理中，每次把交互的信息整理進去，是最簡單、有效的處理方式，不僅組件本身的各個狀態樣式能反映出來，交互的信息也不用到別的文檔查看，減少了文檔維護的壓力。只要了解了這幾個核心的要點，那么整理整套組件庫就只是時間問題了。最后還要重復那句話，文檔格式是死的，人是活的。

我們要根據前期對項目環境的分析，來決定規范應該做到什么程度，該寫哪些說明。不要在沒有充分考慮的情況下，把我例舉的案例直接作為標準在項目中實踐，很可能因為內容太多而最終放棄。所以，盡量先從最精簡的模式展開，先完成基本的框架搭建和樣式圖層置入。確保組件庫能滿足最基本使用需求后，再考慮逐漸優化豐富相關信息。

六、規范的評審和分享

1. 規范的內部評審會議

完成版本相關的規范以后，就一定要在內部召開一次規范的評審會議，來統一相關成員的認識。如果團隊成員對規范還有意見，認為有需要修改的地方，就要進行協商并做進一步優化。評審要解決以下三個領域的問題：

• 產品/交互
• UI 設計師
• 開發/測試

（1）產品/交互

第一，讓產品經理和交互設計師了解規范中的內容有哪些，對應的結構和目錄，以及文件存放的位置，如何打開進行查看、引用。因為設計規范只要整理了，就絕對不是局限在視覺樣式上，必然會包含了框架、交互的內容，在后續的版本迭代中產品和交互都要遵守。

比如提示和彈窗，產品和交互設計師都不能在后面的原型中隨心所欲的設計，想放哪放哪，必然是要根據設計規范來處理。如果一定要和原規范內容不同（規范不適用新場景），那這就是一個新的產品需求，是要添加到版本迭代的條目里的。

同時，產品或者交互在完成一些新頁面原型的時候，如果頁面本身很簡單，也是可以直接使用規范中的內容直接拼裝高保真原型出來的，可以大大提升他們的原型有效性，而不是還在產出一些風馬不相及的簡陋原型，降低我們的工作壓力……

（2）UI 設計師

第二，就是設計團隊內部的對齊了。如果你們團隊人少，都參與了規范的搭建這步可以略過，但如果團隊人多，部分設計師壓根不知道你做了什么，那就絕對不能忽略。

我們需要和他們講解規范文件所在的位置，引用樣式和組件庫的方法，以及如何進行維護和迭代的說明。確保設計規范可以在設計團隊中正常的流通和應用，而不是完全變成自嗨。

因為設計規范的應用必然會和不同設計師原有工作方式有沖突，所以一方面我們要征求他們意見優化，另一方面就是需要強制推行的（職場問題），需要一開始就有部門的領導或者項目負責人發聲表態，并全力支持規范的執行，不然規范的結果嘛……

（3）開發/測試

規范的應用，必然和前端有非常大的關聯，需要他們在這個階段理解規范的內容，以及思考模塊化開發的可能性和阻力，并給出優化建議。

如果前端沒在評審階段對我們制作規范的工作表示認可，那基本后面也不會照著規范的內容做開發，這同樣需要有外部的不可抗力來強制他們執行規范。除了開發外，測試工程師也肯定要知道規范的內容，這可以讓他們在測試階段共同發現設計的問題，而不是只讓設計師做程序還原度檢測。

這三個部分意見都統一了，這套規范才脫離自嗨的范疇，具備真正的生命力。

2. 規范文件的應用思路

最后，就是規范文件本身的注意要點了。我們前面講過，規范直接使用設計軟件中的文件作為載體，在里面放置樣式、組件并添加文字說明，然后進行發布，就可以從別的文件引用它了。

常規的項目設計，會拆分成不同的模塊或流程，每個用一個獨立的設計文件。所以這種好處就是即保證文件獨立性，又支持我們在規范頁面優化內容批量修改所有引用頁面。

但這也衍生出一個新的問題，當進入新的版本以后，我們會創建新的項目文件，那么按新設計更新了規范，那么老的引用它的文件不就也受到影響了嘛？

所以，我們不能在整個項目中只引用一個規范文件。而是要在每次新的版本中，創建一個新規范文件出來作為引用對象，并且能保證每個版本的規范文件被保存下來，且讓規范的文檔編號和項目的編號持平是最好的情況，而不是獨立一個規范的版本編號出來。

滿足完這點，那么規范的變動就可以追溯，也便于長期的維護和更新。我們的整套 B 端設計規范制作的分享也就結束了。

七、結尾

一套優秀的規范輸出并落地，是規范制定者本身能力的直接反應，需要具備扎實的設計基礎，豐富的知識點，充分的項目經驗，以及職場必備的同理心和執行力。它是檢驗我們自身能力的一面鏡子，新手可以通過去構建規范來檢查自己的缺點，以及找到提升的方向。