推薦閱讀

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

一、設計規(guī)范的主要矛盾

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

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

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

所以問題到底出在哪里？

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

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

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

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

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

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

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

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

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

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

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

為了做規(guī)范而做規(guī)范！

二、UI 設計規(guī)范的常見問題

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

1. 規(guī)范要不要認真設計和導出

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

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

2. 規(guī)范中的組件應該如何處理

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

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

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

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

3. 規(guī)范文件中的版本控制方法

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

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

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

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

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

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

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

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

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

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

5. 規(guī)范里要不要每個細節(jié)都添加說明

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

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

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

結尾

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

我們下篇再賤~

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

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