一、定義
1.1 設計規范的概念
設計規范是指對設計的具體技術要求，是設計工作的指導規則。一般包括總體目標的技術描述、功能的技術描述、技術指標的技術描述,以及限制條件的技術描述等。
Design System 最開始是 Guide 演化而來，Guide 是一套可指導、可延續、可擴展、可統一的、可區分的視覺指引手冊，指導相關設計結構完成統一性與對外區分性。具象層，它是一種設計方法；抽象層，它是一種思考模型。
設計規范一般會具體到公司級別、某一類產品線、某個產品等。今天主要講具體某個產品的設計規范，主要是為該產品制定統一的用戶體驗、品牌、視覺等方面的規范，當然是在滿足以上公司級別和某一類產品線層次的設計規范的基礎上。
1.2 設計規范的組成
設計規范由設計原則、設計語言和組件庫構成，在設計原則的指導下使用設計語言和組件庫創建體驗一致的用戶界面。
設計原則是指：整個設計體系所要遵循的全局原則，是為我們設計提供方向指導的。
設計語言：是指設計所包含的語言體系。具體包含了：色彩、字體、圖標、布局等。
組件庫：相當于積木玩具的一個個積木，每個組件就是一塊積木，通過組件的拼搭可以迅速搭建出一個個頁面。下面我會具體說明組件庫。組件庫具體包括：按鈕、導航、表單、數據等等。
1.3 B端及C端
B端產品和C端產品制定設計規范差別還是蠻大的，最主要的差異大致是：
C端產品的設計規范：目標幾乎都是為了更好的打磨用戶體驗的一致性和標準化；
B端產品設計規范：由于用戶體驗更復雜，學習成本更高，所以它的目標側重點是：除了布局的不同外， 相同業務場景下，相同產品功能需要有一致的，標準化的體驗，降低學習成本，提高工作效率，即統一體驗。
二 、為什么要制定設計規范？
2.1 對于產品經理來說
創建原型時可直接調用組件庫，能搭建出高保真的原型。
與設計師和前端溝通更加順暢，小的修改可以直接和開發溝通不需要通過設計師出圖，極大增加了前期的節奏，提升溝通效率。
2.2 對于設計師來說
對于只有一個設計師的項目：可以讓那個設計更加規范，有些簡單功能迭代可以直接個研發溝通，不用再單獨出圖，減少重復性的工作。
對于同一個項目由多個設計師共同協作時：可保證設計各方面包含體驗、設計、交互等等的統一性。減少設計成本，提升設計及溝通效率。
對于接手新項目，能盡快的了解產品，快速入手。
對于開發完成驗收走查，有了前期的規范及比較詳細的設計尺寸，開發的設計還原度會更高，減少重復及沒必要的設計走查。
2.3 對于開發來說
開發可以按照設計規范建立好公共組件庫，極大的提升開發效率。
可復用的東西確定了下來不會頻繁改動，設計走查的問題也會逐漸減少。
2.4 對于測試來說
對于模棱兩可的交互可以有地方看交互樣式了，不需要再詢問設計師。有更多的時間專注于測試功能上的問題了。
通用的組件前期測試后了以后，后續就不需要重復測試，極大的提升工作效率，避免重復工作。
2.5 對于協作溝通來說
前期制定及評審設計規范以后，有一套筆記明確的規范，可減少各個職位方面的溝通成本，提高溝通效率。
三 .為什么要制定自己的設計規范？
目前市面上有很多多的第三方設計規范，比如：antdesign，element，那有人就會問有必要自己重復造輪子做一遍嗎？
我覺得是非常有必要的，為什么呢？
1、每個產品有各自獨有的品牌調性，如果都用第三方 的設計規范，那同質化會很嚴重，很難做到差異化，也就很難在競爭中脫穎而出。
2、 世上本沒有萬能的設計規范，那些設計規范的組件并不能100%滿足我們產品的需求。另外一方面使用封裝好的第三方設計規范，在此基礎上進行修改，效率很低，適配的復雜度和重新開發相差無幾。
3、第三方的的成熟的組件庫，我認為應該把它當成模式，在他們的基礎上去做自己的設計規范。
四 、什么階段適合設計規范？
個人工作中總結出兩個比較建議的規范建立時間點，探索期和成長期。
4.1 導入期
產品在導入階段，產品還在處于極大變動的時候，這個時候做設計規范，其中就蘊含可極大的風險。但是也不是不做規范，這階段規范主要涉及到色彩，字體，間距，布局，柵格等通用設計原則以及常用業務組件的定制。此階段搭建的規范具備高效性以及靈活性的特點。
不適合搭建特殊的業務組件，比如：當領導想要突然調轉方向也不會很慌，改動較小就可以完成整體的規范轉向）此時搭建規范組件庫需要考慮到預留后續更改的空間。
4.2 成長期
當產品進入成長期處于較為穩定的版本，整個團隊對業務的理解也都很熟悉了，這個適合創建符合業務場景的組件庫，有了前期的積累這個組件庫會更加符合產品及業務邏輯。
在制定規范前，設計師需要明確產品中主要有哪幾種分類，將最基礎的分類定義好方便后續針對分類內容進行整理。B端產品與C端產品既有共同性也有著很大的差異化，可以借鑒但是切忌生搬硬套C端的設計規范。
一、 pc端
1.1 Antdisign
Ant Design是由螞蟻集團體驗技術部經過大量的項目實踐與總結，逐步打磨出來的，基于「自然」、「確定性」、「意義感」、「生長性」四大設計價值觀，通過模塊化解決方案，降低冗余的生產成本，讓設計者專注于更好的用戶體驗，是非常完整的一套設計規范。
1.2 TDesign
TDesign是騰訊企業級設計體系，也是去年才發布的。雖然才發布，但是作為一款誕生于騰訊內部開源，卻是經過了超500項內部業務檢驗的企業級設計體系，TDesign 匯集了騰訊眾多優秀組件庫能力和設計研發經驗。
內含豐富可復用的設計組件資源，如色彩體系、文字系統、動效設計等，覆蓋支持 Axure、Sketch、Figma、Adobe XD 等各大產品設計軟件。可以按照需求查看對應組件的使用教程和代碼演示，只需簡單的引入操作，即可搭建屬于自己的產品界面。
1.3 Element
Element是由餓了么公司前端團隊開源一套為開發者、設計師和產品經理準備的基于 Vue 2.0 的組件庫，提供了配套設計資源。4、AT-UIAT-UI 是一款基于 Vue 2.x 的前端 UI 組件庫，主要用于快速開發 PC 網站產品，在眾多的的組件庫中，AT-UI 屬于視覺風格比較清新的一款。
1.4 Zent
是有贊 PC 端 Web UI 規范的 React 實現版本，提供了一整套基礎的 UI 組件以及常用的業務組件。通過 Zent，可以快速搭建出風格統一的頁面，提升開發效率。目前有 50+ 組件，這些組件都已經在有贊的各類 PC 業務中廣泛使用。
2、移動端端
2.1 Material Design
谷歌在 2014 年的 Google I/O 上推出了 Material Design，它的目標是創造一個將經典的設計原則和科技、創新相結合的設計語言，并且在不同設備上提供一致的體驗底層系統，并同時支持觸摸、語音、鼠標、鍵盤等輸入方式。
2.2 iOS Human Interface Guidelines
iOS 的人機規范指南，保持了蘋果一貫的風格。雖然沒有 Material Design 規范那么細致全面，但是核心的設計原則在每個組件的設計說明中都有滲透。作為 iOS 系統的設計基礎，建議每個設計師都需要仔細研究。
2.3 Vant
Vant 是有贊前端團隊開源的移動端組件庫，于 2017 年開源，已持續維護 4 年時間。Vant 對內承載了有贊所有核心業務，對外服務十多萬開發者，是業界主流的移動端組件庫之一。目前 Vant 官方提供了 Vue 2 版本、Vue 3 版本和微信小程序版本。
2.4 NutUI-JDL
NutUI-JDL 是一套基于京東物流視覺規范的移動端組件庫，包含了36+高質量組件和詳盡的文檔和實例。
設計師在開始準備設計規范時，首先需要確定設計風格和設計尺寸，頁面布局是做居中固定式，還是全屏響應式。如果是全屏響應式的網頁設計，那要選擇怎么樣的屏幕來做效果？等等這些問題
接下來分別來展開說明。
1、設計風格
三種B端產品的設計風格
純白風（網頁大背景是純白色;文字背景是線框，輕淡色（灰）;文字一般用深色）
輕淡風 (網頁大背景是淺灰色;文字背景是白色;文字一般用深色）；
深色風（網頁大背景是深色;文字背景是帶有透明度的純色；文字一般用白色）
我們在開始設計之前，要確定好使用哪種風格，一旦確定下來，后面的所有頁面和元件的設計，都得基于這個風格來設計。
據數據顯示，目前市面上比較流行的是：輕淡色背景風+全屏響應式的設計風格，也是相對比較保守安全的設計。
接下來需要考慮尺寸是做居中固定式，還是全屏響應式。全屏響應式的網頁設計，選擇怎么樣的屏幕來做效果。
2、設計尺寸
設計規范中，分辨率尺寸的問題，一直以來是我們設計師討論最多的。
決定產品設計尺寸分辨率大小的因素大致包含以下兩點：
2.1 市場占有率（主流）
目前市面上主流的排在前3的屏幕分辨率為1920*1080，1440*900，1366*768。
2.2 兼容能力
做B端產品時，現在市場上的設計師一般都會采用的是1440*900。為什么不用市場占有率最高的1920*1080和1366*768呢？
1、由于B端產品的特殊性，它的尺寸分辨率大小，是取決于用戶使用的電腦設備條件。由于員工電腦顯示屏大部分都是統一采購的，尺寸也就大致統一，所以開發適配的分辨率可以按這個統一尺寸進行設計。
2、因為它的兼容能力會比較強，向上適配或者向下適配誤差會比較小，不管是市場占比最高的主流1920*1080尺寸，還是一般般的1366*768尺寸，都完全可兼容。
注意：別忘了設計出極端情況（寬度為1280，以及寬度為1920）的效果圖，力求前端開發實現的效果和高保真設計圖誤差最小。
假如你產品的用戶用的設備主要是市面上占有率最高的24寸辦公室顯示器，也就是1920*1080分辨率的話，那毫無疑問，在選擇設計尺寸上，直接選擇1920*1080分辨率。
比如我現在做的產品，除了移動辦公，web基本都是固定辦公，管理人員使用的辦公設備（電腦）屏幕一般都是臺式電腦，那這個時候，我們在設計時就會同時考慮它的占有率和兼容能力。所以我們采用的是：1920*1080分辨率。
所以設計師們在選擇尺寸上，一定要靈活使用，不能一味的認死理只選擇1920 或1440某一尺寸，而是要對您的產品用戶的具體情況做好分析，從而得出最適合你們產品的設計稿的尺寸。
注意點：
如果希望設計稿完全還原程度高的話，還特別要考慮瀏覽器的適配，比如說它的頂部固定區域（當前網址，書簽欄等的高度）必須排除在外，剩余的部分才是我們設計稿的真實高度。
拿我們常用的谷歌瀏覽器舉例，如下面公式所示：設計實際高度=電腦分辨率 -（網址欄+書簽欄+頁簽高度)
3、頁面布局
3.1 常見的頁面框架有以下三種:
第一種：上下布局
上下布局包括："頂部菜單欄、主體內容"兩大區域。其中頂部菜單欄是固定不變的，主體內容根據不同分辨率進行自適應動態縮放。另外還需要把主體內容左右兩邊空白區域最小值確定好；
優勢：內容區域可操作空間大。
劣勢：導航區域限制數量，如果導航選項內容比較多，用頂部橫向導航的話，就會顯得很擁擠。另外，橫向導航一般有“展開”，“折疊”，和“收起”三種狀態，加上內容很多的情況下，橫向導航就特別難做到尺寸適配。
第二種：左右布局
左右布局包括："左側菜單欄、頂部欄、主體內容"三大區域。其中頂部菜單欄、左側菜單欄是固定不變的，右側主體內容根據分辨率進行自適應動態縮放。
左右布局時，左側菜單是支持收縮或展開，收縮狀態下也需要有固定的寬度。
優勢：導航部分可擴展性強，適合導航選項內容都是比較多的情況。且只有“展開“和”收起”兩種狀態，在不同屏幕情況下，寬度的自適應也能更加得心應手。
劣勢：相對內容區域空間變少。
第三種：其他的布局
現在很多后臺管理系統采用，"頂部一級導航欄、左側二級菜單欄、主體內容"三大區域。其中頂部菜單欄、左側菜單欄是固定不變的，右側主體內容根據分辨率進行自適應動態縮放。
優勢：結構更清晰?？沙休d更多層級內容。更適用于復雜且層級多的產品。
所以，可以得出結論：設計師在選頁面布局的時候，要全局考慮產品框架及內容。
1、如果導航選項內容比較多的話，或者不確定有多少內容的情況，從美觀和操作難易程度、可用性來評估的話，選擇第二種左側導航是最適合B端產品使用的。
2、如果內容選項確定很少，就沒那么多限制，“左側縱向”"頂部橫向"都好使
特別要注意
1、同一個產品需要考慮它的統一性，不能這里使用頂部橫向，那里用左側縱向。
2、如果是個更新迭代的版本，就還得考慮老用戶之前的使用習慣，避免引起不必要的麻煩。
在確定好導航的布局后，就基本上能確定整個產品的頁面布局了。
3.2 常見布局尺寸：
B端產品，一般會在整個頁面的左上角放企業的LOGO，頂部欄高度48+8n，側邊欄寬度200+8n。
我常用的是頂部欄高度：56px或80px，側邊欄寬度：200px，側邊欄收縮狀態寬度：56px或80px，右側的側浮窗寬度：400px。（具體高度寬度尺寸，設計師可根據具體情況來定，不需要按部就班這么死板）。
同時需要確定好主體內容的上下左右邊距，以及主體內容區域中各模塊的安全距離，內容超出區域的，通過滾動查閱更多。
4、文字
4.1 B端產品常用的字體
Windows系統：中文Microsoft YaHei(微軟雅黑），英文Arial；
Mac字體：中文PingFang SC（平方字體），英文 Helvetica；
4.2 常用的字體大小
常見的字體大小為：12px、14px、16px、18px、20px、24px、26px、28px、30px（一般都是采用偶數字號，文字大小12+4n）。
注意：
在設計過程中，設計師對字號應該有一個全局觀，在同一個界面內，盡量少用大小太接近的字號。比如一個頁面中，如果同時用了12px、13px、14px、15px、16px、18px排版，文字的層級對比會比較弱，沒有主次之分，用戶閱讀困難，視覺效果也顯得凌亂。
所以，剛接觸B端產品的小白設計師，如果不知道怎么運用不同字號字體的情況下，可以直接以這組字號12px、14px、16px、20px、34px的字號為參考使用，這樣的分布會層次明晰，能夠有個比較不錯的布局結構。
“行高”根據文字大小和使用場景來定，公式如下，
行高=文字大小+8px（或6px，視情況而定，我常用8）
例如：12號字體的行高=12+8=20px
同一個界面中，一定不要出現多個不同字體。盡量選擇用戶設備里自帶的字體來進行設計，比如說WIN系統默認用系統自帶的“微軟雅黑”，不能使用特殊字體。
如果必須要用特殊字體，建議用圖片替代。如果用戶的設備里沒有你使用的這些字體的話，會默認顯示設備的系統自帶字體，最終效果就會和你的設計稿相差很多。
從視覺方面來講，為了讓整體界面更簡潔具有美感，體驗感更好，在使用字體方面，一般字體種類不超過2種，越少越好。因為頁面的層次感主要是靠字號大小及顏色拉開層次，如果字號在變，字體種類也各種變化，整體就會感覺很凌亂，沒有統一性。
5、顏色
顏色規范包含“品牌色”、“輔助色”、“中性色、圖表色”四部分。
5.1 品牌色系
品牌色系：即產品主色調，主色調的設定直接影響產品氣質和直觀感受，也是產品的對外的形象。品牌色是根據這個產品的特征和定位、用戶群，以及使用場景等綜合考慮最后確定的。
品牌色的一般用于LOGO 、操作狀態、按鈕顏色、其他一些可操作圖標等。
1、品牌色一般建議選擇冷色系。這樣有效避免與“錯誤提醒”的紅色、黃色相沖突，讓人誤解。但要是被硬性要求必須選暖色系作為主色調，就得格外注意調節好主色調與錯誤提醒的區別了。
2、注意選的品牌色（主色調）不要太刺眼。要保證用戶長時間使用也不至于顏色太亮太刺眼，而產生的視覺疲勞。
5.2 輔助色系
輔助色系：輔助色一般用于“提示”。類似：成功、失敗、警告、無效等內容等。
5.3 中性色系
中性色系：中性色涵蓋黑、白、灰三個不同層級，通常在文本、背景、邊框、分割線用到它們。同一色相，只要改變它的透明度就能表現出不同的層級。
B端產品的文字中，一般會有：一級標題、二級標題、一級正文、二級正文、提示文字、輔助文字、說明文字等。
為了區分層級，提升用戶的閱讀體驗感，通常會根據具體需求，把字體顏色的深淺，大致分成3到5個層級。常見的有#333333、#666666、#999999這個組合，這個組合的層級區分比較分明，適應性比較廣，設計師在設計時可以直接作為參考。
5.4 圖表色系
圖表色：我們常見的后臺管理類產品， 像數據可視化、統計圖、多個標簽的不同配色方案，所以一般還會設定圖表的顏色。
6、按鈕
按鈕是任何用戶界面不可或缺的交互元素，B端產品中用到按鈕的場景特別多，類似：登錄注冊，保存，表單，彈窗，導航，提交，確認等等。
6.1 按鈕的形式
常見的按鈕形式包含這六大類：圖標文字組合的按鈕 ，主按鈕，次按鈕（線性按鈕），按鈕菜單，文字按鈕，圖標按鈕。
6.2 按鈕的交互狀態
常見的按鈕交互狀態包含六種：
正常狀態、聚焦狀態（使用Tab鍵或方向鍵來對網頁進行訪問輸入的聚焦狀態，在設計時很多設計師都會把這一狀態忘記，導致用戶無法用方向鍵控制光標位置，會降低用戶的使用體驗感）
懸停狀態（鼠標正在按鈕上，但不點擊，需要注意的是平板電腦和移動端設備上不會展示懸停狀態，因為手指跟光標不一樣，無法在屏幕上進行懸停 ）
激活狀態（點擊按下狀態）
加載狀態（等待期間不可操作，在B端產品中Loading狀態特別重要，能緩解用戶的焦慮情緒）
禁用狀態（不可操作狀態，置灰顯示和透明度（40%）代表不可操作狀態）
6.3 按鈕的圓角
按鈕圓角：在開始設計產品之前，設計師都需要對按鈕圓角有具體的規劃。按鈕四角都是直角會比較有距離感和強烈的引導性，容易分散用戶注意力，所以我們一般會采用視覺上給人比較柔和親近感覺的圓角按鈕。
但按鈕的圓角并不是越大越好，因為在相同尺寸下，按鈕圓角小的，操作熱區會更大，頁面的使用效率也會更高，更容易操作。同時還要特別考慮到下拉菜單的設計，所以圓角大小一般采用偶數：2px,4px,6px,8px,16px為宜，不宜過大（這里的圓角弧度的值有一定的倍數關系或基數關系，例如：4/8/16, 4/6/8，4/8/12，都是可行的）。
注意：圓角大小也會跟著按鈕尺寸的大小有相應的變化。
按鈕的高度
在B端產品中，當確定好網格基數時（通常網格設定為：4px。按鈕的高度會分兩種情況：
1、一種是寬度為高度的倍數關系。
2、第二種是如果寬度為高度的倍數關系，從視覺上看達不到想要的效果的話，設計師就可以靈活設置。
6.4 按鈕的大小
討論到按鈕的尺寸，我們需要大致知道如何設置網格基數。
在設計中，我們需要在常用的繪圖軟件（如：Ps、Sketch）里找到我們的網格功能，設定好一個數為基數，然后按照這個基數來進行按鈕的繪制，按鈕就相對比較規范了。
那如何用繪圖工具設置網格基數呢？方法如下：在Sketch繪圖工具中找到：【視圖】-【畫布】-【網格設置】- 彈出網格設置對話框進行設置就好了
把網格基數設置為【4】的原因：它是谷歌Material Design繪制小組件的規范，模塊之間定義的基數就是【8】。
假設我們定這個基數為4，那采用的尺寸數值就需要是基數4的倍數。比如B端產品中，常用的按鈕高度尺寸有：24px、32px、36px 、40px、48px，這些都是可以整除基數4的值。例如：32/4=8，40/4=10，這里的4為基數。
按鈕的寬度尺寸，一般是確定好文字到邊框左右兩邊的距離（例如如圖Padding值為12px)后，開發會根據文字內容的多少自適應的。
按鈕間距，按鈕之間的間距也遵循基數為4的倍數，比如：16，24，32，40，48等。這里的基數定為偶數（一般為4或8）
7、表單
從廣義的定義來講，表單是指用于數據錄入的一切形式。從狹義上來講，表單在大家更廣泛的認知印象中，表單則是一類包含輸入框、下拉選擇框等常見控件的組合形式的頁面才屬于表單。表單的本質核心是提交數據，所以凡是具備采集數據并完成采集后提交數據的交互形式均可稱之為表單。
表單在設計上的結構有：1、標題；2、表單標簽；3、占位符；4、表單域；5、提示信息；6、操作按鈕；
7.1 表單設計目標
表單的設計必須優先考慮為用戶減負，提高效率并簡化填寫流程。另外表單中組件的選擇需要依據具體的數據類型和具體的業務場景進行合理正確的選用，為用戶提供高效的數據錄入表單，降低用戶操作成本、認知負擔，并提高數據采集效率才是表單設計的根本目的。
7.2 表單的輸入域
可交互輸入域，是構成表單的核心內容，是表單用來采集數據的入口。輸入區是用戶交互最多也是最能影響使用體驗的區域，不同類型數據選擇與之相應的錄入方式，對提高表單操作效率和用戶體驗大有裨益。
表單并不是把一些不同類型的輸入框排排版、標清楚必填非必填、哪些表單比較復雜適當的加個說明就完了
其實，表單設計遠遠不止這些，表單本身也是一個小產品，它也需要有需求的支撐、也需要嵌套使用情境、也需要考慮用戶的心理模型；從表單的產生到表單在頁面上如何呈現，再到使用表單時與表單之間的交互，每一步都需要投入大量的思考來做好表單。
后面我會專門有一篇16000+的文章聊聊這個B端產品中比較核心的表單，有興趣的朋友可以關注一下，大概五月份就會發。
8、表格
表格在整個B端產品比較常見的，它的地位也是相當重要的，我們在設計表格時需要注意一下幾點：
8.1.表格內的文字內容：
一般以左對齊為準。與左邊表格邊距盡量保持在10px以上的間距。（特別注意：金額和操作的標題和內容需要右對齊）
8.2 表格的列數：
默認展示的列數為3-8列，如果需要展示更多列數，則需要優先固定展示重要列，其余的列的內容會以滾動條滑動而展展示出來。
8.3 表格列表的寬度：
寬度的尺寸大小自適應，但需要根據文字的重要性顯示，重要文字內容優先完整顯示。
8.4 表頭每列標題文字字數：
字符不要多，最多可輸入8個。如果文字太多，就需要做文字信息精簡化。
8.5 滾動條使用場景：
表格內容超過一屏，就需要顯示豎向滾動條，注意：表頭需要固定，但表格內容可滾動展示。
8.6 表格無內容：
表格的某些單元格無數據內容時，需要用“—”表示，需要區別于“0”。
8.7 表格標題欄和內容欄高度尺寸：
標題欄高度（標準高度為56px）；內容欄（標準高度為56px，偏大的標題欄高度為80px），內容區和標題欄水平居中對齊。
8.8 表格內容對齊方式：
列的對齊方式（垂直方向）除了需要始終保持“右對齊”的：金額，最右側操作列內容外，其他的內容可自行左對齊或右對齊。行的對齊方式（水平方向）
當表格欄的高度尺寸小于80px 時，一般只有一排內容，內容水平需要居中對齊。當表格欄的高度尺寸大于80px時，如果是有兩排內容，所有的內容需要頂對齊；但是如果既有一排內容 又有多拍內容的話 ，內容水平則需要居中對齊。
8.9 自適應規則：
表格中的內容，會根據字段的長短定義所占的百分比，完成表格占比，從而達到希望實現的最佳效果。
8.10 滾動條：
滾動條分為橫豎兩種，當表格內容超過一屏時，就需要顯示滾動條。豎向滾動條時， 需要固定表頭標題欄和頁碼。只需滾動表格內容部分即可。橫向滾動條時， 需要固定第一列 和 正在操作的項列。只滾動表格內容部分即可。
9、反饋
9.1 弱反饋
僅提示用戶相關內容，不需要用戶做任何交互動作。類似：toast弱提示通知提示等彈窗（（一般3-5秒會自動消失：包含普通信息，成功信息，失敗信息，警告信息）。
另外還有，鼠標經過的時候即可出現而不用點擊的彈窗（這個彈窗通常會設計一個浮動帶有陰影效果的框，不需要遮罩）。比如提示說明，顯示更多信息，鼠標移過后立即消失，它不會影響下一層（當前頁面內容）頁面的視覺效果和操作。弱彈窗尺寸一般根據文字多少自行適配。
9.2 強反饋
第二種是強彈窗。它是一個需要用戶必須對這個對話框進行操作后才可以離開。
例如彈出的列表，詳情，表單等的確認信息彈窗、錯誤提示彈窗。這些強彈窗一般會對下面一層的頁面做一些遮罩處理，例如添加上一層有透明度（例如30%，50%都可以）的黑色/白色，給下一層頁面的內容做模糊濾鏡等等；
在寫彈框規范時，應了解各自項目中需使用彈框的有哪些內容，給出相關大小彈框的比例，哪些為固定尺寸，哪些為適配比例。以及對于通知提示給出停留多少時間后自動消失，彈窗彈出狀態等等相關的交互規范。
10、其他
缺省頁是互聯網中常見的場景，當遇到網絡不好、頁面中沒有內容數據、暫無資料等等情況，所導致的空白頁面。
大致分可為：系統類缺省頁，信息類缺省頁，空白類缺省頁。
遇到這些情況時，設計師一般采用一些插畫&文字的組合放置本來空白的頁面中提示或引導用戶進行下一步操作，以緩解用戶的焦慮情緒。（也就是我們常說的情感化設計的一種方式）
設計規范很大一部分是組件庫，所以就把組件庫單獨拎出來聊聊。
1、組件庫是什么？
做一個比喻，組件庫相當于積木玩具的一個個積木，每個組件就是一塊積木，通過組件的拼搭可以迅速搭建出一個頁面，而設計規范就相當于搭建的“說明書”。
通常我們將組件庫分為基礎組件和業務組件兩大類，前者是系統通用組件（圖標/按鈕/輸入框等），后者是由業務決定的相對更復雜的組件模塊。
而對于B端產品和C端產品，二者的組件庫又有些許差異。C端的組件庫更追求極致的交互和視覺體驗，因此需要考慮視覺、性能、實現、兼容性，另一方面，C端會根據活動、節日切換不同的主題，也要考慮組件視覺上的個性化擴展。對于B端而言，組件庫更看重可復用性和穩定性，保證可以支持業務快速迭代。另外B端會涉及到各種各樣的數據錄入與展示，因此相對更高的要求是大而全，覆蓋面廣。
2、組件庫的原子理論
2.1 原子設計/拆分
在業務已經發展到一定體量情況下，需要將項目中具備復用性及拓展性的模塊進行拆解，對于B端產品來說篩選的時候會依據之前迭代的版本內容，把頁面一一羅列出來，將可替換與相似的模塊提取，并利用思維導圖的方式統一歸納，并做成可以被替換的組件。組件的替換建議合成一個大的排期進行替換，避免了線上組件不一致導致體驗問題。
以我們現在的產品為例：依據產品類型將組件拆分為：基礎組件 、業務組件、數據可視化組件、常用模塊。
原子設計
將產品拆分后，此時得到很多可復用組件。我們再依據原子設計理論針對性進行拆解直至拆分出5個層面：
從原子開始重新依據定好的視覺規范進行更改，再由原子組成新的分子。
3、盒子理論
在與開發溝通設計規范制定的過程中，常提到他們寫CSS樣式的時候是采用盒子（box）去寫的。通過一個個盒子填充來將我們的組件元素放入其中，最終形成前端展示的頁面。
走查時使用瀏覽器我們也可以看到開發寫的盒子，了解盒子也可以方便我們走查時知道問題在哪。
四、如何搭建組件庫
搭建組件庫的步驟
4.1 確定組件庫內容
對于新產品來說，業務體量較小，較難抽取共性，組件也不全面，因此較好的方式是參考大廠的組件庫確定要做哪些組件，它們的相對成熟，參考價值較高。
對于已經成熟的產品來說，我們可以直接全面體驗查看頁面，找出所有用到的組件，除基礎組件外，提煉出復用率高的業務組件進行結構化和組件制定。
4.2 搭建每一個組件庫
以提示彈窗為例，演示單個組件的建立方法。
1. 定義組件：根據業務定義提示彈窗使用場景，用于重要信息的提醒，且需要用戶自己關閉操作。
2. 拆分組件：這一步是將組件拆分為元件。對提示組件進行拆分后得到如下：
3. 重組輸出根據業務場景，我們把各個元件重組為組件，建成組件集，并定義各種組件的使用規則。
4.3 輸出文檔并替換到產品中
在組件庫建立完成后，只有在日常設計中真正使用組件庫，提高組件庫在設計稿中的覆蓋率，才能真正達到組件庫的效果。這就要求我們要輸出一份完整的組件庫描述文檔，在團隊中進行推廣，加強設計團隊的公用意識。設計團隊內部可以直接維護一套組件庫，設計師設計時直接調用公共組件庫組件使用。
另外，我們還要與開發工程師配合逐步完成現有頁面的組件替換。
4.4 定期維護組件庫
組件庫的內容并非一成不變，而是在不斷地更新，以保證所包含的組件都是最新和有用的。與其他數據一樣，組件也會有增刪改。我們需要定期對組件庫進行維護。
增加：當有新的組件產生時，我們需要通過判斷它的拓展性和復用率，以確定是否將它入庫。
刪除：隨著產品的不斷升級迭代，如果某個組件已經不用或復用率很低時，我們可以考慮是否要將它刪除。
改：不可避免的，組件會隨著業務而進行升級，我們可以通過數據埋點和A/B test的方式來確定某個組件是否要進行改動。
一、設計規范落地不了的原因
1. 設計層面
組件擴展性弱：
有時候設計師做出來的組件雖然看著很好，但是實際上使用時，適配效率很低，用組件去擴展和重新做的效率差不多。
脫離業務：
大部分時候設計師手中都有任務，于是這個任務就落在了相對不是那么忙的設計師手里（一般是新設計師），但是新設計了解業務相對來說是不夠的，做出來的東西就像是是空中樓閣，拋開業務談設計規范的都是很難落地的。
缺乏開發思維：
設計師不了解開發的實現方式，可能會做出來以后，開發較難實現，然后開發也就不會做。
2. 開發層面
缺少開發資源：
首先，設計規范的作用是巨大而延遲的，不能即時產出很大的價值，另外一方面，設計規范的落地會增加開發工程師很多的工作量，且無法量化成果。這也導致很多時候設計師無法爭取到足夠的開發資源來做這件事，所以，很難導致達到預期的效果。
二、怎樣更好的落地設計規范？
1. 更加全面的了解產品及業務
設計師需要更加全面的了解產品及業務流程。
研究用戶：
前期需要做好用戶畫像，弄明白產品的目標用戶的差異，不同用戶的使用場景。只有弄清楚各個角色的關系以及功能設計的邏輯，具體用戶年齡，解決什么問題，才可以產出更符合用戶需求的設計。
研究業務：
如果是新的產品，那就需要去詳細的看類似的競品的功能及業務流，并且了解公司產品的定位及方向，所以就大致清楚設計的大方向。
研究產品：
系統整理產品情況，最好是做思維導圖形式，可以更好的梳理同類型的產品功能及組件，也就能更好的提高組件的復用性。
2. 整理好規范的內容和分類
在制定規范前，需要明確產品中主要有哪幾種分類，將最基礎的分類定義好方便后續針對分類內容進行整理。
3、如何推給pm、推給設計團隊、推給研發團隊
團隊溝通其實是一門藝術，那需要如何做呢？
首先，寫一份設計規范的價值的提案給領導，爭取到足夠的資源，包含設計資源、開發資源。如果領導的主導參與，那這個事情就好推動多了。
然后，把設計規范的設計工作交給熟悉業務的設計師來做，通過業務提煉復用率高的典型元素，優先開發，最大化投入產出比。
搭建設計規范和我們日常處理工作需求類似，并非輸出一份文檔就結束了。我們還需要將做好的設計規范推廣給各個職能部門的同事包括設計小伙伴，PM和開發小伙伴的團隊內外，并且需要得到團隊內的一致認可才算是初步完成。
召開專門的設計規范會議，以清晰明確且有效的方式把詳細的內容傳達給各個相關人員，在一致認可規范的情況下，以達到內容的傳達到位。同時，這個時候，就可以依據開發人員的反饋，做落地的修改規范文檔。
1、如何推廣給PM
利益點：提升協作效率，減少工作成本
在啟動設計規范的整理之前，內部宣講讓PM對于設計規范的搭建已經有了一個基礎的概念。然后爭取到更多的開發資源。否則PM不會分配資源給予時間去搭建整體的設計規范。
可以從提升PM與設計的效率和降低原型搭建成本作為切入點，通過組件庫以及通用模版的搭建，PM只需要極低的成本學習一下組件庫怎么使用，即可搭建高保真的原型界面。甚至完善好組件庫后直接不需要設計的參與，開發通過原型組件庫搭建頁面。
2、設計團隊內部如何推廣
利益點：提升設計效率，減少人力損耗，保持體驗一致性
設計規范一般由團隊內小伙伴共同制定，基本上已經對規范的優勢達成共識。因此主要講講如何更好在團隊內部使用規范。
團隊設定主要負責維護的設計人員，其他人員在設計時候，通過Sketch Library 共享組件庫可以直接調用組件，并建立更新日志規范項目流程提升效率，定期維護的時候其他人員統一告知負責維護的設計人員，統一定期修改更新升級維護。
3、研發團隊內容如何推廣
利益點：封裝組件，更少的更改，提高驗效率，縮短研發流程
需要研發團隊認可設計規范，前期前端的參與是必不可少的。
在制作規范時設計師了解了前端開發的一些簡單原理，前端開發也能及時了解設計師的想法，大家不再是各司其職而是串聯起來共同協作，當規范確認下來前端就不會頻繁改動組件，而且在有限的項目時間中。設計規范的統一極大縮短了設計和前端開發所需的時間，為后面的項目爭取了空間。
4、排優先級，嵌入版本迭代內
一套完整的規范包含內容是非常多的，難以在1個版本迭代里面修改完。
因此可以采用敏捷開發的思想，小步迭代快速推進，將設計規范的覆蓋放在每次迭代過程中。設計師需要將自己作為設計規范這個項目的產品經理，針對現有的需求進行拆分，并排出優先級分版本迭代進產品里面。
可以依據從大到小的原則進行優先級排序。對產品設計風格影響大的先排，影響小的后排。
設計規范的制定不單單是對于設計師，在嵌入版本里面要隨時與產品和開發多溝通，以便達到更好的落地效果。
接近1.5萬的文字梳理，感謝你看到了最后。接近尾聲了，制定及梳理設計規范對于設計師來說個人成長有哪些方面呢？我個人覺得可以從這幾個方面來說；
收集信息能力
通過整理規范，需要收集目標用戶，使用場景、前期調研、產品功能梳理等眾多資料，這期間我們需要去發現信息以及整理信息。龐大的信息收集，那對于個人的收集整理信息的能力是一個很好的提升，同時對產品會有更全面的認識。
歸納總結能力
將收集好的信息進行分類整理，這要求需要一定對邏輯性。在設計基礎框架時合理對分類可以協助我們處理好每個控件對層級，這項能力無論實在工作還是日常中都有著巨大對好處，可以幫助我們從一堆繁雜的事物中“提綱挈領”，換言之就是“化整為零”，做減法，提取出最關鍵對因素。
全面復盤能力
將信息歸納整理好后，需要對全局進行思考，全局的設計及交互都需要考慮到位，比如什么情況下適合跳轉頁面，什么情況下適合給與用戶彈窗。大體符合什么交互原則。
除了對大體交互需要考慮到位，細節上也不可以忽視，比如異常情況，極端情況該如何去處理，組件之間該怎么去配合等。在日常工作中我們也可以逐漸有意識去培養此類技能，對項目全局思考的越多，那么對整體項目對把控能力也就越強，與他人合作也會越顯得專業。
溝通表達能力
在整個推廣設計規范的過程，就是提升溝通表達能力的過程。
另外，整理設計規范時，難免會遇到模凌兩可舉棋不定的時候。此時可以尋求向上或者向下的資源尋求幫助，具備良好的表達能力能迅速幫助我們將問題闡述清楚，表達能力是設計師需要具備的重要技能之一。
我們每次在求助他人或向他人匯報，都需要在全面復盤問題過后做到心里有數，將問題自己復述一次是否有漏洞或者沒考慮清楚的地方。長此以往你表達的事情會更清晰，別人也更容易聽懂你說的事情快速理解內在邏輯，那么說服別人推動工作的難度也會越小。同事對自己的邏輯思維，表達能力都是很好的鍛煉。
這里總結了幾個工作中與上下游溝通的小技巧希望能幫助到小伙伴們：在開始與他人溝通之前我們需要搞清楚我們溝通的原因與對象
原因里面包含：
對象里面包含：
當然在溝通時還需要考慮方式和語氣，這些都需要好后斟酌。如果遇到情緒不太好的開發，這個時候反倒我們更不能將情緒激化，一般這些情緒化對態度過一會都會消散，可以采取冷處理等情緒過后換一種方式溝通看看。
文章來源：站酷 作者：789研習社
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
問題注意事項
