作為一名合格的UI，如果還不會寫UI規范文檔，只是停留在做圖標的階段，那么，要小心了。

我也是這半年來開始習慣了寫規范文檔，并且越來越喜歡這種對各個元素有約束的定義方式。

UI規范文檔移動端開發的相對好寫一些，網上也有很多范本，其實對UI來說，看著范本來寫，并沒有什么難度，無非就是定義一些觸發區域和樣式之類。我自己看過當當的H5規范，微信UI規范，大概了解了風格，后來再寫的時候，就會慢慢形成自己的書寫習慣。

今天就個人經驗談一談UI規范怎么寫更合適。

首先，要明確的是，規范文檔是給誰看的。我們寫UI規范的時候，絕對不是為了讓自己逼格看起來更高，而是為了溝通更高效，以及界面做更少的標注（我自己用的是markman），有些重復性的樣式，反復在界面標注，會導致最后的標注圖密密麻麻，前端攻城獅拿到后也要鼓起勇氣才能看下去，甚至標的太多，攻城獅們就難免有疏忽。一方面，規范文檔交給前端開發，一些通用控件在規范文檔中清清楚楚，看上去也會神清氣爽。另一方面，自己在后續的界面設計過程中，也要參考規范文檔，保證自己設計的界面的前后一致性。

所以，規范文檔兩個受眾，自己以及前端。

其次，規范文檔什么時候開始寫。我的經驗是從界面設計開始的那一刻，就要建立規范文檔了，書寫時，可以按照自己的設計順序，確定好的設計元素都可以陸續加到文檔里，一直到交付設計稿，文檔有可能都是未完成狀態，這里說未完成，是因為交到前端那里，真正開發時，可能會有一些不合理的地方，比如字號、顏色是不是協調、甚至突兀，包括一些CSS樣式是不是不同瀏覽器表現不同等等，根據反饋意見，后期在界面調整的過程中，規范文檔也要一并更新，是以我的規范文檔向來命名 XXX（更新中）。（這么說起來，似乎還沒有最終版呢~）

規范文檔需要貫穿整個界面設計以及產品開發的過程。

規范文檔需要寫什么。這是重中之重，因為產品不同，所以差別也很大，但非常重要的一點是考慮到各種不同的狀態下界面元素的樣式。因為最近的工作都是B/S結構產品的開發，所以就會考慮一些鼠標經過之類的狀態。移動端的規范，個人建議是先參考ios的HIG和google 的material design，尤其是2016年的MD，對各個元素定義的極其詳細，所以省時省力，只需要在此基礎上發揮自己的創意就好。web端不同分辨率下的樣式要考慮到，哪些元素左對齊，哪些右對齊，哪些尺寸限定，哪些可以根據分辨率伸縮，當然了，如果你的團隊采用響應式的布局，這些就不用考慮了。書寫方式的話，因為自己之前有過一些CSS基礎，所以可能會直接把一些CSS樣式寫到文檔中。但畢竟很多UI是平面設計或者其他行業轉過來的，沒有任何代碼基礎，這也絲毫無影響我們的工作結果，只要把樣式表現清楚就可以了，比如加深，變換顏色等等，當然，我個人建議是在PS里實現的效果盡量轉成CSS樣式，這個可以使用一些在線的工具，代碼可以拷貝，非常方便。另外，現在強大的css3真的可以實現各種樣式，所以小伙伴們按鈕之類的就盡量不要再切圖了。

移動端：以平臺規范為基礎。

web端：考慮到多種狀態及定義不同屏幕分辨率的表現。

還有一個問題，就是規范文檔里已經定義好樣式的，界面圖中要不要做標注，我的建議是可以備注上（見規范文檔），不要因為文檔里定義了，就理所當然的認為開發人員一定會理解哪些可以在規范文檔中查找。很多前端沉浸在js的世界中哦。對他們來說，更有成就感的事情或許是寫一堆判斷，而不是100%的復現你的設計文稿。

如果想得到和界面設計效果圖最接近的開發后的樣式，就不要怕麻煩，界面標注中也可以有規范文檔里的內容。

一份好的規范文檔的定義非常簡單，就是當你交付給前端的時候，他在開發過程中不會問你任何問題，當然啦，需要和界面標注配合。但實際工作過程中，這是不可能的，所以多和前端溝通，畢竟實現樣式只是他們工作的一部分而卻是UI工作的全部體現呢。

規范文檔可大可小，附上一份今天完成的一個通用組件的規范。這是我寫過最精簡的了~