產品視覺設計大致是由80%產品界面和20%運營設計組成。80%的產品設計，屬于理性，有規(guī)律的部分；而20%運營設計，屬于感性，表達創(chuàng)意的部分。本文想討論的就是這80%理性的產品設計。面對產品不斷迭代，產品框架和結構不斷復雜化，視覺設計師如何對工作流程進行反思和優(yōu)化，從而實現(xiàn)干得更少，做得更多的目的，做一個高效的設計師。

設計語言不統(tǒng)一，組件運用不規(guī)范等情況，大部分互聯(lián)網產品都存在，原因有很多種。而作為產品視覺設計師，觀其表更應審其內。了解產品邏輯，理解交互思維，將視覺相似、功能相近（或其他可界定維度）模塊整合，統(tǒng)一標準。如此既能保證產品功能的完整，又能保證控件統(tǒng)一，視覺可控。

借著起點讀書APP 改版的契機，我們重新梳理了全局 UI 控件，以及設計師之間，設計和開發(fā)之間的合作方式。通過幾個月的實踐，有了一些收獲和心得，沉淀總結出來以供分享和交流。

關鍵詞：組件化和 Libraries 功能。

Libraries 功能是什么？怎么用 → 《實用全面！教你用Sketch Libraries構建組件庫/設計體系》

所謂組件化是將產品設計中重復出現(xiàn)的控件整理歸類，究其共性，以最小顆粒重組，通過整齊排布，并最終以準確易懂的語言來命名；使用過程中既可準確定位，又方便維護和修改，這就是組件化。而 Libraries 功能是 Sketch 中的多人協(xié)作的組件管理系統(tǒng)。了解了這兩個概念，開啟本文正篇。因為產品視覺設計師工作性質問題，此流程優(yōu)化涉及到兩個角色，設計師與開發(fā)。

編者注：什么是組件化設計 → 《進階必讀！可能是最全面的組件化開發(fā)與設計指南》

一、設計師與設計師

1. 以往設計稿維護

以往設計師各自獨立維護設計稿，每個人的習慣各不相同，大致兩類：

• 獨立維護好幾份設計文件（按版本或板塊分割文件），沒有完整的組件庫。
• 擁有一份文件，各個板塊與不同版本堆積在此文件中，擁有獨立的組件庫。

2. 以往合作流程

請隨我們一起走一遍以往的合作流程：

• 設計師甲對視覺稿A的某個共用元素進行改動；
• 口頭或源文件傳播形式告知設計師乙；
• 設計師乙根據(jù)最新改動手動刷一遍設計稿B；
• 設計改動是頻繁的，設計師乙也有改動影響到設計師甲；
• 按照1、2、3的流程再走一遍，如此反反復復。

這樣的合作模式既浪費時間，也在消磨設計師追求完美的意識。我們也嘗試過用很多流程、工具來優(yōu)化這個合作的工作流，包括一些 Sketch 插件，但結果并不理想。而如果設計師在這種損耗中放棄抵抗，最后的結果就是每個人負責的板塊視覺風格迥異，甚至連基本組件也不統(tǒng)一。

3. 現(xiàn)在設計稿維護

Sketch 的 Libraries 功能為這個問題帶來了轉機，這個功能，我們將設計稿與組件庫分開，組件庫單獨存放在云端，設計稿存放云端或本地；設計稿的所有控件調用都從組件庫抓取、同步，也可以不斷向下細分多稿并存，并相互影響。

4. 現(xiàn)在合作流程

更改組件的操作

• 設計師甲更改了組件庫中的某個組件；
• 組件庫保存改動，并實時將改動自動同步到云端；
• 設計師乙的設計稿收到云端同步的提示，并根據(jù)提示點擊同步，乙的文件即完成同步。

添加組件的操作

• 設計師甲在組件庫中添加了部分組件；
• 組件庫保存改動，并實時將改動自動同步到云端；
• 設計師乙需要用到甲新建的控件時去云端拉取即可，不產生重復勞動。

自動化規(guī)范的生成

因為個人習慣，通常項目都會維護一套規(guī)范文件，不過是在項目定稿階段，但是隨著項目周期的拉長，以及不斷的調整變動，規(guī)范文件會因版本過低失去其本身價值。組件庫的應用對這一現(xiàn)狀有了極大的改觀。具體步驟如下：

• 項目空檔期對組件庫的文件進行排版規(guī)整，排布到組件庫的一個子目錄下，稍加命名、排版即可形成初始規(guī)范文件；
• 當設計師修改組件時，組件庫會實時更新；
• 添加組件時，在空檔期把新建的組件再排版到規(guī)范中即可。

如此，組件庫可以始終保證同步。有時效性的規(guī)范，才體現(xiàn)出了規(guī)范的價值。

5. 優(yōu)化后的結果

成本降低

舉一個最簡單的時間的例子，做一張設計稿，若以前要消耗1.5小時；現(xiàn)在用新方法只需要1小時，拆分一下0.7小時是制作組件庫的時間，0.3小時是設計消耗時間。這樣看來其實提高的效率也一般，但是如果把設計稿量放大到100倍，以前的方案需要消耗150小時；但是新方案只需要花費35+15小時，量大了，生產力其實會變的更加高效，因為這100個頁面中公共元素不需要再設計，相似板塊可以復用，所以時間減半。

而其實成本降低最高的體現(xiàn)是后期維護，因為運用了組件庫，不需要以前那樣一處一處的改正。設計初期，工具還沒這么發(fā)達，在 PS 里面做設計稿，改一個頂部欄的樣式可能就需要改動幾十個頁面，而現(xiàn)在維護起來，只需要改動一處，所有共用部分即可實時響應。大大降低了時間，提高了生產力。

交叉同步

交叉同步，不占用各自時間，還可產生雙倍暴擊效果。舉個例子：設計時 A 花1小時修改導航，設計師 B 花1小時修改工具欄。在以往的流程中，雙方可能至少還要花1小時，前期溝通，后期刷稿，而現(xiàn)在這個同步時間幾乎可以忽略了。

修改可見

借用 Sketch 的 Libraries 功能，所有的改動都有列表提示，讓其他設計師可以二次確認，防止意外發(fā)生。

文件變小

設計文件從開始的 187M 減小到 72+7M，7M 是組件庫的大小。設計文件的大小對設計師來說意義還是比較大的，會影響到 Mac 運行效率和設計時的手感。

二、設計師與程序員

與程序員的合作主要是文件交接，以及線下交流，我們主要以文件的交接入手，進行優(yōu)化。

1. 以往提供

視覺標注

以往提供的文件存在以下問題：

• 每份文件都是相對獨立的，出自不同設計師之手；
• 開發(fā)只看視覺標注來進行頁面還原，沒有其他文件做參考；
• 相同板塊因經手的人不一樣開發(fā)出來的效果也可能不同，即產生了重復開發(fā)。

img icon

以往提供的文件存在以下問題：

• 同一個 icon 會產生大量重復切圖（顏色不同的 icon 都需要切圖）；
• 切圖多，App 文件過大；
• img icon 顯示效果比較模糊，體驗較差。

圖形類切圖

以往提供的文件存在以下問題：

• 文件不聚類，沒有總覽；
• 尺寸凌亂，沒有規(guī)章；
• 設計風格不一致，看上去不像同一個 App 的配圖。

2. 現(xiàn)在提供

可能你會產生疑問，這不是提供的文件更多了嗎？不著急，這些文件雖然多了，但其實這是必要的，雖然提供的文件多了，但是花費的時間是變少的，質量也是提高的，我們一個個分析。

控件規(guī)范（半自動化生成）

剛才我已經簡單介紹過控件規(guī)范是如何形成的了，現(xiàn)在我們來看，我們這樣做會帶來哪些具體好處：

思維同步，我們提出的組件化思維跟有追求的程序員的組件化思維是基本一致的，所以在合作中，這兩個角色間的理解程度會相應提高，并慢慢的互相理解，減少了很多不必要的時間浪費。

模塊總覽，起點改版的規(guī)范都是按照類型細分的，定位查找比較方便，既節(jié)省了程序員的時間，也能讓每個組件的還原擁有規(guī)范依據(jù)。

節(jié)約資源，這里舉例來說明，上圖是同一個產品三個頁面的截圖，可以看出同樣的組件，因為是不同的程序員開發(fā)，所以產生了三種不同的前臺表現(xiàn)。這個在產品最終還原中算比較常見的 bug，但也是不能容忍的。而現(xiàn)在通過我們整理的規(guī)范，很容易就可以定位到此控件，并解決問題。

走查定位，其實這個問題剛才的圖也可以解釋這一點，以前設計師都是對比單個設計稿來走查。現(xiàn)在通用組件的走查可以用控件規(guī)范來對比查找。這不僅幫助我們提高了效率，還可以一次性定位大部分頁面的問題。畢竟再優(yōu)秀的設計結果，也依賴于開發(fā)的實現(xiàn)還原。設計師不能只關注視覺稿的交付，也必須要為最終在用戶面前展現(xiàn)的結果負責。所以輸出一份規(guī)范文檔，還是非常有用的。

視覺標注（自動化）

直接推薦插件 Sketch Measure，可以快速生成整套 html 的標注文件。

目錄式表現(xiàn)，上圖中間部分是視覺稿的組件擺放展示，開發(fā)者可以根據(jù)設計師輸出的 html 標注文件準確定位到組件命名，平時的開發(fā)只需要用到視覺標注文件，控件有疑問時，還可根據(jù)命名去規(guī)范文件中查找詳細規(guī)則。

SVG 類 icon（手動但成本很?。?/strong>