我最近對設計規(guī)范（Design Guidelines）很有興趣，收集了不少有用的資料，包括什么是設計規(guī)范，做設計規(guī)范的最佳時機，如何制作設計規(guī)范等，全是精選干貨，在此分享給大家。

什么是設計規(guī)范？

首先是幾家公司的案例，有些網(wǎng)址可能在墻外，麻煩大家自己翻一翻了。

• Salesforce – Lightning Design System（規(guī)范地址）
• IBM – Design Language（規(guī)范地址）
• Google – Material Design（規(guī)范地址）
• Facebook – Brand Guidelines（規(guī)范地址）
• MailChimp – Patterns（規(guī)范地址）
• GitHub – Primer（規(guī)范地址）
• Yelp – Styleguide（規(guī)范地址）

這些設計規(guī)范不盡相同。

有的非常概括，比如IBM的Design Language；有的非常細致，比如Salesforce的Lightning；有的側(cè)重于企業(yè)內(nèi)部復用元素，減少工作時的摩擦，例如MailChimp的Patterns；有的側(cè)重于對接外部的設計，比如Google的Material Design；有的側(cè)重于外觀和模版資源，例如Facebook的Brand Guidelines；有的側(cè)重于代碼，例如GitHub的Primer；有的形式是一個網(wǎng)站，例如蘋果的HIG；有的形式是一個app，例如Airbnb的DLS（僅內(nèi)部可見，不確定，感覺是）。

IBM講了很多high level的設計原則

Salesforce的設計規(guī)范比Material Design還仔細。

MailChimp的規(guī)范寫明了柵格系統(tǒng)，字體字號等各種元素。

Google的Material Design和蘋果的HIG可能是大家最熟悉的設計規(guī)范。

Facebook對外可見的規(guī)范主要是品牌規(guī)范，也有assets可以下載。

GitHub的規(guī)范基本上是一份代碼文檔。

什么時候應該做設計規(guī)范？

做一份設計規(guī)范可能會花不少時間和精力，什么時候應該做設計規(guī)范，又怎樣促使管理層同意這個提議呢？

先說什么時候還不需要設計規(guī)范

在產(chǎn)品初始階段，通常一份Sketch文件就包括了所有設計，只要把Symbol和Styled Text利用好，就可以保證設計的整潔有序了。

在人力不足的時候，建立和維護一份設計規(guī)范是很奢侈的。我自己在小團隊中做創(chuàng)新產(chǎn)品的時候，就選擇把Sketch文件存在Dropbox，頻繁溝通，確保團隊成員了解版本的變更和對他們工作的影響。

什么時候應該考慮制作設計規(guī)范

在一些產(chǎn)品做出一次大的設計變更之后，通常會產(chǎn)生出一份嶄新的全面的設計稿。在這個稿子的基礎上，發(fā)展設計規(guī)范更容易。

舊版的Asana。

Asana經(jīng)歷了一個大改版，很可能會維持這個樣子好幾年，所以適合制作一個規(guī)范。

除了大改版，有時設計師也會做facelift（意為只改外觀，不改邏輯），如果有規(guī)范，就可以依據(jù)規(guī)范一點一點地改，而不擔心會遺漏了。AOL新舊版交替的時候，404頁面就拖了很久，一是優(yōu)先級不高，二是存在感太低很容易被遺忘在角落。

如果旗下有一個以上產(chǎn)品，又想保持品牌的一致性，有設計規(guī)范作參考會容易很多。比如Facebook的F8大會上，設計師曾經(jīng)提到過他們在設計新功能的時候，從設計規(guī)范中把小頭像的縮略圖直接拖到新設計上，復用了這個元素，既節(jié)約時間，也避免了用戶體驗的割裂。

對內(nèi)的規(guī)范應該設置為所有員工都可以瀏覽，部分員工有權更改，每一次更改都需要記錄。在規(guī)范里標明品牌個性，設計原則，各種可復用的元素等等，可以減少設計和開發(fā)之間的摩擦。

平臺型產(chǎn)品可以做一份對外的設計規(guī)范，以統(tǒng)一相關產(chǎn)品的樣式，擴大影響力。唯有統(tǒng)一，才能有區(qū)分度。如果不統(tǒng)一，產(chǎn)品形象會混亂模糊。

與全球的設計師分享制作設計規(guī)范的經(jīng)驗，以及它如何影響了設計流程和團隊協(xié)作。一方面為設計師社群做貢獻，另一方面塑造了重視設計的公司形象，對PR和人才招募有利。

制作設計規(guī)范需要什么？

一個計劃

首先要確定這個項目的scope，明確設計規(guī)范的類別，預估所需要的人力，規(guī)劃項目時間和項目結(jié)束后的安排。

對于設計規(guī)范的類別，如果你的產(chǎn)品是一個復雜的網(wǎng)站，你可能更想做一個動態(tài)的，不斷更新的代碼庫，而不是一個畫滿標注的PDF。確定類別后，可以考慮有哪些內(nèi)容應該加入進去，比如styles，components，patterns等等。

對于人力，依據(jù)團隊的大小有所區(qū)別，有些大公司會有人全職負責設計規(guī)范，小一點的可能有人在主業(yè)之余負責維護這個規(guī)范。

對于項目時間和結(jié)束后的安排，建議用一段時間集中建設設計規(guī)范，然后長期地維護它。

額外加分項是，給這個設計規(guī)范起個好名字吧，像Spotify的GLUE（Global Language for a Unified Experience）就很不錯。

一些經(jīng)驗

• WeWork – Plasma Design System??（文章）
• Airbnb – Design Language System（文章）
• Spotify – Scaling Design at Spotify（文章）

這是三家知名公司分享的設計經(jīng)驗，WeWork的最新也最詳細。除了參考文章，也可以參考下面的其他公司的設計規(guī)范。

作者：酈橙錦妖

來源：https://zhuanlan.zhihu.com/p/24764675

本文由 @酈橙錦妖 授權發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。