前言
產(chǎn)品視覺設(shè)計大致是由80%產(chǎn)品界面和20%運營設(shè)計組成。80%的產(chǎn)品設(shè)計，屬于理性，有規(guī)律的部分；而20%運營設(shè)計，屬于感性，表達創(chuàng)意的部分。本文想討論的就是這80%理性的產(chǎn)品設(shè)計。面對產(chǎn)品不斷迭代，產(chǎn)品框架和結(jié)構(gòu)不斷復(fù)雜化，視覺設(shè)計師如何對工作流程反思和優(yōu)化，從而實現(xiàn)干得更少，做得更多的目的，做一個「高效」但偷懶的設(shè)計師。
設(shè)計語言不統(tǒng)一，組件運用不規(guī)范等情況，大部分互聯(lián)網(wǎng)產(chǎn)品都存在，原因種種。而作為產(chǎn)品視覺設(shè)計師，觀其表更應(yīng)審其內(nèi)。了解產(chǎn)品邏輯，理解交互思維，將視覺相似、功能相近（或其他可界定維度）模塊整合，統(tǒng)一標準。如此既能保證產(chǎn)品功能的完整，又能保證控件統(tǒng)一，視覺可控。
借著起點讀書 APP 改版的契機，我們重新梳理了全局 UI 控件，以及設(shè)計師之間，設(shè)計和開發(fā)之間的合作方式。通過幾個月的實踐，有了一些收獲和心得，沉淀總結(jié)出來以供分享和交流。
關(guān)鍵詞：組件化和 Libraries 功能。
所謂組件化是將產(chǎn)品設(shè)計中重復(fù)出現(xiàn)的控件整理歸類，究其共性，以最小顆粒重組，通過整齊排布，并最終以準確易懂的語言來命名；使用過程中既可準確定位，又方便維護和修改，這就是組件化。而 Libraries 功能是 Sketch 中的多人協(xié)作的組件管理系統(tǒng)了解了這兩個概念，開啟本文正篇。因為產(chǎn)品視覺設(shè)計師工作性質(zhì)問題，此流程優(yōu)化涉及到兩個角色，設(shè)計師與開發(fā)。
一、設(shè)計師與設(shè)計師
以往設(shè)計稿維護
以往設(shè)計師各自獨立維護設(shè)計稿，每個人的習(xí)慣各不相同，大致兩類：
1. 獨立維護好幾份設(shè)計文件(按版本或板塊分割文件)，沒有完整的組件庫。
2. 擁有一份文件，各個板塊與不同版本堆積在此文件中，擁有獨立的組件庫。
以往合作流程
請隨我們一起走一遍以往的合作流程：
1. 設(shè)計師甲對視覺稿A的某個共用元素進行改動
2. 口頭或源文件傳播形式告知設(shè)計師乙
3. 設(shè)計師乙根據(jù)最新改動手動刷一遍設(shè)計稿B
4. 設(shè)計改動是頻繁的，設(shè)計師乙也有改動影響到設(shè)計師甲
5. 按照1、2、3的流程再走一遍，如此反反復(fù)復(fù)
這樣的合作模式既浪費時間，也在消磨設(shè)計師追求完美的意識。我們也嘗試過用很多流程、工具來優(yōu)化這個合作的工作流，包括一些 Sketch 插件，但結(jié)果不甚理想。而如果設(shè)計師在這種損耗中放棄抵抗，最后的結(jié)果就是每個人負責(zé)的板塊視覺風(fēng)格迥異，甚至連基本組件也不統(tǒng)一。
現(xiàn)在設(shè)計稿維護
Sketch 的 Libraries 功能為這個問題帶來了轉(zhuǎn)機，這個功能，我們將設(shè)計稿與組件庫分開，組件庫單獨存放在云端，設(shè)計稿存放云端或本地；設(shè)計稿的所有控件調(diào)用都從組件庫抓取、同步，也可以不斷向下細分多稿并存并相互影響。
現(xiàn)在合作流程
1. 更改組件的操作
a. 設(shè)計師甲更改了組件庫中的某個組件
b. 組件庫保存改動，并實時將改動自動同步到云端
c. 設(shè)計師乙的設(shè)計稿收到云端同步的提示，并根據(jù)提示點擊同步，乙的文件即完成同步
2. 添加組件的操作
a. 設(shè)計師甲在組件庫中添加了部分組件
b. 組件庫保存改動，并實時將改動自動同步到云端
c. 設(shè)計師乙需要用到甲新建的控件時去云端拉取即可，不產(chǎn)生重復(fù)勞動
3. 自動化規(guī)范的生成
因為個人習(xí)慣，通常項目都會維護一套規(guī)范文件，不過是在項目定稿階段，但是隨著項目周期的拉長，以及不斷的調(diào)整變動，規(guī)范文件會版本過低失去其本身價值。組件庫的應(yīng)用對這一現(xiàn)狀有了極大的改觀。具體步驟如下：
a. 項目空檔期對組件庫的文件進行排版規(guī)整，排布到組件庫的一個子目錄下，稍加命名、排版即可形成初始規(guī)范文件
b. 當(dāng)設(shè)計師修改組件時，組件庫會實時更新
c. 添加組件時，在空檔期把新建的組件再排版到規(guī)范中即可
如此，組件庫可以始終保證同步。有時效性的規(guī)范，才體現(xiàn)出了規(guī)范的價值。
優(yōu)化后的結(jié)果
1. 成本降低
舉一個最簡單時間的例子，做一張設(shè)計稿，若以前要消耗1.5小時；現(xiàn)在用新方法只需要1小時，拆分一下0.7小時是制作組件庫的時間，0.3小時是設(shè)計消耗時間。這樣看來其實提高的效率也一般，但是如果把設(shè)計稿量放大到100倍，以前的方案需要消耗150小時；但是新方案只需要花費35+15小時，量大了，生產(chǎn)力其實會變的更加高效，因為這個100個頁面中公共元素不需要再設(shè)計，相似板塊可以復(fù)用，所以時間減半。
而其實成本降低最高的體現(xiàn)是后期維護，因為運用了組件庫，不需要以前那樣一處一處的改正，初做設(shè)計時期，工具還沒這么發(fā)達，在 PS 里面做設(shè)計稿，改一個頂部欄的樣式可能就需要改動幾十個頁面，而現(xiàn)在維護起來，只需要改動一處，所有共用部分即可實時響應(yīng)。大大降低了時間，提高了生產(chǎn)力。
2. 交叉同步
交叉同步，不占用各自時間，還可產(chǎn)生雙倍暴擊效果。舉個例子：設(shè)計時 A 花1小時修改導(dǎo)航，設(shè)計師 B 花1小時修改工具欄。在以往的流程中，雙方可能至少還要花1小時，前期溝通，后期刷稿，而現(xiàn)在這個同步時間幾乎可以忽略了。
3. 修改可見
借用 Sketch 的 Libraries 功能，所有的改動都有列表提示，讓其他設(shè)計師可以二次確認，防止意外發(fā)生。
4. 文件變小
設(shè)計文件從開始的 187M 減小到 72+7M，7M 是組件庫的大小。設(shè)計文件的大小對設(shè)計師來說意義還是比較大的，會影響到 Mac 運行效率和設(shè)計時的手感，當(dāng)然用 iMac Pro 的同行可以飄過。
二、設(shè)計師與程序員
與程序員的合作主要是文件交接，以及線下交流，我們主要以文件的交接入手，進行優(yōu)化。
以往提供
1. 視覺標注
以往提供的文件存在以下問題：
a. 每份文件都是相對獨立的，出自不同設(shè)計師之手
b. 開發(fā)只看視覺標注來進行頁面還原，沒有其他文件做參考
c. 相同板塊因經(jīng)手的人不一樣開發(fā)出來的效果也可能不同，即產(chǎn)生了重復(fù)開發(fā)
2. img icon
以往提供的文件存在以下問題：
a. 同一個 icon 會產(chǎn)生大量重復(fù)切圖（顏色不同的 icon 都需要切圖）
b. 切圖多，App 文件過大
c. img icon 顯示效果比較模糊，體驗較差
3. 圖形類切圖
以往提供的文件存在以下問題：
a. 文件不聚類，沒有總覽
b. 尺寸凌亂，沒有規(guī)章
c. 設(shè)計風(fēng)格不一，看上去不像同一個App的配圖
現(xiàn)在提供
可能你會疑問這不是提供的文件更多了嗎？不著急，這些文件雖然多了，但其實這是必要的，雖然提供的多了，但是花費的時間是變少的，質(zhì)量也是提高的，我們一個個分析。
1. 控件規(guī)范（半自動化生成）
剛才我已經(jīng)簡單介紹過控件規(guī)范是如何形成的了，現(xiàn)在我們來看，我們這樣做會帶來哪些具體好處：
a. 思維同步，我們提出的組件化思維跟有追求的程序員的組件化思維是基本一致的，所以在合作中，這兩個角色間的理解程度會相應(yīng)提高，并慢慢的互相理解，減少了很多不必要的時間浪費。
b. 模塊總覽，起點改版的規(guī)范都是按照類型細分的，定位查找比較方便，既節(jié)省了程序員的時間，也能讓每個組件的還原擁有規(guī)范依據(jù)。
c. 節(jié)約資源，這里舉例來說明，上圖是同一個產(chǎn)品三個頁面的截圖，可以看出同樣的組件，因為是不同的程序員開發(fā)，所以產(chǎn)生了三種不同的前臺表現(xiàn)。這個在產(chǎn)品最終還原中算比較常見的bug，但也是不能容忍的。而現(xiàn)在通過我們整理的規(guī)范，很容易就可以定位到此控件，并解決問題。
d. 走查定位，其實這個問題剛才的圖也可以解釋這一點，以前設(shè)計師都是對比單個設(shè)計稿來走查?，F(xiàn)在通用組件的走查可以用控件規(guī)范來對比查找。這不僅幫助我們提高了效率，還可以一次性定位大部分頁面的問題。畢竟再優(yōu)秀的的設(shè)計結(jié)果，也依賴于開發(fā)的實現(xiàn)還原。設(shè)計師不能只關(guān)注視覺稿的交付，也必須要為最終在用戶面前展現(xiàn)的結(jié)果負責(zé)。所以輸出一份規(guī)范文檔，還是非常有用的，良心建議。
2. 視覺標注（自動化）
a. 直接推薦插件 Sketch Measure，可以快速生成整套 html 的標注文件。
b. 目錄式表現(xiàn)，上圖中間部分是視覺稿的組件擺放展示，開發(fā)者可以根據(jù)設(shè)計師輸出的 html 標注文件準確定位到組件命名，平時的開發(fā)只需要用到視覺標注文件，控件有疑問時，還可根據(jù)命名去規(guī)范文件中查找詳細規(guī)則。
3. SVG 類 icon（手動但成本很小）
矢量圖標的好處毋庸贅述，無論是從設(shè)計角度還是到產(chǎn)品還原角度，都應(yīng)該安利給整個團隊。
a. 靈活多變，可以隨便變化任意尺寸、顏色，而且只需要切一次就解決以前一個 icon 切了幾十個的現(xiàn)狀。
b. 體積小，一個 SVG 格式的 icon，比單個的 img icon 都要小很多。
c. 高清顯示，無論手機屏幕的分辨率是多少顯示都不會失真，強迫癥患者的福音。
4. 圖形類切圖（手動但成本很?。?/strong>
a. 歸類排列，通過以上圖片可以看到，將所有的標簽類切圖或者不需要切圖的部分都已經(jīng)整理到同一個文檔中。不僅如此，其他類型切圖也都有統(tǒng)一整理，這里不一一展示。
b. 用色，尺寸都是在規(guī)范之中，導(dǎo)出也是一鍵式的。
優(yōu)化后的結(jié)果
1. 所有流程可見
整個項目合作中，流程可見，我們的每一步都有跡可循，不會產(chǎn)生冗余工作。
2. 設(shè)計結(jié)果條理清晰
組件庫、規(guī)范文件，以及最終的視覺稿，每個文件的結(jié)構(gòu)內(nèi)容都保持整潔清晰，無論是交接，還是傳播都比較容易理解。
3. 節(jié)省開發(fā)資源
所有組件均有總覽，重復(fù)開發(fā)的問題減少。最終既節(jié)省了開發(fā)資源，也保證還原品質(zhì)。
4. 問題快速定位
這一點主要是影響了后期的開發(fā)還原，前文也提到，視覺走查時，可根據(jù)還原結(jié)果對比規(guī)范，準確定位組件的還原問題，并迅速跟進。
總結(jié)
結(jié)合組件化和 Libraries 功能對視覺設(shè)計流程的優(yōu)化?？梢园l(fā)現(xiàn)設(shè)計師之間，降低了協(xié)作成本，提升了工作效率，變相改善了設(shè)計結(jié)果；設(shè)計師和開發(fā)之間，優(yōu)化交接流程，更可控的交付物，以雙贏的方式推動開發(fā)更好地設(shè)計還原。
后續(xù)我們將深入到組件化的細節(jié)，討論如何構(gòu)建組建化，敬請期待。
