精選乾貨｜如何製作一套互聯網產品的設計規範？

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

什麼是設計規範？

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

這些設計規範不盡相同。

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

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

Salesforce的設計規範比Material Design還仔細。

MailChimp的規範寫明了柵格系統，字體字型大小等各種元素。

Google的Material Design和蘋果的HIG可能是大家最熟悉的設計規範。

Facebook對外可見的規範主要是品牌規範，也有assets可以下載。

GitHub的規範基本上是一份代碼文檔。

什麼時候應該做設計規範？

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

先說什麼時候還不需要設計規範

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

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

什麼時候應該考慮製作設計規範

在一些產品做出一次大的設計變更之後，通常會產生出一份嶄新的全面的設計稿。在這個稿子的基礎上，發展設計規範更容易。

舊版的Asana。

Asana經歷了一個大改版，很可能會維持這個樣子好幾年，所以適合製作一個規範。

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

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

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

平台型產品可以做一份對外的設計規範，以統一相關產品的樣式，擴大影響力。唯有統一，才能有區分度。如果不統一，產品形象會混亂模糊。

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

製作設計規範需要什麼？

一個計劃

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

對於設計規範的類別，如果你的產品是一個複雜的網站，你可能更想做一個動態的，不斷更新的代碼庫，而不是一個畫滿標註的PDF。確定類別後，可以考慮有哪些內容應該加入進去，比如styles，components，patterns等等。

對於人力，依據團隊的大小有所區別，有些大公司會有人全職負責設計規範，小一點的可能有人在主業之餘負責維護這個規範。

對於項目時間和結束后的安排，建議用一段時間集中建設設計規範，然後長期地維護它。

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

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