團隊設計沉澱：做好 Style Guide 不容易

說起 style guide （即設計規範），大部分人的第一反應就是 material design 和 ios human interface guidelines，我自己就是靠讀這兩份文檔逐漸入門設計領域，國内外的設計師、開發者們自然也是對它們了然于胸。來大公司實習之後，接到的第一個任務就是維護、優化團隊的設計規範網站，同時最近也經常和餓了麼、随手記等網際網路公司的設計師或産品經理探讨如何沉澱團隊的設計。

一個完善的 style guide 是什麼樣的？也許 material design 官網給出了一個範本，從互動、視覺、體驗、開發四個次元入手，全方位诠釋了平台規範一緻性的含義。盡管 material design 目前的推廣還不夠理想，不少細節也可能并不完美，但這并不妨礙國内的設計團隊像它學習。

建構 style guide 并不是一件簡單的事，尤其對于目前快節奏的行業氛圍，從前期就開始沉澱設計内容會耗費很多的精力。就拿設計師來說，有時為了趕項目進度，連命名、标注和切圖規範都不一定能做到細緻，更别提去制作一份詳細的設計文檔了。更關鍵的是，在高速的疊代下，我們通常很難界定一個設計是否能夠稱為規範，也許下個月就大改版了，那前期所做的沉澱不就浪費了嘛。是以，往往很多公司和團隊都是到了一定的産品階段才開始注重 style guide 沉澱，這時的工作重心更偏業務和體驗優化，疊代也更多遵循已有的樣式，規範的重要性才得以展現。但是很容易明白，沉澱這件事，做得越晚，越難做好。

是以第一個問題，我們為什麼需要 style guide？最簡單地說，是為了疊代一緻性和設計開發高效性。

有一份完善的 style guide ，它不會直接給你提供設計稿源檔案，也不會直接告訴你代碼的文檔細節，但是它是一個有效的索引。設計稿可能存在于 ps 或 sketch 中，代碼則往往放在 git 平台上，它們像是你開發疊代産品的工具箱，那麼 style guide 就是這份工具箱的使用說明書。它會告訴你什麼場景下要使用什麼樣的錘子，這把錘子要和什麼釘子結合在一起，使用方法又是怎麼樣的，該有哪些注意事項。是以，通過 style guide 我們最直覺可以看到的就是“元件”，可能會在網站上放不同元件的使用規範，以及設計源檔案和代碼文檔的位址。

這裡引出了一個概念，就是“元件”。我對“元件”的定義就是：一些符合整體平台設計規範，具有較高可複用性且具備完善設計、使用說明，代碼文檔的控件。

是以，元件應當是有比較大機率反複被用到的——比如按鈕、表單、圖檔樣式等；元件也應該易于衍生出新的子元件——比如基于某個表單的子表單，修改了顔色或滾動樣式等；最重要的，元件必須有完善的設計規範和代碼文檔，這才能讓設計師和工程師複用它們時效率倍增。

然而在實際工作中，我遇到的一個最大的問題就是，如何定義一個内容是否為元件。從定義上來說，将一個設計内容确定為元件的成本是不低的，主要除了産出那些必要的資訊以外，還需要特意撰寫設計規範文檔、開發文檔，上傳到某個網站或者伺服器上，最重要的是還需要後期維護。很多内容在用的時候很難推測未來是否會經常複用，在糾結要不要投入精力去做成元件時，往往就放棄了。

另一方面，由于産品的快速疊代，元件更新往往也可能變得很頻繁，這時新增或修改元件還需要一個小組去評估确認，并且要更新相關代碼和文檔，最後還要通過網站讓所有同僚都知道這件事，确實要花費不少的精力。

基于這樣的一些問題，不少團隊的 style guide 都沒有做得太好，畢竟這是一件需要長期督促的工作，一旦有些許的松懈，style guide 就會逐漸落後于極快的疊代速度，漏洞越來越多，沉澱的内容越來越陳舊，最後導緻需要花費更大的精力去維護它，可能慢慢就荒廢了。是以，做好 style guide 就是在和快速疊代賽跑、是在對抗人的惰性，但如果能夠堅持下去，一定會讓團隊受益匪淺。

從這段時間的工作出發，我提出幾個可以幫助有效建構 style guide 的方法和要點。

第一，如果産品規模并不太大，可以考慮建構頁面到元件次元的 guide 形式。

做設計的時候，尤其是在已有的産品頁面上修改，我做的最多的一件事就是截圖。把現有頁面截下來，然後直接在圖上修改，增加新的元件。但是，有些頁面并不是随時可以得到的，比如做支付成功的頁面，或者做退款的頁面，往往需要有一個真實訂單才可以截到這些内容。是以除非你事先就把截圖整理好，不然每次都要去對付這些事，真的挺煩的。

是以，我們可以把産品先子產品化。比如電商産品的 detail 頁是一個子產品，導購是一個子產品，支付交易又是一個子產品，然後把每個子產品的線上界面做好記錄，存放起來。同時，最好在每個頁面旁邊提供這個頁面的設計源檔案下載下傳。另外，在每個頁面上可以簡單注視一下用到了哪些元件，并提供這些元件規範的連結。

這樣做的好處就是，從查找頁面會非常簡單，并且元件以頁面為依托，更容易查找對應的元件，也很友善了解元件的實際使用場景，避免光看規範文檔但是脫離了場景的情況發生。

第二，嚴格要求設計稿的命名規範。

我和開發同學聊下來，使用 style guide 最大的問題就是，經常找不到設計稿裡用了什麼元件。本身元件的命名可能很代碼化，比如xui/button_homepage，當複雜起來之後，光在規範網站上搜名稱是很難定位到目标元件的。是以，除了界面次元的索引，将設計稿中元件命名規範非常重要。

以 sketch 為例，經常我們畫闆的名字是 button copy、button copy copy 3，再加上一些 group 操作之後，甚至連 button 字樣都不見了。如果隻是按鈕，好歹還容易認知，但是如果是面包屑、逃生艙等快速入口，或者複雜的表達，就真的很難定位了。是以在設計軟體中時刻注意每一個圖層的命名，雖然有些繁瑣，但在讓設計稿更嚴謹之餘又能極大地幫助開發同學進行定位，真的很有必要。

第三，嚴格規範元件更新制度。

都說，每件事做到最後，最大的阻礙在人本身，這真的太正确了。 style guide 本身作為一種規範，友善的是設計師和工程師，是以他們對設計沉澱的貫徹程度幾乎直接影響了規範的建立和維護。

一個元件的新增，需要有特定的設計師和工程師來稽核，這個人數不要太多，因為人數越多牽絆就越多。每個元件可以對應到特定的負責人，主要可以是這個元件的設計師和代碼編寫者，同時源檔案必須同步顯示在網站上，讓其他設計師可以直接下載下傳，但若有修改，則應該找負責人來送出稽核。隻要制度執行夠好，這種方式可以平衡精力的開銷。

凡是和稍大的設計團隊同學聊，都會遇到設計規範的問題，是以今天也結合自己的實際工作提出一些想法，希望給大家一定的啟發，也是督促我自己在接下來的工作中把設計沉澱做得更好一些。