如何建立一套 UI 設計規範？
說句實在話，Style Guide 我在 HP 幾乎天天寫，但是在百度還沒見過很嚴格細緻的版本（攤手），一份 PDF 做兩個月改三個月、目錄佔三頁、總頁數超一百、做完要用三五年，等你離職了還有人找上來問拿到的是不是最新版，這事兒擱互聯網公司確實效益不大。
請不要揪住我說百度東西不統一，BAT 的設計都很醜這種事兒，我只想來分享一下一些（至少看起來）還不錯的 Style Guide，加這個括弧是因為我覺得這玩意兒最重要的是「用起來」好用，做到這個很難，因為往往 Style Guide 是設計師寫給一些跟設計師思路很不一樣的人群的。
先來幾個有份量的壓壓場：- 納粹的設計規範，出版於 1937 年
- NASA的設計規範，1976 年
- 1993 年的任天堂角色設計規範
如果沒有被上面兩個嚇到的話，再來看看一些偏 UI 的設計規範：
- BBC 移動端
- Mozilla
偏 VI 和 Brand 的
- 現在的 NASA
- Dropbox
偏前端的：
- Lonely Planet
- FontShop
當然還有 Apple 和 Google 的很出名的規範，我就不贅述了，以上內容收集自 Google、Designer News 和 Brand Style Guide Examples。
我自己做的 Style Guide 沒法發出來而且我覺得我做得也不太好，不過分享一些我覺得可以注意的地方吧：- 以觀賞者的視角去寫，大到結構啊小到單位啊啥的都注意一些，考慮一下使用的人群。
- 要可執行，像當年 Android 初代時候那個奇葩的桌面圖標透視角度，有幾個人鳥他的，他自己後來都不鳥了。
- 考慮好擴展性，以後要多一個 iOS 平台怎麼辦？如果屏幕越來越大，定義的文字大小不夠用了怎麼辦？
- 讓別人「用」一遍，相信我，你做完之後發給十個人，至少有 3 個人會看不懂不會用的。
- 做好版本管理並且寫上聯繫方式，如果有問題別人可以找你解決。
2017.01.07 更新：
今天看到一個 Design Guideline 的聚合網站，目前收集的還是比較主流的，但估計以後會有陸續更新，另外還有對每個 Guideline 的大致介紹：
http://designguidelines.co/
概念，靈感，方法和工具
概念：
設計互聯網產品，Style Guide / Pattern Library 和純粹的 Specification 各具不同功能和作用，卻都含「設計規範」的概念。
1. Style Guide / Pattern Library：- 偏重視覺概念，一般以文檔或圖像格式呈現（不限定）。
- 內容：對設計作品中的字體（Typeface）、字型（Font）、色板、品牌標識規範（Brand Guideline）、Icon 等要素作出展示和說明。
- 主要作用於設計團隊或設計師之間，展示產品的視覺設計風格。便於風格復用，規範第三方的品牌塑造（Branding）和接入。
實例參考（更多參考下文中「靈感」）：
Brand Assets | Kickstarter
Logos branding | Dropbox
2. Style Guide / Pattern Library：
- 偏重（Web 前端）開發概念，基本都以網頁文檔形式呈現。
- 內容：對界面元素（UI Elements）的樣式風格及實現其效果所對應的代碼片段（HTML, CSS）作出說明解釋，包含交互和動效設計（以 JavaScript 為主，更多信息參考：界面動效設計方法有哪些？）。例如：常見的基礎布局（Grid System）、字體排版（Typography）、按鈕、菜單、列表、對話框（Dialog）、Tooltip 等等。
- 用於團隊 Web 設計和開發協作，統一產品風格。復用時提升工作效率，同時也保證用戶體驗質量。
實例參考（更多參考下文中「靈感」）：
Pattern Library | MailChimp
Mapbox styleguide | Mapbox
概念 1 和 2 結合的實例（更多參考下文中「靈感」）：
Product Style Guide, Visual guidelines | Salesforce
Style Guide | Lonely Planet
3. Specification (Spec)：
- 介於設計與開發之間，由設計師直接在視覺稿（Mockup）中創建。
- 內容：主要由 Annotation（注釋，國內俗稱「標註」）和 Measurement（量度）構成。Annotation 既注釋設計稿中界面元素所使用的字體字型、色值等，Measurement 則註明各元素的尺寸及它們的邊距，留白等。
- 用於設計師與開發人員之間溝通和工作交接，保證開發出地產品界面和視覺稿高度統一。
______________________________________________________________________________________
靈感：
一些常用的項目和文檔都有採用上述的「概念」，比如採用了概念 1 的：
iOS Human Interface Guidelines
Material Guidelines
採用概念 2 的：
Skeleton
Pure
Bootstrap
而概念 3 往往僅在公司或團隊內部使用（詳見下文「工具」）。
靈感和實例資源：
Website Style Guide Resources | 收錄大量案例，該項目同時也收錄了相關文章、工具、書籍、播客等。
Find Guidelines | 一個直觀的 Guideline 官方鏈接收集列表。
Brand Style Guide Examples | 同上
All The Style Guides | 同上，託管在 Tumblr ，以博客形式呈現。
______________________________________________________________________________________
方法和工具：
1. Style Guide / Pattern Library：
方法不限，以能夠準確展現視覺設計風格和品牌識別（Identity）的規範為標準。正因其偏視覺化，編寫文檔不是必須的，可直接用圖形編輯軟體產出。例如：
Airbnb UI Toolkit Web
Salesforce1 UI Kit
Housing UI Style Guide
也可藉助工具：
Style Inventory for Sketch | Sketch 插件，基於視覺稿生成 「Style Guide」。
Style Tiles | 用於快速製作「Style Guide」的 PSD 模版，
Frontify Style Guide | Frontify 是一個面向設計團隊的協作平台，提供「Style Guide」生成和「Spec」工具。
CSS Stats | 解析 URl 對應網站的 Style（主要依靠分析 CSS 文件），展示相關信息，比如字體尺寸（font-size）、色板、浮動（float）採用數量等。
Stylify Me | 填入網站 URL，自動生成對應頁面的「Style Guide」。提供 PDF 文件保存。
2. Style Guide / Pattern Library：
因要製作出網頁文檔，且其中含有大量的 Web 組件（代碼片段）和元素（視覺），可藉助前端框架高效產出，比如相對大眾的 Bootstrap，Semantic UI。在大量的自由和開源前端框架項目中，選擇有維護支持，自身喜歡或熟悉的即可。
可用工具：
設計師 Brad Frost 有一套叫做「原子設計（Atomic Design）」的 Web 設計理論，在該領域有一定影響，其核心概念就是復用「Pattern Library」，高率生產 Web 頁面：
Atomic Design | Brad Frost
他為該理論創建了一個開源項目，基於 PHP：
Pattern Lab | Build Atomic Design Systems
Web Starter Kit（HTML, CSS, JS） | Google Web Fundamentals 提供的 Web 生產樣板，支持創建「Pattern Library」形式的文檔。
Style Guide Boilerplate（PHP） | 「Pattern Library」樣板，類似 Pattern Lab。
更多方法類文章和工具列表可參考：
Website Style Guide Resources
50 Style Guide Tools, Articles, Books and Resources | Tuts+
3. Specification (Spec)：
「Spec」應以盡量降低設計師精力消耗，並能讓開發人員清晰理解為標準。提高效率並保證質量的基礎，是選擇合適的工具。
在繪製設計稿所用的圖形編輯軟體中啟用擴展和插件，直接生產「Spec」，高效直擊主題：
specKing | Photoshop（$19，推薦，正在使用）
Specctr | Photoshop, Illustrator（$49 ,PS 和 AI 單獨出售）
Markly App | Photoshop, Sketch（$39.99，PS 和 Sketch 單獨出售）
Sketch Measure | Sketch（自由）
一些其他插件也提供製作「Spec」功能，比如：
PNG EXPRESS | Automated Design Delivery for Photoshop（$29）
Ink | A Photoshop documentor plugin（免費）
團隊協作平台和其他工具：
Avocode | 簡化設計師與開發人員之間的協作流程（Web 產品），提供 Slice（切圖）、Spec、圖層轉 CSS 等功能。
Zeplin | 同樣是一款有質量的設計協作軟體。目前僅支持 Sketch 設計稿，PS 支持仍在開發中。產品處於邀請內側階段。
Frontify | 上文「Style Guide 工具」提到過，屬協作平台，支持對設計稿「Spec」。
分享下我司一些項目的guideline
老闆其實建議做online version 但是實在沒空
我們用github做cms所以我一般在issue里一塊塊一邊和front-dne討論可行性難度係數然後一邊做，最後確定了就放到wiki里
guideline文件我是在sketch里做
因為樣式可以關聯，所以改起來很方便
這個項目的需求並不是在一開始就敲定的，PM一開始設定了初步的timeline，根據timeline把項目分成若干部分。然後是IA,doodles,sketch,wireframe,這個項目由於工期短且需求更新頻繁所以並沒有做prototype,直接做的mockup然後implement
我一般不會從一開始就從guideline做起，而是先挑幾個元素較多較有代表性的page比如這兩個頁面，graph,table,map,timeline，可以通過它們找到共性，確定大致的基調和color code，我的經驗是做的越簡單越好，對比度越高越好，因為之後一些頁面如果涉及到呈現層級較多的情況，會比較好把握和調整。
這個項目只有10%的page元素種類較多，其他的都是table/form，所以我們一直在研究各種table/form的呈現方式，且必須在友好界面和實施難度中作出選擇。
這些是一些比較有代表性的模塊
這些是過程中的嘗試，反覆和clients和front-end溝通最後敲定每一個模塊的呈現方式和流程。
我強調把對比度設的高一點的原因是
比如這個nest table 表裡嵌表再嵌表，我現在是用不斷把灰背景透明度除2來做區分，到了第三級，那個灰已經淡到pc顯示屏根本看不出來了， 所以如果是做淡色背景，一定要保證背景／字／中心內容的對比度比你看著舒服的程度再略高一點，強化對比度比看著舒服要重要的多。
把元素設計的簡單，流程做簡單的原因是
前端實施更方便，因為80%的前端不會去注意太小的細節，而一套好UI的關鍵就是在小細節，如果元素設計的簡單，他們就更有時間把精力放在小細節上。
統一性也很重要，如果花太多時間摳一個小模塊，你做的很漂亮，那除非你可以保證你其他99%的模塊都可以做的跟它一樣漂亮，累啊，其實，有些美女，五官一般，拼一起特好看，我覺得是一樣的道理吧～
樣式越少越好，如果你的UI模塊是一個人，你管理5個人很輕鬆，管理50個人有點累，管理500個人呵呵呵，所以要做減法，減到直到不同的樣式只為不同功能性服務為止。
另一個是worldbank的 這個界面少，比較簡單。
guideline是個越做越有經驗越有感覺的東西，跟做菜差不多，並不是放10克鹽20克醬油就能把菜炒好，需要拿捏，需要多練，而且，好的guideline並不適用於每一個人，每個人的思維方式不同，會有不同的表達方式。
然後一定要不斷的騷擾front-end，他們熟知所有UI element的css庫js庫以及關鍵詞，你拿到關鍵詞去google去dribbble去pinterest去behance會方便很多。
對了，之後有空我會把內容好好整理下放到專欄里去，速度很慢但敬請期待 Guideline #0 - 摸索期 - Work harder - 知乎專欄
http://weixin.qq.com/r/SUzy6onEvNTDrc2J9xlb (二維碼自動識別)
因為我們的項目用到了Bootstrap前端框架，所以設計規範的一些元素是按照Bootstrap來的，另外我們也在一定程度上參考了Material Design以及Ant Design的一些東西，最後結合我們自身產品的特色和涉及到的UI元素總結出了下面這套設計規範。
在這套規範中需要注意幾個問題，尤其是在Web Design中會遇到：
1、字體高度
字體是設計中非常重要的元素之一，很多設計師追求所謂的Perfect Pixel，如果要追求這個，你就必須要對字體有基本的了解，其中就包括字體高度，在Web Design中字體高度稱為行高（line-height）。例如14px大小的字體，其實在行高設置為1.5的Web中高度為21px。
2、柵格布局
柵格布局是Bootstrap裡面的重要概念，而且因為牽涉到響應式，所以設計師必須要對柵格的計算方式了如指掌，我們將Bootstrap的1170px container改成了1160px，所以柵格大小也做了相應調整，尤其需要了解1160px和1140px之間的關係。
3、場景色使用
因為我們產品的特殊性（需要考慮到大量定製和主題），所以色板還是沿用了Bootstrap的場景色方式，不同場景採用不同場景色，一些主題性的地方可以採用主色調。
附上我們的規範，請勿轉載和另行他用，謝謝合作。
2017年我們基於之前的設計規範推出了最新的Codeages Design規範，有興趣的朋友可以看看我的最新文章 知乎專欄 ：）
看到很多不錯的設計規範guideline，忍不住上來回答一下。
如果沒有耐心看下去的，可以直接看我們的online demo: Uskin Components Introduction
這是早期的取色板，可以看到顏色還是比較混亂的，這就涉及到一個典型的問題，顏色是提供高度定製化，像bootstrap一樣呢，還是提供有限的色板，兩者各有優勢和劣勢。
前者的優勢在於色彩、定製的豐富性上，每一個component的顏色都可以毫無關聯；但劣勢也非常明顯——加大了色板的控制難度，換言之，如果用代碼實現的話，由於顏色的不確定性，管理起來非常困難！
後者的優勢在於便於管理，色彩主題的切換非常容易；但由於顏色的可選性不多，因此可能會導致其適用場景的選擇上更加苛刻，或者需要添加額外的色塊來完成整體的設計。
之後，我們做了進一步的優化和整理（下面展示的是另一套theme的色板），但明顯可以感覺到色彩的應用上不像之前那樣雜亂不堪了。
下面的圖大致可以展示一下，其中某些組件老版和新版對比：
下圖是具體某個組件設計過程中的一些思考：
當然本身而言，在建立一套全新的、完整的UI規範時，必不可少的會先參考已有的一些設計，比如：
下圖是之前規劃時的組件列表，現在的組件較之前又多了不少，一開始的demo裡面就可以看到，不小心找到了，就貼在這邊吧。
最後，這些都不是最終成品，限於公司原因，只能展示這麼多，如果對其具體的實現感興趣的，可以移步到：GitHub - icecreamliker/uskin: A front-end framework for developing web projects based on CSS3, and provides common components.
以上。細緻的設計規範在不注重設計的互聯網公司十分難以推行，一方面是節奏變化非常快，你隨時需要應用用戶數據做出改變，二來，你的老闆們哪天不爽，也可以分分鐘推翻你的血汗。
規範到底用來做什麼？
所謂規範，便是對成一定數量的可復用設計或者多設計師協作的設計項目進行量化和約束的東西。如果數量不到一個量級，或者設計師就你一個人，規範的作用力實則非常小，甚至繁瑣程度會影響到正常的設計工作，所以分清你的使用場合，什麼情況下需要用到規範？
規範先行還是設計先行？
規範和設計孰先孰後？我所提倡的規範應該在設計中同步進行，沒有根據設計實踐建立的規範瓶頸過低，經常遭遇各種事先沒有考慮進去的問題，同時在設計中要不斷完善和修復自己的規範。
我們設計一個產品的設計方面的工作流程通常是：
探索 &> 腦爆 &> 草稿 &> 討論 &> 細化 &> 定稿 &> 規範 &> 批量化
所以，先小範圍的將設計雛形生產，在生產過程中不斷的沉澱規範，哪些可以作為規範使用？哪些地方需要靈活處理，這些都需要實踐獲得，當小範圍的設計規範得到驗證後，即可進行批量化生產，此時，所有設計師都可介入生產過程，即使的新加入的設計同事也可以通過規範了解設計規則。
清晰的表達給所有人
規範是面向所有設計師的，你需要讓規範被每個人理解。所以規範需要非常細緻，按照規範的種類類歸，同一種控制項按照多種狀態、不同場景羅列，讓每個設計師都能清晰設計中需要用哪一種，如下圖：
不同數量按鈕時的排列及尺寸規範：
你需要足夠了解你的產品，才能將多種不同場景羅列出來。
你需要足夠了解你的產品，才能將多種不同場景羅列出來。
沉澱你的規範：
規範建立時間，也更需要沉澱，不能一個版本完成就全部推翻重來，這樣就失去了規範的意義，一來你的規範剛剛才逐漸完善就要被拋棄；另一方面，用戶已經有了固定的認知，推翻則是對用戶習慣的挑戰。
僅作拋磚引玉。文中如有錯誤遺漏，還請指正海涵。
UI設計規範，簡單、不難。然而意識到規範的必要性，做好一整套行之有效的規範，很可能是設計師自己多年經驗的結晶。UI設計規範是隨著公司的業務和人員規模擴大，所必然出現的，用於保證設計風格一致，減少設計師彼此溝通成本，減少設計與前端甚至運營溝通成本的，一份文檔，可能是PSD，AI，sketch，網頁。
其形式根據業務和內容的不同，可能劃分為如下形式
一、UIkit ：常用於Web、App設計師之間協作用
設計Web和 App時，可能由多名設計師一同設計。為了保證最終效果的統一，按鈕風格、控制項樣式、間距、都需要做統一。包含所有控制項的一份動態的PSD文件（或.ai/.sketch），可以讓不同設計風格的設計師，產出風格近似的產品。
（來源：
（來源：
優點：快速高效在設計師之間使用
要點：UIkit的設計質量，決定了使用這套UIkit的Web或者App的好壞。
二、UI設計規範的文檔
文檔與UIkit的不同點在於，更詳細和準確，納入了交互與前端的一些內容。對風格，顏色，文字，控制項，交互，圖標，動效，甚至配樂都有了明確的標註。往往是歷經無數次休整與完善，迭代出的結果，而且是一個持續完善的動態文檔。
這個的例子其實比較多，拿最近做的一個比較簡單的項目以作參考。可能在項目初期，是非常簡單直白的。用Sketch生成可供開發查看的Web規範頁。可免標註，且便於相關人員查看。
這裡推薦大家都知道的..
《iOS官方設計指南》《Andriod官方設計指南》
以及推薦閱讀和學習的
Design Guideline 尺度 新浪APP端的設計規範綜述
http://ant.design/docs/spec/easing 阿里的ANT desigh 規範和原則
優點：將複雜而抽象的設計，表現的更明確深入。與非設計人員溝通更加省力。前端將其轉化成web，形成了統一的前端控制項使用規範。
要點：同樣，文檔體現的設計質量，決定了使用這套UIkit的Web或者App的好壞。文檔定的太死會非常影響設計師的發揮，並且改動起來更折騰。設計規範本身要與時俱進的注意迭代。為了保證產出的質量，有時候會犧牲設計本身的靈活性。利弊自知。
三、企業VI/品牌形象
之所以把企業VI放到並不相關的UI設計規範里。是因為兩者很相似，且相關。在服務設計的理念里，UI/VI/品牌形象並不獨立，而在最初的設計里貫穿始終。當然，服務設計並不僅講這個~，這就是另外一個話題了。
這裡我想到一個相對比較好的例子MUJI （當然還有Apple公司～）
從門店實體店到APP和網站，風格色調始終注意保持一致。
UI設計規範本身作為企業設計生產的輔助工具。不必神化，也毋須輕視。重要的是我們所秉承的美學和設計理念，能在點點滴滴中體現出來，最終匯聚成一股力量，成為一個企業的核心競爭力之一。
感謝閱讀...希望有用～
感謝樓上各位的精彩分享，最近根據項目需要，也整理了20個精選規範案例。
設計規範如何寫，這20個精選案例讓你大開眼界
作為一篇乾貨貼，開篇必須來點鎮樓的。
如下為規範匯總頁，裡面囊括了許多大家熟知品牌的規範。
1.Brand Style Guide Examples
Brand Style Guide Examples, Hand-picked by Saijo George
從中大致可以總結出規範的分類：
品牌類（VI）
一般以產品宣傳手冊形式呈現，幫助塑造企業形象。
平台、系統類
面向第三方開發者，介紹平台、系統生態的設計指南，要說明平台理念，開發者要遵循什麼，以及遵循這套規範有什麼好處。
產品業務類
面向產品內部，規範側重在產品設計和實現層面，需要將內容梳理清楚，實用性第一，設計文檔和標註都配好，設計師或者工程師可以直接參考和使用。
根據這三大類，以下精選了各類別的規範案例。
一、BrandGuidelines品牌規範
2. 任天堂角色設計規範（1993年）
Press The Buttons: Mario, Kirby, And Samus Aran Shine In The Nintendo Character Manual
這是一份很早期的設計規範，對每個人物角色以及使用場景都有說明，這對於如今的動畫形象設計有很重要的參考意義。
3. Dropbox
https://www.dropbox.com/branding
Dropbox的這份規範算得上是最為基礎的品牌規範，其對Logo的應用場合進行了說明。如果將此品牌形象擴展到信封、工裝、茶杯等，便是更加完整的VI（視覺識別系統）設計了。
4. Airbnb
Inside our Brand Evolution
Airbnb的品牌進化讓我們感受到了更加開放的品牌文化，它甚至歡迎所有人創造自己的Logo，一起創造Airbnb。
5. Uber
Uber Brand Guide
除了規範內容清晰的梳理外，Uber細膩的動效真的打動了我，這絕對是精美之作。
二、DesignLanguage 平台規範
Apple和Google Guidelines想必是大家最為熟知的平台規範了。面向第三方開發者，這類規範不僅傳遞了平台的設計和開發理念，還告訴開發者需要遵循什麼，以及精選出案例以供開發者參考。
Apple
iOS和OS X HumanInterfaceGuidelines是每位開發者都熟知的平台規範，除此，這裡也推薦一個Apple針對UI通用設計進行的可行示範，和apple watch 和apple tv的規範示例。
6. iOS Human Interface Guidelines
iOS Human Interface Guidelines: Designing for iOS
7. OSX Human Interface Guidelines
OS X Human Interface Guidelines: Designing for Yosemite
8. UIDesign Do』sand Don』ts
UI Design Do"s and Don"ts
9. Apple Watch
Apple Watch Human Interface Guidelines
10. Apple TV
Apple TV Human Interface Guidelines
Google
Google的規範是一個非常好的案例。自Google 提出material design 以來，這份規範對materialdesign的闡釋非常詳盡。不論是規範的框架梳理，還是具體每個模塊的呈現和說明都可圈可點。
11. Material design
http://www.google.com/design/spec/material-design/introduction.html#introduction-principles
12. IBM
IBM Design Language
很多大公司，國外如Apple、Google，國內如騰訊、阿里等，每個公司幾乎都有自己的設計風格。IBM這個規範庫就是告訴你IBM的設計風格是如何定義的。
其中，這份規範還包括下圖還有很多精選圖表設計案例。
三、ProductGuidelines 產品規範
13.MIKADO
InfoJobs Design Styleguides
這是一份寫的非常完整、清晰的產品規範，不僅針對web、ios、andriod平台均有相對應的規範，而且還提供了UI樣式表，這對於設計師復用UI元素非常實用（力薦）。
產品規範除了對每個元素進行尺寸規範外，在基本規範已有的基礎上，可以就某一些特別的產品或者功能進行說明。如下面介紹的MailChimp Email規範，在MailChimp產品規範基礎上，針對Email一些特別情況進行了說明。
14. MailChimp
Email Design Guide
四、Frontend Guidelines 前端規範
Bootstrap和Semantic UI算是很好用的前端開源工具，這也可以看作是一個豐富的前端規範案例。
15. Bootstrap
Components · Bootstrap
16.Semantic UI
Integrations
除此，還有一些結構複雜、式樣繁多的對外產品也會梳理前端規範，就比如下面的Homify、FontShop、MailChimp、LonelyPlanet。
17.Homify
Homify Living Style Guide: Components
18. FontShop
https://www.fontshop.com/styleguide/modules
19. MailChimp
Grid System | MailChimp
20. LonelyPlanet
Lonely Planet Travel Guides and Travel Information
選擇WEB版還是PDF/PPT版？
以上介紹的設計規範主要以WEB版為主，較之於PDF/PPT等靜態文本格式，WEB版的優勢在於：
更加靈活，可以實時修改並更新；
擴展性強，根據需要可以繼續添加模塊；
降低瀏覽成本，打開網址就可以查看規範詳情，省去了下載文件的麻煩。
不得不說
規範多半在產品1.0版本之後才會誕生。對於設計師而言，規範很重要的意義在於解決效率問題，但同時也在一定程度上扼殺了設計師的創造力。待大家有過撰寫設計規範的經驗後，便能更好地把握規範的度，也能找到最有效地撰寫設計規範的方法了。
參考
How To Create a Web Design Style Guide
Inspirational Examples of UI Style Guides
轉載請註明：文章來自微信公眾帳號-yoyofootprint
從我自己實踐和觀察來看，不妨討論一下 UI 設計規範的使用對象及場景：
- 產品和設計團隊參照共享的設計規範。不管是跟外部的用戶體驗設計公司合作，還是內部的設計團隊執行設計，UI 設計規範都是用來體現大家在產品設計溝通後一致確認的方案輸出，以及為後續的產品迭代提供參照依據。
- 為項目相關的技術同事（如前端工程師、iOS / Android 工程師）實際開發和重構提供保障。技術在實際產品開發的時候，往往喜歡模式化，因為開發的工具語言往往有庫、類這樣的模塊化思維。UI 設計規範通過對一系列元素模塊的具體規範，既能與產品開發實現完成對接，同時又便於工程師理解。
那麼何時輸出 UI 設計規範呢？對於 BAT 等大公司來說，產品線眾多，歷史包袱沉重，一般無法形成公司層面非常細緻的 UI 規範，一般以項目團隊為基準。UI 設計規範的輸出時機，一般都是產品高保真界面經過產品、設計和技術共同討論確認後。如果產品的高保真界面 OK，同時內部設計資源相對有富餘，對應的產品設計師就可以整理一份初版的 UI 設計規範，然後後面再填充優化。
UI 設計規範，從目前大家共享出來的方案來看，分為三種類型：- 平台（系統）性質，主要對於其平台內生態的設計指南，例如 Google Material Design 、Apple Watch Human Interface Guidelines、Ubuntu Design；
- 品牌物料，主要提供給媒體、第三方公司等用於公關報道和設計（PS：貌似國內很少看到有這種整理，導致一些媒體報道的 logo 圖片千奇百怪），例如 Dribbble - Logo Downloads Brand Guidelines、LinkedIn Brand Guidelines、https://www.facebookbrand.com/；
- 產品業務相關，主要是產品設計和實現層面的方案，Web 產品居多，同時很多是與前端技術成果相結合，例如 Starbucks Style Guide、Overview | Atlassian Design Guidelines；
UI 設計規範，其內容來看，可分為：
- 品牌 Logo 及相關物料規範；
- 字體排版（Typography），即界面版式設計；
- 顏色（Color）規範，產品主要的顏色庫；
- 圖標庫（Icon）；
- 控制項庫（UI Toolkit），Web 產品與 APP 產品表現形式可能有所差異；
- 視覺框架（Visual Hierarchy），定義產品的交互框架結構，與信息架構相關；
相關資料：
- Find Guidelines On The Web
- Brand Style Guide Examples
- A List of Style Guides, Brand Guidelines, and Front-End Frameworks
- Inspirational Examples of UI Style Guides
- Reimagining Codecademy.com
- Website Style Guide Resources
- How To Create a Web Design Style Guide——結合前端實現
- How to create a design style guide: 25 pro tips
- How to Build a Brand Bible Visual Style Guide
20160808 補充了一些示意圖
————————————————————
去年曾參與過門戶網站以及電商類App的組件化規範製作過程，想來在這方面也積累了一些經驗， 想在這裡和大家分享一下。
主要內容分三方面展開：
第一部分，網頁組件化規範的具體步驟以及注意點；
第二部分，App組件化規範與網頁的區同點；
第三部分，在組件化規範的基礎上製作UI規範的注意點。
／1／瀏覽所有組件
瀏覽網站的所有主要頁面，比如門戶網站的頻道頁以及一級、二級頁面。此步驟要求對門戶網站的所有組件類型有一個全面的了解，比如圖文組件、feed流、登錄註冊等等。
注意點：切記鑽到細節，只需要知道所有的組件類型即可。
將網站中常見的組件形式通過截圖的方式截取下來，並根據組件的類型進行分類歸檔。
注意點：
（1）組件的分類需要結合網站的類型，有側重地劃分、取捨和排優先順序。比如，門戶類常見feed流，而電商類則多見圖文組件。
（2）建議採用截圖的方式而不是用Axure製作，這樣可以避免前期不必要的時間消耗。
在每一類組件下，繼續進行細分、刪減和整合。比如，圖文組件有很多種類型，上圖下文、左圖右文，更細節的有標題＋圖片＋簡介＋評論等控制項。
注意點：刪減哪些組件類型以及對哪幾種類型進行整合，需要根據自身產品的需求進行取捨。
在分類方法上，剛接觸組件化規範的人可能會有些困惑。因為根據圖文數量的不同以及排列順序和方位的不同，會變幻出多種組合方式，這是很大的工作量。
這裡，實際上出現了一個思維誤區。這種通過排列組合進行思考的方式，被稱為「向下」的思維方式，俗稱「鑽細節」。相反，我們更應該採用自下而上的思考方式。具體來說，就是分析網站上搜集到的組件類型以及使用場景，留下常見的組合方式，將個別的組合方式做特殊情況處理。這一步就是利用自身產品的「需求」推動設計決策。
這部分完成後，每類組件下，我們便得到了主要的幾種細分類型。
進行到上一步，我們只是對網站原有的組件進行了規整。但由於設計團隊的更替、網站版本的迭代，現有的組件常常存在大大小小的問題，很可能這種組件已經落後於產品和用戶的需求了。比如，登錄註冊中的密碼輸入功能，從最初的單行輸入，到兩行確認，到明暗文切換，再到明文顯示，這就是一個需求演變的過程。
因此，參考競品就變得很重要了。這一步我們需要利用競品分析，找到符合當下用戶體驗趨勢同時滿足自身產品定位和用戶需求的組件樣式與操作方式，進一步優化組件。
注意點：
（1）競品分析的競品不應只是同類產品，我們此時分析的是組件，因此可以將參考依據細化至使用場景。比如針對登錄註冊組件，無論是門戶網站或者電商網站都有一定的參考價值。
（2）在分析競品時切記照搬照出，無論是產品的定位、頁面的布局、當前的使用場景都是分析的依據。
進行到這一步，我們心裡已經形成對組件布局以及交互方式的大致構想了，可以將此在紙上粗略畫出，接著進行到下一步。
製作文檔初期，需要針對文檔的信息架構以及內容排布，預先制定規則，並在文檔前面註明文檔的使用方式。
注意點：
（1）確定文檔的信息架構時，需要注意組件分級的粒度，比如導航欄有一級、二級導航，圖文組件有左圖右文、上圖下文等，這些分類的粒度不能過粗也不能過細。過粗會導致頁面內容的繁雜，過細則導致信息架構的複雜。此外還需特別注意複合型組件與單元型組件的分組分級方式，如單元型的左圖右文、上圖下文的組件類型以及複合型的標題＋圖片＋簡介＋功能模塊的組件類型。
（2）針對不同組件，其頁面布局都需要遵循統一的規則。 比如，在頭部概述組件的定義以及細分的規則，接著根據示例＋標註＋說明的原則進行內容的詳細說明。
此步驟即為文檔的更新迭代過程。驗證是將規範化組件帶入幾個主要頁面檢驗其適用性以及頁面的整體效果。拓展是在後續頁面設計過程中，將新的組件補充進文檔中。
注意點：
（1）將規範化組件帶入產品進行檢驗時，可將組件進行適當細化和修改以適應頁面需求，但大體規則應符合組件化規範。
（2）補充新的組件時，應注意這個組件在規範中是否已經存在。此外，補充的位置以及分級排序方式都要滿足文檔的分類分級規則。
PART2 App組件化規範
App的組件規範化流程與網頁差不多。特別注意如下幾點差異：
（1）App相對網頁來說更強調整體設計的統一性，比如圖文組件的變式應盡量不超過3種；
（2）App需要考慮跨平台、跨設備的體驗；
（3）App包含多種手勢操作，在此基礎上組件的交互形式也多種多樣。但切忌為了交互而交互，應以需求為前提，避免沉浸在華而不實的交互方式中。
PART3 App的UI規範
在組件化規範的基礎上制定UI規範。同樣需要進行搜集&>分類&>整合&>優化&>製作文檔的過程。最終的UI規範文檔一般都包含組件示例、色值、字型大小、間距以及icon尺寸、按鈕尺寸這幾個部分。
注意點：
（1）無論是色值、間距或者字型大小，對於一個App都需要設定幾個梯度的常用值並適當描述其使用場景。比如，較深的色值用於大標題，淺一些的用於圖文模塊等等。
（2）通常需要代入幾個頁面進行驗證，頁面的選擇最好是一個頁面中能包含多種色值或間距或字型大小等。
總結
以上便是針對網頁和App的組件化規範的製作過程說明。我再將上述內容簡要概括一下：
／1／組件化規範包含5個步驟：瀏覽所有組件&>搜集分類&>整合&>優化&>製作文檔（&>檢驗）
／2／UI規範主要包含：組件示例、色值、字型大小、間距以及icon尺寸、按鈕尺寸
組件化規範需要注意幾點：
／1／分類與分級的標準，考慮組件的適用性與可拓展性；
／2／時刻以符合產品定位於用戶需求為前提，優化組件；
／3／時刻以使用者需求為前提，製作文檔。
（特別註明：UI規範是從交互設計師的角度進行闡述的，相比較而言，會更加註重體驗的效果，希望也能給UI設計師一點啟發。）
前幾個月都在陸陸續續做這件事，中間做著做著就焦頭爛額了，遇到很多一時想不清楚的問題，直到最近才產出一份初具雛形的文檔，不過在規範文檔沒有產出之前就已經在印象筆記中邊設計邊梳理所有的元素以保證界面的一致性，這二天正好在知乎上看到這個話題，就順道來吐吐撰寫設計規範過程中的一些想法~
首先需要想清楚這份規範文檔是給誰使用，偏視覺和偏前端的規範並不一樣，本來自己做之前是考慮給設計師查閱，但編寫的過程中又覺得應該讓前端工程師也能使用，可那樣就意味著得包含相關樣式的代碼，且是網頁格式，思考再三還是決定先專註於視覺設計師這個角色，讓團隊中不同的設計師能夠產出設計語言一致的界面方案為先。而類似於JJ Ying分享的Lonely Planet或Purple: A UI kit for Heroku"s web interfaces這種偏前端的樣式庫我認為可以讓前端工程師去建立。
然後我也認為一套細緻的設計規範對於更新迭代快速的互聯網產品來說性價比不高，很可能好不容易完成了但又要面臨新版本迭代，我的解決方案是出一份像Material Design 中文版式的Style Guide+UI Kit+標註圖搭配使用，這也是受到台灣UI設計師Akane Lee的啟發，可參考她的博文 UI 設計師應該要會寫的文件
下面分別說下這三種產出物的作用
- Style Guide
pdf格式，主要作用是指南。用於說明色相、字體、字型大小、分隔線、間距等這些影響到風格形式的元素如何使用，如何建立層級，為了直觀，需要適當的配上標註圖，並說明界面中各組件的作用和使用場景。組件無需標註，從UI Kit的psd文件中提取即可。
- UI Kit
psd格式，主要作用是提取。設計師可直接拖拽至PS中使用。
- 標註圖
png格式，主要作用是參考。Style Guide中不會包含方方面面場景的情況，如果設計師捉摸不定邏輯上的一致性和合適的層級設定，可以參考更多以前交付給前端工程師的頁面標註圖，我向設計師傳達的一個原則是：除非有更好的方案進行全局替代，否則應盡量使用之前已應用的方案，避免每次迭代都出現新的方案造成不一致問題的放大。
以上便是我目前在使用的方案，且仍在完善中，供各位知友酌情參考，最後附上幾張Style Guide文檔和Web UI Kit的的截圖。
設計規範是在多人合作團隊中、長期迭代的項目中經常出現的一部分，相信大多數設計師也都整理過設計規範。關於設計規範的文章並不少，但最近在整理規範中經歷了苦痛掙扎的我決定好好的總結一番，仔細思考一下與規範整理相關的幾個基本問題，回答問題的同時幫助自己進一步成長，也希望能對大家有所幫助。
為什麼要做設計規範？（why）
如果說工作兩年我養成了什麼習慣的話，那一定是在做任何需求之前，都先問問自己「為什麼要做這件事」。整理規範也是一樣，做之前先要想清楚為什麼要做規範？清楚的了解做一件事的價值有助於我們產生心理認同，從而更好的實施。
1. 保證平台統一性
統一性是交互設計的一個基本原則，在一個長期迭代多人合作的項目中，不同的設計師會負責不同的模塊，每個人都有各自的思路，就有可能會對相同的元素做出了不同的方案，對於用戶來說容易造成困惑，對品牌整體形象的建設也沒有好處。所以對於較大型的產品，最好有設計規範來定義基本的元素，幫助眾多設計師一起做出有統一性的產品。
2. 提升團隊工作效率
對於同一個基本元素，如果沒有設計規範，交互設計師需要設計一次交互方式，視覺設計師需要設計一次外形，UI開發同學需要開發一次，每個不同的設計師遇到這個元素時都可能重新設計一遍。但如果有了設計規範，只需設計一次，團隊中任何一個設計師需要用的時候直接拿來用就可以了，也不需要再進行視覺和開發，極大的提升了效率。
3. 打磨細節體驗
在整理每個元素的規範時，設計師都需要對其場景、狀態考慮清楚。在整理的過程中，經常會發現一些以前沒注意到的問題，並進行優化。把一個小元素單獨拎出來仔細考量，寫成一篇完整規範的過程，其實就是在打磨細節的過程。
什麼時候做設計規範？（when）
雖說最理想的情況是在做設計前把設計準則、風格、規範都定義清楚，但在實際項目中很少能有條件這樣做。項目初期總是小步快跑、先上再說，產品在不斷試錯的同時設計也是在不斷試錯，在一開始就能定義一個完全「正確」的規範其實是不太現實的。
通常情況下，在產品發展日趨平穩，產品定位和品牌形象都比較確定的時候；參與設計的人越來越多，統一性和效率的問題漸漸顯現出來的時候，就是需要定義和整理設計規範的時候。
什麼樣的規範是好規範？（what）
規範是給人閱讀的，寫好一篇規範就像是設計好一個界面，我們也應該確定目標用戶、用戶目標、設計目標後，再進行設計執行。
設計規範的目標用戶有可能只是一個團隊內的設計師，有可能是第三方的工作人員，有可能是公開給所有人都可以查看的。不管是哪種類型的用戶，都會有一個基本一致的目標，那就是「快速的在規範中找到有效信息並獲得指導」。在這個一致的目標下又有所不同之處。
1.團隊內設計師——準確使用
團隊內的設計師通常情況下需要儘可能的依據規範做出「準確」的設計，保證元素使用在正確的場景下，保證整個平台的一致性。所以給團隊內的設計師看的規範相對來說會詳細很多，以騰訊雲內部設計規範為例，需要包含實際的交互場景舉例及說明幫助交互設計師理解和判斷，需要包含視覺標註幫助視覺設計師和UI工程師查閱等。
2.第三方團隊——快速上手
給第三方工作人員的設計規範又有所不同，他們的目標更側重在合作時快速上手，直接將團隊內部詳細的長篇大論拿給他們看很難保證他們有耐心閱讀，因此很難保證他們遵循規範。針對這種情況，更適合整理出典型頁面，UI Kit，加之簡單易懂的說明給他們，讓他們快速了解頁面應該怎麼布局，可以用現成的元素進行快速拼接就可以了。
3.公開大眾——尋求參考
公開給大眾的設計規範有非常詳細的，也有比較簡單直接的，主要還是要根據公開的目的來確定。通常情況下只是起到參考作用的公開指南，內容會比團隊內部的設計規範精鍊的多，大都只是展示定義描述、樣式，再配以正確和錯誤示範幫助理解。而某些公開規範同時起到給合作方使用的功能時，就會包含更多詳細的內容，詳細的描述、視覺標註、代碼等等。
確定用戶目標之後，設計目標就很清晰了，一個好的規範應該是高效的、簡單易懂的，以內部設計規範為例，具體執行時，我們應該確保分類合理、規範本身保持一致、布局排版易讀，來提升設計師查閱的效率；確保定義清晰、描述準確、場景完備，來幫助設計師理解和使用。
1.分類合理
一整套規範的內容通常都很多，為了能讓用戶快速查找，合理的分類必不可少。
2.保持一致
每篇規範包含的內容保持一致、格式保持一致可以給用戶構建心理預期，讓他們看一篇規範就知道每篇都包含哪些部分，可以找到哪些信息。
3.排版易讀
通過合適的字體字型大小、間距留白減少用戶閱讀的疲勞感，圖片與說明清晰的結合，正確和錯誤示例要能明顯區分，使用表格來組織信息。
4.定義清晰、描述準確、場景完備
用簡單易懂的語句進行定義和描述，幫助用戶了解是什麼、怎麼用、哪些場景可用。（規範不可能包含所有場景，但應該包含大多數常見場景。）
如何系統的整理規範？（how）
一.制定一個計劃
整理設計規範是一個涉及廣周期長的項目，所以有一個清晰的計劃可以幫助這個項目更好的推進。制定計劃的流程如下圖所示：
1.整理規範內容及分類
做之前先明確我們需要整理哪些內容，這些內容的分類是怎樣的，下圖是我們整理騰訊雲規範時列的內容及分類，初始時列舉的內容可能不全，但沒有關係，先把最基礎的分類和內容定義好，後續發現有遺漏的內容再添加進去即可。
2.確定優先順序與分工
由上圖可以看出，一整套規範包含的內容非常的多，所以內容和分類整理好後，還需要確定每塊內容的優先順序和分工。從大的模塊上說，首先應當確定整體的設計風格和框架，整體確定後才好確定細節的風格；其次的優先順序最好是控制項、組件、場景，因為控制項組成組件，控 件和組件組成場景，所以先確定小的控制項後，組件和場景更容易確定。至於分工，規範的制定是整個團隊的事情，最好團隊中的設計師都能夠參與，互相分擔工作量以提高規範整理的效率，也能夠確保規範是在大家的討論下制定而成，每個人都參與過並贊同結論。
3.確定規範展示形式及推進流程
其實確定規範展示形式也是確定規範目標用戶，要確定規範是給誰看的，展示在網站上還是直接用文檔承載，網站是否對公眾開放等問題。確定了這些問題後就可以確定規範的詳細程度、大體的展示形式。
推進流程指的是整個項目要怎麼跑，涉及到每個設計師接到分工後如何輸出，何時討論，怎 么輸出，交接給誰等等問題。例如我們的推進流程是每周固定時間開規範討論會，每次確定幾個要討論的內容，負責的設計師整理問題，在會議上和大家一起討論敲定結果，經過兩周討論後輸出最終版本，交給下一個負責人。
4.制定規範的規範
規範本身要遵循什麼規則，也是需要事先確定的，我認為包括兩個部分，一是設計原則，二是輸出物規範。
根據整個產品的目標用戶、用戶及產品目標可以確定我們的設計原則，所有的規範梳理都要遵循最基礎的設計原則，以滿足用戶及產品需求，提升整體的體驗。
之前有提到過規範自身保持一致性是提高規範閱讀效率的一部分，而且為了提升設計師輸出的效率，事先制定好規範輸出物的規範可以幫助設計師按照一個既定的格式進行輸出，同時又能保持一致性。我們的輸出物規範中包括：
1.規範包含的內容，需要有描述、類型及場景、使用說明、視覺規範、補充說明、相關下載、負責設計師
2.規範插圖的尺寸、背景色、板式、字體及用色、正確及錯誤示例圖樣式等
二.單個規範的整理流程
整體計劃制定好之後，就需要開始一個個整理規範內容了。整理單個規範的內容也是有流程可尋的，如下圖所示。下面以整理「對話框」規範為例，講解一下單個規範整理的流程。
1.收集場景
給已經趨於成熟的產品整理規範，第一步就是要先收集場景。以對話框為例，對話框可能出現的地方很多，類型也各有不同，在沒有規範之前，產品中可能會有各種各樣的對話框，每個設計師做的可能都有些差別，所以第一步，是把產品中所有出現過的對話框都收集起來。
2.歸納分類
場景收集完後，就要對收集到的所有場景進行歸類，例如對話框按照樣式不同可以分為「模 態對話框」和「非模態對話框」，在模態對話框中按照功能不同又可以分成「確認類對話框」、「反饋警示類對話框」、「表單類對話框」。歸納分類的作用在於，可以把眾多的場景收攏成幾個典型的種類，只對典型種類進行定義和詳細描述就可以很好的給用戶起到指導作用；同時歸類之後減少了規範對象的種類，更好的保證產品的一致性。
3.給出定義
分類確定好後就可以開始給出定義了，首先給出整個規範對象的定義，例如對話框是什麼，什麼情況下適合用對話框等。除了整體的定義外，每個類型也需要有定義，幫助用戶理解每種類型有何差別，什麼場景選用哪種類別等。
4.優化方案
分類和定義都確定後，需要對各類型進行優化輸出最終的規則，對於這些細節規則，無法確定的時候可以尋找一些優秀案例來參考，例如優秀的產品、有名的設計指南等。同時可以根據實際場景輸出多種優劣不同的方案，和大家一起討論對比。
5.宣講討論
規範整理出後可以在討論會議上同步給大家，最好事先把所有需要大家一起討論確定的問題列出來，把對比方案都做好，提高討論的效率，和大家一起來敲定最終的方案，同時也讓每個設計師都了解規範的細節。
6.最終輸出
所有問題都敲定後即可按照輸出物規範進行輸出，輸出後交接給視覺設計師。
規範整理完之後還有什麼工作？
如所有的設計工作一樣，輸出並不代表完結。
設計稿輸出後還需要確保還原度、保證其正常上線、收集反饋意見不斷進行優化。設計規範也一樣，做完規範後也要確保還原度，推動新的規範落地；不斷收集遺漏的部分補充進規範中，發現問題並不斷優化，持續的維護更新規範文檔。
有了完善的規範如何進行創新？
規範和創新從來都不是對立的。
1.規範不可能囊括所有場景，即不可能所有場景都需要100%遵循規範。
對於一些規範中沒有包含的場景，或者不適合遵循規範的場景，例如一些特殊的運營活動，一些特別的功能點，還是有可以創新的餘地的。
2.體驗好是第一要義。
遵循規範是為了保證一致性從而保證體驗，如果在某些場景下不遵循規範也不會因為影響一致性而影響體驗，反而對特定場景有更好的效果時，不遵循規範也沒什麼關係。
3.規範不是永恆不變的，還有優化的空間。
規範也需要不斷的優化、迭代更新，優化規範本身也是創新的過程。例如樣式風格隨著時間的變化需要更新，例如交互方式也有可能會有新的場景需要補充等等。
整理規範可以鍛煉哪些能力？
寫一篇分類簡單合理，場景、細節考慮完備，展示清晰易讀的規範，也不能算是一件很簡單的事情，需要用到設計師的很多基礎能力，例如：
1.收集信息的能力
在整理規範時，收集場景、收集定義、收集優秀案例都可以鍛煉到我們的收集信息能力，這個基本能力在日常工作中也經常需要用到，例如做需求前需要先收集需求背景相關信息，了解清楚是什麼、為什麼、怎麼做的問題。
2.歸納總結的能力
將收集到的信息進行歸納整理，得出簡單合理的分類的過程，就是鍛煉我們歸納總結能力的過程。在設計時，大到信息架構的設計，小到表單信息分類展示，都需要此能力幫助我們更好的處理信息，更好的將信息展示給用戶。
3.全面思考的能力
我一直認為，全面思考的能力是交互設計師最重要的能力。在整理規範時，既需要對全局全面思考，例如什麼情況適合用對話框，什麼情況不適用，不同類型的對話框應該在哪些場景用等等；也需要對細節全面思考，例如對話框中需要放幾個按鈕、按鈕順序應該怎麼定、按鈕文案怎麼才好理解等等。在日常工作中也是一樣，既要思考全局的問題，例如用戶目標、產品目標、整體使用流程等，也要思考細節的問題，例如異常情況怎麼辦、極限情況有哪些等。
4.清晰表述的能力
在整理過程中和大家討論，可以鍛煉自己的表達能力和說服對方的能力；在輸出規範時，又能鍛煉清晰的描述能力，幫助用戶快速抓住重點。表述能力也是交互設計師的必備能力之一，因為日常工作中經常需要和上下游各類同事溝通、PK，清晰的表述能力可以幫助設計師把全面思考的結果告知他人，並說服他人，推動工作更好的進展下去。
最後
再來回顧一下全文的主要內容：
- 在產品發展到穩定階段、參與的人越來越多時，還是十分有必要整理設計規範的，因為它可以幫助我們提升產品統一性、團隊工作效率以及細節體驗。
- 好的設計規範應該是能讓用戶高效獲取到有效信息的，但針對不同的受眾，規範本身也會有不同的側重點。
- 規範的制定最好能有系統的組織、遵循一定的流程來完成，以確保規範有條不紊的整理和推進。
- 規範輸出後並不代表完成，還需要推動落地、迭代優化、維護更新。
- 有了規範也不代表設計師就沒有創新的空間了，規範和創新從來都不是對立的。
- 整理規範對設計師的基本能力有很好的鍛煉作用，所以各位設計師們整理規範時不要嫌瑣碎麻煩，它可以讓我們慢慢變強！
UI規範，首先有幾種不同的作用或者說側重點。
對象不同：- 面向內部
- 面相第三方開發者
樹立規範的時機不同：
- 在成熟的設計基礎上梳理、總結規範
- 在項目初期開創，制訂規範
這兩處不同，會影響整個「UI設計規範」本身的內容方向屬性等等。
然後要清楚UI規範的作用。UI規範不只是給設計師看的，而且也是給開發工程師看的，UI規範從某些角度可以成為一個面子工程，但一定不能只是一個用來裝X的麵皮。UI規範應該對產品交互，視覺設計，開發實現都有一定的指導性和約束性。
PS: BBC確實是一個比較好的例子，他們特別喜歡搞規範，事無巨細，從Web端到移動端，都是值得參考的範本。
針對上面提到的兩種不同，展開說一下：
對象不同：- 面相內部的規範需要將內容梳理清楚，實用性第一，設計文檔和標註都配好，設計師或者工程師可以直接參考和使用。廢話可以少說，這份規範就是一個工具，乾貨為主。
- 面相第三方開發者的情況，要更加細緻，並且要說明為什麼這麼去做，開發者遵循這套規範有什麼好處。其實這個直接參考Google / iOS 的規範就可以。(MD: Introduction)
樹立規範的時機不同：
- 在成熟的設計基礎上梳理、總結規範，是需要考慮到規範的適用期的，對目前的設計未來可能發生的變化也需要考慮在內。總結和梳理容易，保留可擴展性延展性就需要深入思考了。
- 在項目初期開創，制訂的規範，往往隨著項目的推進會發生很大改變，並且初期的規範一定是面向內部的，所以言簡意賅，規範限制的東西都是界面上最基礎的元素，給UI設計工作進行定調。這種規範應該盡量避免被顛覆，也就是說小步走，快速迭代可能會更合適。
未完待續…… 可能會以我們目前已經整理過的 EUI Design Guidelines 為例，來說一點東西。
--------------------------------------------更新--------------------------------------------
忍不住問：@陳希 Chris 為啥Flyme的設計規範單位不用DP而是PX？？？驚了……設計最有趣的地方在於它的通用性，不論是音樂、建築還是工業，設計的規則大同小異。
轉載一紐約妹子Melissa做的分享：總結了從建築到產品UI的四個設計的基本原則。
一、軸
軸在UI設計中是最基本、最常見的概念，也是用來組織界面結構的重要核心。簡單說來，軸是在設計的時候組織一系列元素的假象線，在下面的設計圖中，軸以虛線的方式被標註出來。
1、對齊
軸最常見於對稱元素的使用，當元素被布置成軸對稱的布局的時候，會給人有序感。就像生活中絕大多數的事情一樣，我們更傾向於享受有序的的東西，它們令人感覺平穩、舒適、平易近人。最簡單的一個例子就是iTunes 程序中的專輯列表的設計，所有的專輯列表在界面的左側保持對齊，圍繞虛線軸軸對稱。
2、強化
雖然軸是一條假想的線，但是如果周圍的元素的邊緣控制得足夠整齊，這跳線會在視覺中變得更加「明顯」的。最好的例子是城市中的路燈構成了道路兩旁建築物之間的軸，如果一邊有建築一邊沒有，那麼這種軸線的感覺不會那麼強烈。
從產品設計的角度上來看，Twitter 的時間線設計就是一個很好的案例，左側的頭像和右側的推文共同塑造出縫隙中軸線的感覺。
3、運動
當我們碰到某先線條的時候，視覺會很自然地沿著這些方向運動，就如同我們站在街上，會自覺地沿著街道的兩頭走動。兩個端點決定了線，界定了開始和結束的地方，線，或者說軸線的存在會引導和提示運動的方向。
SoundCloud中，音軌沿著一條既定的水平軸線運動，隨著音樂的播放，音軌自然地自左向右勻速運動。
4、連續性
如果終點是不確定的，那麼你通常會沿著軸線的方向瀏覽/運動，直到你找到感興趣的東西，或者感到厭倦並關閉應用。在建築學中，未清楚界定的終點非常少見，因為建築的修建通常沒法永遠持續下去，但是UI設計則不一樣，無限地滾動下去是無比受歡迎的設計手法。
Pinterest的APP中就是這樣做的，持續不斷的圖片沿著中軸線的方向持續不斷地滾動下去，只要你有興趣一直觀看下去。
二、對稱
當元素被均勻地放置在軸線的兩側之時，他們構成了對稱的關係。當元素被精準地在軸線兩側一一對應之時，它們就形成了完美對稱。
1、平衡
對稱令整個設計更加平衡。當元素與控制項在軸線兩側處於相同位置之時，會給人以協調和諧的設計感。當我們在規劃街道兩側的房屋建設的時候，如果左右兩側都是5間大小一致的房子，當你走在街上的時候這種平衡的設計會令人非常舒適，這是平衡給人的感受。
Rdio的APP設計就遵循著這樣的設計規則，屏幕兩側的控制項是相同的規格，這類布局很適宜閱讀，用戶會自覺地自上到下，從左向右查看。
2、不對稱
如果軸線兩側的控制項布置不再是一一對應尺寸相近，那就是不對稱的設計。不對稱的設計會給人明顯的失衡感，可能會令人不舒服，但是也能造就殘缺美，當然這要看你具體怎麼做。
雖然Pinteret 的APP設計在整體上是沿著中軸線對稱的（寬度一致），但是兩邊的界面控制項並非是對稱的，它們的高度並不一致，位置也是錯落的。稍微一點的落差都會被眼睛捕捉到，而這樣的差異讓用戶無法準確地左右順序閱讀。不對稱設計打破了設計的平衡性和舒適性，但是也可以緩解了規律性設計帶來的視覺疲勞。
三、層級
當某個元素出現在比其他元素更重要的位置的時候，層級就出現了。
1、尺寸
如果一個設計元素在尺寸上比其他的控制項更大，就會區分出層級。毫無疑問，我們查看某個設計的時候，通常會被最大的元素吸引到。如果一個建築物有5個出窗戶，其中一個是其他四個的兩倍大，我們的注意力自然而然會被吸引過去。
通過尺寸來區分文章列表層級的典型就是稍後讀應用Pocket。頂部的輪播文章擁有更大的圖片，它的位置和尺寸會令我們一眼注意到。
2、形狀
如果一個控制項在形狀和形態上同其他的不一樣，也可以讓它獨立出一個層級。不規則的設計同樣會令人側目。建築物的正面擁有五個相同的窗戶和一閃大門，你會立刻注意到門的獨特之處。
在Instagram的個人信息頁中，圓形的個人頭像在方形的圖片中別具一格，非常抓人眼球。它會讓人意識到，這個獨特的東西，更為重要。
3、位置
位置的存在同樣能彰顯層級的不一樣。在圓圈之內，中心位置的東西比邊緣部分的看起來更重要。位於軸線頂端的控制項會顯得比其他部分的優先順序更高。
以設計應用Path的設計為例，時間軸頂點處的用戶頭像就明顯比時間軸上的其他部分更重要，而這個地方正好展示的也是用戶頭像。
四、韻律
UI設計和建築設計同樣有著韻律之美，重複的模式會營造出獨特的節奏之美。
1、模式
理解韻律最直接的方式就是聽歌。音樂擁有節奏感，絕大多數的音樂遵循著相同的節拍，節拍就是音樂模式的一部分。
這方面最典型的APP是Airbnb，APP列表中每一間房子都佔據一個模塊，模塊中有著大小相同的圖片，價格、位置和房東信息和圖片的相對位置一定，且排版勻稱舒服，兩個模塊之間的間距也相同，當你瀏覽的時候，熟悉的節奏會讓你清楚地知道上哪看關鍵信息。
2、間斷
當節奏被間隔打斷的時候，會形成不同的層級。聽歌的時候，均勻的節奏被其他的音樂元素打斷的時候，你會意識到這是比較特別的部分。
在Twitter的APP中，推文和推文保持著相同的樣式，均勻的節奏，但是其中的「推薦用戶」一項有著不同的樣式，它插入到推文列表中，打破了整個信息流的節奏，凸顯出不同的層級，會很快抓住你的注意力。
文章內容轉載自：紐約設計師教你UI設計的四個基本原則
轉：
原型設計建議規範（一）
現在各種各樣的互聯網產品層出不窮，但是設計水平著實叫人不敢恭維。其實一款產品的設計水平在原型設計階段就幾乎已經決定了。熊先生最近和幾個產品設計的大神接觸，通過從他們那裡的請教學習，簡單的總結了一些關於產品在原型設計規範的小意見，希望對大家有所幫助。
1. 項目類型
正所謂沒有規矩，不成方圓，項目類型的確立對於產品的原型設計來說，應該是第一槍，也是最重要的一槍。如果你連自己想要設計的產品是什麼類型都不知道，那真的是沒人能救得了你了。目前，比較常見的項目類型有以下幾種：移動端（手機、平板）、網頁、桌面。有些原型工具是自帶這種屬性的，比如Mockplus、Justinmind。從項目建立的第一步，就需要確定所設計的原型類型。一般來說，一開始先明確項目類型，對之後的整體布局。組件使用都有著很重要的意義。因為只有知道自己想要的是什麼，才能更好地去規劃如果得到它。當然，這兩款工具也都提供了自由的模式，以服務有其它需求的用戶。
2. 項目樹
項目樹，也就是項目大綱。在產品設計中，項目樹無疑是骨架與核心，指導著整個項目設計的每一個步驟。項目樹對於一個項目來說，更是一個系統的大綱，項目在每一個頁面的設計都要遵照其項目樹中頁面的規定來進行，不可偏差。所以，在確定了項目類型之後，千萬不要馬上就開始設計，而是要冷靜一下，仔細考慮應該如何去安排項目樹。
3. 參考線
參考線應該是設計中最常見也最容易被忽視的一個輔助工具了。如果大家總結一下就會發現，幾乎所有設計工具都會有參考線這一項，不論是做原型的Mockplus，或者是修圖片的PS、AI。而在這些工具中，參考線早已不僅僅只是躺在那裡的一條線而已。比如Mockplus，當一個組件移動到與其它組件相同X、Y左邊，以及中部對齊時，都會自動的產生參考線，方便大家對組件的定位。
4. 對齊分布與比例協調
頁面布局的整潔和有條理，會給設計工作帶來很大的便利。這裡向大家推薦一個比較有效的方法，那就是巧妙的使用羊角螺線。很多設計師覺得，羊角螺線只是適用於具體圖片的設計中，但是實際上，根據羊角螺線設計出來的整體布局並不佔少數，最典型的例子就是蘋果手機的圓角。根據羊角螺線做整體布局還有一個很大好處就是組件的比例會很協調，大小尺寸的銜接過度會顯得不那麼突兀。
以上只是關於原型設計的建議規範的第一部分，下一部分會著重向大家介紹IOS和Web的具體規範。
一、確認目標用戶
在UI設計過程中，需求設計角色會確定軟體的目標用戶，獲取最終用戶和直接用戶的需求。
用戶交互要考慮到目標用戶的不同引起的交互設計重點的不同。
例如：對於科學用戶和對於電腦入門用戶的設計重點就不同。
二、採集目標用戶的習慣交互方式
不同類型的目標用戶有不同的交互習慣。這種習慣的交互方式往往來源於其原有的針對現實的交互流程、已有軟體工具的交互流程。
當然還要在此基礎上通過調研分析找到用戶希望達到的交互效果，並且以流程確認下來。
三、提示和引導用戶
軟體是用戶的工具。因此應該由用戶來操作和控制軟體。軟體響應用戶的動作和設定的規則。
對於用戶交互的結果和反饋，提示用戶結果和反饋信息，引導用戶進行用戶需要的下一步操作。
四、一致性原則
設計目標一致
軟體中往往存在多個組成部分（組件、元素）。不同組成部分之間的交互設計目標需要一致。
例如：如果以電腦操作初級用戶作為目標用戶，以簡化界面邏輯為設計目標，那麼該目標需要貫徹軟體（軟體包）整體，而不是局部。
元素外觀一致
交互元素的外觀往往影響用戶的交互效果。同一個（類）軟體採用一致風格的外觀，對於保持用戶焦點，改進交互效果有很大幫助。遺憾的是如何確認元素外觀一致沒有特別統一的衡量方法。因此需要對目標用戶進行調查取得反饋。
交互行為一致
在交互模型中，不同類型的元素用戶觸發其對應的行為事件後，其交互行為需要一致。
例如：所有需要用戶確認操作的對話框都至少包含確認和放棄兩個按鈕。
對於交互行為一致性原則比較極端的理念是相同類型的交互元素所引起的行為事件相同。但是我們可以看到這個理念雖然在大部分情況下正確，但是的確有相反的例子證明不按照這個理念設計，會更加簡化用戶操作流程。[2]
五、可用性原則
可理解
軟體要為用戶使用，用戶必須可以理解軟體各元素對應的功能。
如果不能為用戶理解，那麼需要提供一種非破壞性的途徑，使得用戶可以通過對該元素的操作，理解其對應的功能。
比如：刪除操作元素。用戶可以點擊刪除操作按鈕，提示用戶如何刪除操作或者是否確認刪除操作，用戶可以更加詳細的理解該元素對應的功能，同時可以取消該操作。
可達到
用戶是交互的中心，交互元素對應用戶需要的功能。因此交互元素必須可以被用戶控制。
用戶可以用諸如鍵盤、滑鼠之類的交互設備通過移動和觸發已有的交互元素達到其它在此之前不可見或者不可交互的交互元素。
要注意的是交互的次數會影響可達到的效果。當一個功能被深深隱藏（一般來說超過4層）那麼用戶達到該元素的幾率就大大降低了。
可達到的效果也同界面設計有關。過於複雜的界面會影響可達到的效果。（參考簡單導向原則）
可控制
軟體的交互流程，用戶可以控制。
功能的執行流程，用戶可以控制。
如果確實無法提供控制，則用能為目標用戶理解的方式提示用戶。
首先是你要足夠了解你的產品這樣才能很清晰的知道哪些地方可以形成規範。
舉例一個app
1.首先你可以把所有界面全部截圖下來，橫向對比你會發現，很多一樣的東西或者類似的東西居然都做的不一樣；
2.你把類似的歸類，比如彈窗，設計出一個公共樣式出來，給出使用規範；
3.你的規範需要非常的詳細，這樣開發看到你的規範後就可以形成代碼模板，後面的開發只需調用公共代碼即可。
擴展
你可以把你的規範做成一個網站，
這個可以參考一下谷歌Material design 的設計規範Color - Style
然後我們可以把所有能形成規範的寫上去，讓開發在你的對應控制項加上代碼（寫上使用方法和調用方法），到時候特別是新來的同事，就可以直接訪問這個網址，同時也能知道怎麼使用，同時你也可以把相關的產品文檔上傳到對應的位置，當同事訪問該規範的時候不僅可以直接下載源文件進行修改，還可以下載產品文檔。
這樣做的好處就是，你這個規範不僅僅是從設計師的角度出發的，是為整個團隊考慮的這樣大家都方便了，才真正成立了一個行之有效的工具。
接下來你就可以不斷的優化規範，開發也可以不斷的優化代碼。
能定規範的一定是要非常容易理解和方便使用的，如果成為一種負擔，或者不能提高效率，那都是不成功的規範設計。
最近我們團隊也制定了非常詳細的規範，用起來之後，發現確實好很多了，以前每條產品線在app上總是各種各樣，現在才慢慢統一，當然效率提升也是必然的。
Design Guidelines分Platform level的Design Guidelines和APP level的Design Guidelines，platform level的參考例子非常多，最近的可以看看android design sites.
先碼一下，有空再答。
JJ有一點說的特別好，寫完後拿給一個開發同事看看，能不解釋看明白，就算通過。
以下回答主要針對移動設備的interaction design。
Platform level Design Guidelines的主要是在平台內，提出平台的設計指導思想（Design principles),及規範主要的常見交互行為 (Definitions for typical interaction behaviors)，主要的目的是去指導其他設計師或者開發人員如何在這個平台上正確的設計與開發產品。在這個主要目的驅使下，如何讓使用者更好的理解平台的設計指導思想就變的更為重要了，就跟練武功一下，這部分是心法，後面的具體規範是招式，正確理解心法，才能真正的融會貫通，以至在同一個方向上創新。
影響Design principles的因素通常除了一些Universal的設計準則以外，它還與產品自身戰略息息相關，主要是從設計的角度去呈現平台想要傳達給用戶的一種感覺感受，個人認為這部分提得越感性越好，因為更容易讓受眾去體會那種感覺，從而在以後自己設計決策中把握那種分寸感，在感性的描述後，也可以加上一些實例，來解釋說明。
這裡可以拿android design principles：
Enchant me (讓哥著迷) Simplify my life(簡化哥的生活) Make me amazing(讓哥變的了不起)
這每個詞google也舉例做了闡述，詳情可以自行搜索「android design"(沒有VPN可以搜索國內的鏡像網站）
定義完Design principles後，還需要定義平台內常見交互行為的規範，這裡有2種思路，一是從平台內的各種UI控制項出發，定義各種控制項的行為規範，包括在什麼情況下可以使用，可以怎麼用及不能怎麼；二是從基本的交互行為出發，比如導航，多選等等，規定這些行為的平台標準流程及控制項。
UI設計規範能保證產品界面的統一性和可持續性，而且在開發和維護的過程中出現人員加入或者更替的情況後，也能保證產品風格的延續，一套詳盡的規範還可以讓相關的工作銜接更為流暢。
規範的分類：
主要包括顏色、字體、排版、樣式、按鈕、表單、圖標、圖片、交互提示、命名規範等方面內容，其中還有些細分類，比如表單。
規範的建立：
建立流程說起來挺簡單，一般是由主設計師在與各方溝通後先著手去設計界面，在不斷修改整理後完成幾個主要界面，照著設計稿再按上方的規範分類一一PS出來，或者圖片+文字的形式在Word里做出來，就 完成了一套UI設計規範。
小技巧：
1、在PS里做完顏色的規範後，導出PNG無損格式，這樣其他人用起來能快速打開來吸顏色；
2、一些規範需在PS的層中以文件夾方式做成PS源文件（文件夾要準確命名），其他人用起來可以直接將分層中的文件夾拉過來直接用，而且方便修改，適合用在按鈕、表單、提示等方面；
3、給前端程序員看的規範再怎麼詳細也不為過；
4、在敏捷式開發過程中，規範可能會在不斷的增加以及小修改，一定要通知到相關人員作修改。
首先分為兩大系統 ios 和安卓 ios為主導那麼咱們以ios舉例
UI設計規範分為幾下幾點
機型區別 6 6p的尺寸和解析度的區別
色彩 整體的顏色風格 標準色 強調 等規範
字體 重要 非重要的字體px的區別規範
icon 圖標的整體風格 尺寸
button 按鈕的規範 包括大小範圍等
整體app的風格 分為幾大風格 單色調 多色彩 數據信息可視化 卡片化 瀑布流 閱讀類 圓形多邊形 大背景圖鋪底
推薦閱讀：