以前可能會覺得，設計師應該是自由、隨性、充滿創意的。但在實際工作中，尤其是互聯網產品方面的設計師，因為需要管理自己的工作文檔并且和同事協作溝通，設計流程中的嚴謹與規范顯得尤為重要 >>> 不幸的是，我這大半年的設計工作中都不夠重視這件事；而幸運的是，現在醒悟還不晚。 想看同學的面試經驗？戳：《畢業季專題第二期！揭秘天貓交互設計師面試過程》 圖層管理、命名規范、Style Guide 等等都是再重要不過的內容，每一步偷下的懶，日后都要花費數倍的時間去填坑。 這是我月初時候設計稿某一版的圖層截圖。
可以看到，毫無邏輯可言，僅僅從這張圖看來，根本沒有辦法把設計內容和圖層、命名結合起來，更不要提理解和管理了。Group 都保留了默認命名，無法理解含義；中文英文混合，大小寫混合，無法正常閱讀；邏輯層次混亂，取圖層、選定圖層都比較困難；沒有使用 Symbol 功能（或智能對象），對樣式的管理為零。 很多時候，如果需要在界面中添加一條分割線，你會怎么做？也許你會直接快捷鍵拉一個線條，確定長度和角度后放置到指定位置，就完事兒了。那么，這條線的名字就叫做「Line」，下次復制的時候，新的線條名字就變成了「Line Copy 2」。如果再切換到別的頁面或者創建其他組件，一個混亂的圖層就逐漸成型了。 圖層混亂最大的問題就是迭代煩瑣，包括設計層面的圖層修改和合作層面的切圖等。 一般，一個項目的設計圖最少也有幾十頁，多的可能會有上百頁。如果我在每個頁面中都采用不規范的做法新建「分割線」，比如都采用了 200pt 寬，純黑色的線條，加在一起可能有百來條這樣的線。當項目評審后，要求把線條的顏色改成灰色，你就會默念「真是日了狗了」。想想很容易明白，如果不使用 Symbol 進行樣式管理，每一個線條都要重新編輯一次，還要確保不遺漏、不出錯，工作量絕對驚人。 再說切圖，按照上面這張圖的命名方法，直接切圖給開發，對方基本是看不懂這個規則的，結果就是根本找不到需要的內容在文件夾里的什么位置。而且，編碼過程中的每一個組件也可能是一個對象，也需要對其命名，比如「separator_leftview_long」等，如果你的切圖命名為「Line Copu 2」，請問同事是什么心情呢？ 所以，這次我花費了大量的時間把設計稿從頭到尾整理了一遍，把所有用到的字體樣式、圖層樣式、常用組件都采用 Symbol 進行統一管理，并且確保了所有頁面中同一個組件具備完全一致的命名和樣式。 頁面名稱方面，使用「模塊_內容_備注」的形式進行命名，如下圖所示：
層次方面，讓圖層和視覺順序相對應，圖層本身的命名也采用「類型_位置_備注」的形式進行標注。比如「bar_project_leftview_segnav_selected」指的就是一個條塊，位于 project 模塊下的左視圖次級導航頁面中，功能是標識選中的效果。 對于經常用到的組件如 icon、分割線、按鈕等，使用 Symbol 和字體樣式進行統一管理，并且把它們羅列在 Style Guide 中，一方面便于查找，另一方面切圖的時候只要輸出一份就可以了。如下圖所示： 這樣，無論要求改動哪個內容，都可以「牽一發動全身」，極大避免了重復性工作。 切圖方面，@1x 和 @2x 分別存放，對于樣式類經常需要復用的內容可以單獨導出，然后每個模塊獨有的內容就單獨羅列出來，這樣工程師可以結合設計稿很快地找到所需要的內容。 PS：本次合作的工程師說，@1x 是不需要在命名時單獨注釋的，@2x 則要在文件名尾標出。我第一次還特意手動添上了@1x，多此一舉，倒也學會了這個小要求。
至于標注方面，使用 Zeplin 后真的方便了很多，原本要花不少時間的工作可以避免了，開發也表示看起來更加舒暢。 也許今天這篇文章對于很多有經驗的設計師來說是不值一提的小事，因為確實這都是基本的工作規范。但是對于新人來說，不犯錯可能就不知道這些內容的重要性，所謂吃一塹長一智，做的細致，只會讓你更加專業。 今天收到了最近這幾個月來聽到的最大的表揚，就是「比我們公司的設計專業多了」，繼續加油！