總監干貨！5個常見的UI設計規范創建誤區

推薦閱讀

因為最近系統課程講到規范，所以針對設計規范實際創建的誤區做一個簡單的總結。幫助在職的同學改進工作流，也可以幫助新人更好地應對面試中的部分問題。

一、設計規范的主要矛盾

UI 設計規范在原則上是項目必備要素之一，創建規范的邏輯和方法本身也很簡單。但并不意味著規范的創建可以真正發揮作用，它會碰到下面幾個問題：

1. 規范內容太多導致文檔格式和布局的混亂
2. 規范創建后上下游成員都不關注也不遵守
3. 規范的內容用起來太麻煩讓同事怨聲載道
4. 規范創建完第一版以后就難以維護荒廢了
5. 因為規范的限制導致界面設計起來很死板
6. ……

UI 設計規范做起來容易，用起來難，明明應該是提升效率的工具，卻往往變成作繭自縛的累贅。

所以問題到底出在哪里？

分析其中的問題就必須理解 UI 設計規范本身的作用和價值，包含下面這些內容：

1. 標準化設計元素，提高界面的統一性
2. 樣式復用和組件化，增加設計、開發效率
3. 規范設計流程，降低團隊協作成本
4. 書面留檔，便于后續復查和核對

這些作用都很好理解，也很有說服力。但是，設計規范是一種自由度很大靈活度很高的文檔類型，它的創建必須結合項目的實際情況，才能發揮出應有的作用。而很多設計師以為只要把設計規范做好了，就自動可以實現它的作用，這是一種錯誤的想法。

網上有很多設計規范的案例和素材，以常規邏輯來理解，肯定是做的越完整、越細致、版式越有設計感的規范看起來越專業。

這就驅使新人建立一種認知，專業的設計規范就應該大而全，內容詳實，格式完整，設計精美。于是在實際項目中，就會把這些要求轉化成目標，花大量的時間來創建和制作規范本身，而不是以讓規范發揮最大作用的方式去制作規范。

更要命的是，很多設計師或設計團隊，具有“設計潔癖”，比如圖層一定要命名得很清楚，所有編組必須使用自動布局，變體所有屬性和狀態要設置完整等等。這些要求組合起來，就會讓整個組件的制作時長大幅度上漲，雖然可以靠加班加點解決，做完以后看起來也很有成就感。但是，真的有認真考慮過這么做的收益？

一個文檔做得越細致，越全面，就意味著越難調整和維護。在傳統平面行業，品牌 VI 規范這么處理，甚至能做幾百頁打印成厚厚一本規范手冊很合理，因為一套 VI 的生命周期三年起步，中間最多針對一些新場景做補充增量，但不會大量修改 VI 的基礎內容。

但很不幸，我們做的是互聯網產品，注定了迭代是頻發且朝令夕改的。你花了很大力氣整理出來的規范，可能下個版本就要調整，沒幾個月就要大改一次。而過于精細的文檔是很難維護的，除了內容本身的修改、格式的調整、版式的變更，還包括和團隊成員對齊更新內容等一系列操作。這就叫船大難掉頭，所以很多項目規范在做完第一版以后就慢慢荒廢了。

如果有留意大廠規范如 Ant、Arco 的話，往往會發現在開發端已經更新了各種新組件、樣式，但是設計組件庫卻沒有動靜。原因就是調整維護組件庫太麻煩了，即使是大廠團隊也受不了這種工作量。

本質上設計規范就是一種設計團隊和前端開發的規章制度，當我們越想完善規范內容，就是越往章程里添加了更多的條目，我相信誰也不喜歡被這些東西束縛。但恰恰有很多設計師對制定這些套索樂此不疲，并希望團隊成員可以興高采烈地拿起它們把自己給綁了，且要對你的辛苦付出感恩戴德……

所以 UI 設計規范在實際項目的真正矛盾，是設計師沒有根據實際情況考量，建立了過于理想化的目標，從而忽視規范本身的應用屬性：

為了做規范而做規范！

二、UI 設計規范的常見問題

下面，就針對規范中的幾個常見問題來進行分析，分享相關的規范創建思路。

1. 規范要不要認真設計和導出

規范認真設計固然看著舒服，但如果沒有足夠的時間，規范的格式做的很簡陋并沒有關系。確保規范的內容所有人都看得懂，并且方便查看、復制、引用即可，不需要在上面添加美觀的排版和一系列說明。

目前主流的 UI 規范是直接創建在設計軟件的畫布中，文檔型的規范能不做就不做，因為規范本身是需要直接和操作掛鉤的，除了復用外，還包括查看屬性參數。文檔則需要直接添加文字說明，不僅做起來麻煩，而且又臭又長、碎片化的文檔注定沒人想看。只有做甲方項目，或領導明確要求格式情況下，才需要進行導出。

2. 規范中的組件應該如何處理

UI 設計規范通常也直接涵蓋了組件庫的元素，這樣做起來更方便，找起來也更合理。但是組件庫的主要問題，在于如何合理的結合軟件功能，創建方便引用的組件。如果有下載過大型開源組件庫的同學，就應該能看到源文件內一長溜的組件 Page，每次要找到一個自己想要的組件要花不少時間。并且每個組件 Page 內的畫布，又放滿了密密麻麻的不同狀態，看了都讓人頭禿。

這是為了滿足變體的需求，可以在變體面板直接操作開關、選項。看著好像很厲害，但必須強調，變體的實際使用價值非常低……

因為在常規項目設計環節中，組件的多數狀態只需要保留示意稿，但不會在界面設計中直接引用。為多數不需要引用的組件狀態制作變體，除了增加工作量不會得到正面價值。并且越復雜的變體出錯的概率就越大，維護起來就越困難。所以不要在組件制作過程中過度迷信變體的作用，只對最常調用的組件狀態制作變體，否則直接作為普遍分組放在畫板里復制也比做變體有效。

同時一定要減少自動布局的使用量，因為不同組件實現自動布局的邏輯不同，且方法有很多種，這就導致你做的組件別人很難更改，或者過一陣子你自己都不知道怎么修改。這就導致很多時候重新做一個都比修改原來的容易，所以設計師都不喜歡用別人的組件做設計，就是因為低效。

3. 規范文件中的版本控制方法

過去我有分享過，一個項目內規范文件可以作為一個引用文件，被其它設計文件調用。但互聯網產品迭代頻繁，而迭代就意味著版本的更新和變化，那么設計規范怎么應對版本的調整？

很多設計團隊的做法是使用一個固定、唯一的設計規范文件，只對設計文件的版本進行歸檔和管理。

這在項目前兩個版本還好，但隨著版本增多，產生的問題也會越來越多。那就是老的項目文件樣式也會被替換掉了，導致無法在歷史版本中查看過去的具體設計。且設計文件的迭代會對界面畫布有不同的交叉，成為進一步混亂的根源。

所以建議，每次迭代創建一個版本的文件夾，而這里面要復制一個獨立的版本規范文件，不被其它版本引用。

4. 設計規范做完以后沒人關注怎么辦

設計規范不能指望產品、設計、開發、測試認真去看，多數設計規范創建的假設就是沒人會看，就像沒人想看產品說明書一樣，你要讓這個東西足夠易懂，想要使用或查看一看就會。要滿足這個要求，就必須要做好前期的分析 —— 項目需要什么樣的規范？

要分析出對應的結論，就要對下面幾個問題進行思考：

1. 項目有沒有時間留給規范的制作
2. 項目對設計還原度的要求夠不夠高
3. 前端對設計稿實現的意愿和積極度
4. 其他設計師的設計軟件使用習慣
5. 項目的迭代頻率和大改版的間隔

不同的項目需要的規范是不同的，尤其是不同的規范使用對象對規范的需要是不一樣的，你需要圍繞團隊想要的、會用的規范類型去創建，而不是僅僅是追求腦海中 “完美的” 模式。

所以為了進一步實現這個目標，要在規范創建前把規范的結構大綱、前期小樣給團隊檢查、評審，商議出合適的做法。并且在規范基本做完以后，要開一個簡單的培訓短會，對設計和開發解釋規范的所在位置、內容明細、查看方法。總之，規范是結合別人的習慣去創建，而不是根據自己的習慣讓別人適應（你是老板除外），才有人愿意配合使用。

5. 規范里要不要每個細節都添加說明

網上的開源規范說明非常多，所以很多同學問過要不要寫說明，寫的話寫哪些東西，寫到什么程度。

前面就說過，文檔是反人性，所以說明自然是能少就得少。開源框架中添加大量說明，是因為這些系統本身就是產品，要面向數以萬計的用戶進行解釋，所以必須寫得很清楚，對有實際查看需要的用戶進行解釋。而我們自己的項目通常只面向少數產品團隊的成員，就不需要負擔這么重的解釋成本，寫好標題或命名就夠了。只有在不寫下說明就很難保證別人能看懂，或者自己過一陣子都會忘記的設計要素上做說明。

而在我看來一定得做注釋說明的地方，就是前面提到的組件狀態。雖然我們可以不用變體實現它們，但不同的組件狀態切換往往包含了具體的交互過程，很多只看圖是真看不明白它是怎么切換到另一個狀態的。所以我們最好將這些需要通過交互或特殊邏輯產生的狀態進行說明，即使用交互文檔的展示方法連線和備注。

結尾

一套有效的設計規范必然是經過多方面權衡妥協后的產物，檢驗設計師的項目積累和綜合能力，一套規范應該怎么做，只能靠你自己去判斷，而沒有標準的答案。最近 UXBAIKE 在寫新的規范系列新知識庫，很快就會上線。

我們下篇再賤~

作者課程 ????https://pro.uisdc.com

歡迎關注作者的微信公眾號：「超人的電話亭」