我們在做網際網路產品中，有的是以產品功能，但大部分以專案為緯度進行分割。在產品1.0後，設計團隊需要UI設計師建立規範，如果你所在的產品團隊有2個以上的UI同學。那可能在1.0還沒開始，一套好的UI規範就是需要立馬做的。

首先要明確，UI規範是需要UI設計師或UED團隊來完成的。但今天這裡我歸納了一些好的設計規範方法集合（含多個案例）。

從如何建立設計規範、團隊什麼是需要規範、設計規範應該有什麼緯度，本文涵蓋較多的圖片內容，建議注意。

下面這些內容都來自一群優秀的設計師回答者，通過產品經理視角歸納了上面3個問題的答案。

設計規範的分類

UI的設計規範總共可以分為三類：

品牌類（VI）

幫助企業做的宣傳手冊、PPT、市場公關等pr檔案，企業的整體形象顏色。就好比你現在看到的瓜子二手車，綠色是整個的顏色。

 

 

平臺、系統類

常見的是IOS、谷歌、開放平臺、小程式等，需要第三方開發者介入，需要第三方的開發者在設計上遵循什麼理念，以及遵循該套理念 後的背景與原因、好處

產品業務類

面向產品內部，規則側重在產品設計和實現層面，實用性第一。設計文件、標註都不能少，其他設計同學或工程師可以直接參考或使用

互聯產品的設計規範概念

設計網際網路產品，Style Guide /Pattern library、Specification各具不同的功能和作用，卻都含“設計規範”的概念

Style Guide 

偏重視覺概念，常見文件或影象格式呈現（還可以擴充套件）

內容：對設計作品的字型（Typeface)、字型（Font）、色板、品牌標識規範（Brand Guideline)、Icon等要素進行展示和說明

這個部分主要的功能是方便設計師與設計師之間，展示產品的視覺風格。方便風格複用，規範新的元素或第三方接入。

Pattern Library:

偏重（web前端）開發概念，基本都是以網頁文件形式呈現

內容：對介面元素（UI Elements)的樣式風格以及實現其效果所對應的程式碼片段作出解釋（HTML、CSS），常見的佈局（Grid System)、字型排版（Typography)、按鈕、選單、列表、對話方塊（Dialog)、Toolip等等

可以幫助團隊Web設計和協作開發，統一產品風格。減少UI還原與驗收的工作，保證使用者體驗與最初設計稿一致。

 

 

Specification(Spec)

介於設計與開發之間，由設計師直接在（mockup)中建立

內容：主要由Annotation（註釋，國內俗稱“標註”）和Measurement(量度）構成。其實說白了就是我們常規研發中的讓UI切圖，是開發與設計人員最直接的交流。通過切圖，我們可以把字型字型、色紙

 

 

UIKit與設計文件規範

細節的設計規範在不注重設計的公司是非常難以推動，第一是版本變化太快。很可能今天上線的新產品，明天就說要重構。UI稿都沒時間做完了，哪還有時間去琢磨這個版本的設計規範，小步快跑待商業模式清楚後再去考慮設計規範的事情。

當然，如果團隊中已經有幾個設計師的情況，可以考慮在基礎控制元件、元件上建立規範，方便設計稿合併的時候可以連線上。

通過設計團隊一起討論、草稿、細化、定稿、規劃、批量化，設計規範就像炒菜一樣。絕對不是通過加點鹽、少點醋可以把菜做好的，而是通過時間的積累，越沉澱會越香。

設計師也需要從無規範到沉澱自己的規範，如果一個版本推翻，就全部重新更換規範。這就是去了規範的意義，規範是可以複用，並且也可以讓使用者達到了固定的認知，推翻則可能是對使用者習慣的挑戰

UIKit,其實說白了是將設計稿原始檔以 psd\sketch檔案，可以讓不同設計師快速使用，並且產生設計風格相似的產品。

比如小程式與app或web，如果已經訂好了web，則設計師可以通過該規範快速產生小程式設計稿，讓小程式可以用一套規範

如知乎在web的熱搜榜與知乎小程式的熱搜

 

 

UI設計文件規範

 

文件與UIkit的不同點在於，可以更加詳細和準確的表達。對風格、顏色、文字、控制元件、互動、圖示、東校，甚至還可以包含配樂都有了明確的標註。需要不停的更新、迭代、完善，這是一個持續的動態文件。有點類似產品經理的需求池、需求文件一樣，隨著新功能、新版本、新元素的加入，設計師需要增加UI設計文件規範的內容甚至推翻部分規範。

文件規範又分：

• 字型排版（Typography),即介面式設計

• 顏色（Color)規範，產品主要的顏色庫

• 圖示庫（Icon)

• 控制元件庫（UI Toolikt)

• 視覺框架（Visual Hierarchy)，定義產品的互動框架結構，與資訊架構有關需要產品經理參與

下面是一個UI文件規劃web端案例

 

 

企業vi/品牌形象的規範

企業vi並不是網際網路的UI規範，他沒有像互聯產品的什麼button\控制元件等。但他們都非常相似，因為兩者緊密相關。通過企業的logo展開的產品、企業服務、企業形象都是vi、UI設計師需要考慮的。

二個比較好的例子就是MUJI和apple，下面分別是他們的app \網頁\實體店

 

 

 

 

 

蘋果

 

 

 

設計UI規範步驟

既然知道UI規範有什麼，需要什麼內容。UI同學真正在實際工作中是如何建立設計規範的？

大體的流程為：

瀏覽所有元件》分類》整合》參考競品，優化元件》寫UI文件》驗證、拓展更新

瀏覽元件

瀏覽產品所有的頁面，對產品的元件進行全面的瞭解，比如如果是社群產品，則feed流、登入註冊、圖文元件。一定要注意緯度是最細的：元件，搞清楚有多少種元件

分類

不同行業的產品，元件的優先順序會有不同。比如電商類的是以圖文元件、新聞資訊的是資訊流元件。

通過截圖的方式進行收集，不要一開始就用sketch或axure來進行繪製。非常耽誤時間

整合

對元件進行分類，注意的是有一些元件可能會出現個性化的情況。根據產品經理需求而定。對照新版本和需求，對現在沒有的元件也進行標註，以下面的方式進行展開

參考競品、對照需求，優化元件

通過分類，我們可以以元件的型別去參考一些好的案例。比如網易、騰訊等產品，甚至是自己所在行業的競品，上面我們只是把之前的元件進行了規整。接下來就是對不同型別的元件進行優化，因為很多元件可能在沒有規範的時候其實是老化或淘汰的。

參考競品既可以知道元件規範的問題，也可以知道是否付費時代使用者趨勢。在這步完成後，我們的元件就基本新鮮出爐啦。

寫UI規範文件

通過上面的工作，我們接下來使用sketch或藍湖等工具，將文件規範輸出。注意前面說的，UI規範文件是一個持續動態的文件，保證團隊可以及時更新和複用。下面是一個例子

顏色提供高度定製化還是提供有限色板

在這裡有2個前端開源工具，分別是Bootstrap和Semantic UI，都是非常豐富的前端規範案例。

Bootstrap是美國Twitter公司的設計師Mark Otto和Jacob Thornton合作基於HTML、CSS、JavaScript 開發的簡潔、直觀、強悍的前端開發框架，使得 Web 開發更加快捷

Semantic UI

Semantic is a development framework that helps create beautiful, responsive layouts using human-friendly HTML.

在色調的選擇上

有去色板的，色彩主題非常容易切換；由於顏色的可選性不多導致場景的選擇上會更加苛刻，或者需要新增額外的設計

定製化的優勢是方便提供色彩的豐富性，每一個component的顏色都可以毫無相關，但劣勢是增加了色板的控制難度，對開發的要求也會非常高。開發需要通過管理不確定的顏色，就要管理未知的程式碼設計。

下面是在是一個案例

本次規範內容原創的作者門：

阿本、陳希 Chris、周莜、葉卉、靜靜、阿本、icecreamliker

 

好的內容會發光，感謝他們的內容提供。相信也能在這裡幫助正在閱讀的你

定一套設計規範，減少產品彎路

之所以花這麼長時間整理這篇歸納內容，是近期在工作中深刻認知到一套UI規範是可以大大提升開發效率，減少在測試、UI還原的工作量，並在思考一個問題產品經理如何協助UI定規範？

 

產品經理需要告知需求的背景、需求介紹、產品未來的規劃甚至是產品的商業模式

當然，如果你只有一個點子，還沒有開始你的專案運營。那設計規範可以放在後邊，但當專案上線後，逐步開始進行UI的迭代與團隊成員增加，一個持續動態更新的UI規範是非常有必要的。

產品經理要知道在UI規範中常見的一些事件，比如按鈕的狀態、輸入框的狀態等型別。因為很多情況下，UI設計師一個人是沒辦法全部想全面，產品經理需要在測試環境甚至是線上環境就給予建議。

當然，理想的方式還是在UI設計中就給予對應的元素、元素狀態。