聊聊構建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 本身作為一種規范，方便的是設計師和工程師，因此他們對設計沉澱的貫徹程度幾乎直接影響了規范的建立和維護。

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

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