視覺、交互設計師如何完成設計走查？

01-05

經常會聽到有的設計師朋友說：
「開發又沒有還原設計稿。」
「這個動效不是這樣的，我們的開發技術真差。」
產品是設計師的臉，所以設計對此很是重視。
可我也發現，很多設計師工作一完，設計稿一丟，就完事了。

直到最後產品出來測試了，開始吐槽，還原好差。
其實，設計工作完成，設計師的工作遠遠沒有完成，之後的走查流程也是重中之重，那麼正確的走查流程是怎樣的？

謝邀。看到這個問題感覺深有感悟。。剛入行的時候真的是設計工作一完，設計稿一丟就沒事了。。結局。。慘不忍睹，大家一起改改改，改改改（蓋妮馬xxxxx）

在長期改改改的路途中，設計師很多都是沒有耐心在去做一些標註。並且一些設計師辛辛苦苦改好了設計稿後，認認真真標註一整天的結局卻是你們前端或其他程序員並沒有照著你的標註來做，因為他們說自適應不能這樣調整，或者各種理由來搪塞你。結局可想而知，開發做不到還原不說，領導還會覺得是你的鍋。

不知道有沒有人聽過一個故事，說製造一個鞦韆，最後造出來卻是一個木頭，兩根繩子綁著的輪胎。產品到視覺、交互到程序員都是需要一個完整的溝通過程，產品把領導的需求傳達給設計師時，就是希望能做出初步的產品表達，而當他們確認的時候，就是設計師完成的第一步工作。而和開發對接才是接下來最重要的過程，也就是我們所說的走查工作流程：

1.明確清楚我們的目的性：規範界面，給用戶呈現最佳效果和最優質體驗

2.再次確認一遍自己的設計稿在界面上的大小尺寸等等細節問題有無。可用ps play或者skala preview查看。

3.設計完成後，交付給開發的內容：設計稿,切圖（規範的切圖命名、壓縮好的圖片文件），標註，設計規範及交互文檔（包含控制項標準、字體標準等）

4.溝通。先頭任務一定是要溝通清楚，就算交付了上述內容。。開發也很有可能並不去看。。甚至是按照自己的想法去實現。。尤其是移動端的內容。。lz也是深有體會。。

5.檢查。開發完成後。最好盯著檢查下有哪些細節和你的設計稿標註規範等有哪些不同的地方。。要想想這是親兒子。。一手帶大的。。最好和你一樣美美噠QAQ（雖然可能被開發搞死。。

千萬不要再到產品和測試那裡再說。。我們這個產品好醜啊。。交互方式不對啊什麼的。。那質疑的估計不是開發的專業能力，也有你的。。

01.設計走查的作用

前陣子跟幾個同行交流，提到關於交互和 UI 的走查工作問題，所以特地整理了一下，給大家說說關於設計走查的幾個問題。

在很多設計師身上都存在一個現象，就是拿到需求或原型，然後設計完成之後，就以為沒自己什麼事了，也不會主動去找事情做，他們認為到這裡，自己的工作就完成了。

其實到這為止，設計師才做完一半的工作。為什麼呢？

當設計師把設計稿交給開發時，雖然已經標好注、切好圖（交互注釋也很完美），但是不代表開發能把界面表達的跟設計稿完全一樣，甚至會有很大偏差，所以設計師就要做好設計走查工作，盡量跟開發一起把頁面實現的更好，這裡不僅僅說的是UI、也包括交互。

這樣不僅能提高產品的實現度，讓用戶體驗更好，還能促進團隊的工作氛圍，畢竟大家的目標還是一致的。

02.錯誤觀點

當中有一個朋友提到，設計走查應該是測試同學的事情。

首先，我並不否認這位朋友的觀點，但還是局限了。

這位朋友的原話是：「設計只要做好設計的工作，開發也必須做好自己的事情，很好的去實現設計稿，然後測試也要做好自己的工作，找到視覺、交互、開發的所有問題，這才是每個人真正的職責所在。」

三個字總結：理想化。

這是一件不大可能的事情，首先開發要很好的實現設計稿，前提是有一個不錯的開發能力，同時如果還想在不需要設計的幫助下就實現好頁面，那開發本身就要有一個不錯的設計功底，這樣就可以在獨立工作的情況下，相對完美的實現視覺稿。

但是做設計的同學都知道，即使兩個人設計水平相同，他們在臨摹完同一個頁面的時候也會有明顯的差別，更何況是開發用代碼去還原頁面呢？

再者，測試如果要同時找到所有的 UI、交互、開發 Bug，遇到的問題會跟上述開發的問題一樣，同時需要的能力要更高。這是一件幾乎不可能的事情。（可能真有這麼牛逼的人物存在，不過我至今沒見過。）

所以設計師做好設計走查，還是很有必要的。

03.如何做設計走查

那怎麼做設計走查工作呢？

第一步，檢查頁面一致性。包括頭部、尾部等位置是否完整統一，按鈕樣式、反饋狀態、報錯等樣式是否統一；是否有缺少的場景和狀態，根據任務流程對場景和狀態進行排查，保證設計的完整性。

第二步，確保方案的可用性和屏幕上的操作易於使用。設計任務流程，進行設計走查，在移動App端，我們所設計的應用是建立在手指點擊操作的基礎上進行使用的。我們的手指不像滑鼠一樣能夠精確定位和響應，所以我們需要在設計的過程中確保可點擊的區域能夠較為明顯的識別。

第三步，確保文本易於閱讀。文本內容是大部分產品的重要組成部分，所以文本的排版是非常重要的（很多人說中文排版不好看，那是因為你不會用中文排版的方式去做排版）。確保文字清晰、易閱讀是在文字處理上的必須保證的。

第四步，注意顏色對屏幕的影響。Androind 不同的屏幕在色彩飽和度上有較大的差異，比如三星的屏幕亮度和飽和度都比一般機型要偏高。所以在進行設計的時候，選擇的顏色一定要適中，不要偏色。

第五步，Icon 的使用。icon 是代替文字標識的一種圖形，它的價值意義就在於簡化文字，通過圖形來表達功能含義。所以設計的 icon 如果不能表達好，就會造成一定的識別障礙，這也是為什麼我們說設計 icon 是考驗一個設計師功底的技能。

第六步，動效的使用。動效這塊是產品中比較高規格的一個存在，所以在使用的過程中一定要謹慎，不能隨意加入多餘的動效，導致在使用產品的過程中出現問題。

當然，雖然我只說了這六點，但是還有許多其他的東西需要注意，包括新功能提示、熱區的控制等等，這些都是需要設計師去定義的。所以我說開發和測試有時候沒辦法發現這些問題，那設計師做走查的這項工作就必不可少了。

04.走查遇到的問題

有的設計師說：「我們都做好走查工作了，可是開發還是實現的有問題，再溝通就變成吵架了。」

如果到這一步為止，你的任務完成的很好了，實現來說一般不會有什麼問題。如果是一些小差別，實在沒辦法溝通，那可能是開發的問題，也可能是你的設計並不現實，讓開發實現的代價很大，所以要綜合考慮實現因素，不要把責任推給別人，認為就是開發的問題。

同時，希望大家在工作中多投入自己的精力，做好自己的工作，不要完成表面工作就自以為做的很好了。說實話，還差得遠呢~

END.

我覺得只要你把原文件整理清晰，弄好標註切圖，建個說明文檔，確定了控制項標準，再跟程序去溝通就好了，之後就是開發測試，上線迭代了。

有個很奇怪的現象。國外的設計師，除非在校學生，一般是不用帶作品集去面試的。

那他們帶什麼？直接帶產品。互聯網行業的話，就是展示相關的APP，網站之類的。

想想也對，你雇一個設計師，本來就是為了讓產品體驗更加美妙，感官更加精彩。那麼實現出來的產品就是最直接的效果展示。如果一個設計師可以把效果圖畫得天花亂墜，但你的產品都一直還是那樣，你肯定不願意雇這樣的人。

這時有人就會問了，我已經盡責把圖畫得最好了，主要是公司的開發不給力，功能迭代太快等等...但我們確定其他公司的開發會優秀很多，留給設計足夠的時間慢慢打磨嗎？

如果真有這樣的公司，給我們足夠的平台發揮，那麼這些出彩的成果，是不是主要奉獻應該歸他們，而不是設計？

只有想透這點，才是理解設計師的價值是在於把設計實現。能把設計實現的設計師才值得尊重。

因此，走查才成為設計中至關重要的一環。

至於該如何走查，其實也同檢查作業一般，無非是拉開發一塊看看問題。要是不方便記憶，輸出書面的問題列表沉澱，並一一解決即可。

但有一點感悟，就好像人生病了，核心並不是治病，而是如何不用生病。走查也是如此，最重要的並不是嚴謹的走查流程和要求，而是如何不用走查。

是因為設計師不懂實現經常出飛機稿嗎？是因為每次都沒和開發提前說清楚要點嗎？是因為時間太局限而部分效果沒時間實現嗎？一一排查，逐個解決。

最近習得一個設計走查的好方法，願意與大家分享一下。

設計走查的目的：

讓設計師對開發出來的產品，在視覺上相對滿足。
讓設計師體驗『完全態』產品，發現自己原型圖或視覺稿中無法感受到的『設計錯誤』，進而優化自己的設計。

之前在神策數據任職設計師的時候，也經常做設計走查。一般的過程就直接在截圖上進行標註，滿篇都是紅色標註，閱讀體驗不好，而且也不美觀。

最近在使用Zeplin，一開始用它展示設計稿，設計稿的尺寸和切圖它都能很好地搞定。

前兩天發現了一個很有效率的工作流程：

設計稿如圖

開發實現

還原度已經相對很高了，但還是有一些地方設計師實在不能忍，例如右鍵菜單的內padding。有些開發可能對未標註的設計稿中的尺寸不是很敏感，不能和設計師『心有靈犀』，所以會出現一些小差錯。

Zeplin 標註大法

對於要修改的地方，先使用黃色的圈圈標出來。

開發根據設計的標註一個一個排雷，排完的使用修改成藍色的圈圈。

開發有些地方不知道怎麼修改或無法實現的時候，可以在相應的圓圈中評論。

當開發走完一遍，設計再逐個走查，看看小弟弟有沒有認真完成，完成的將藍色的圈圈改成紅色的圈圈。

是不是超棒棒！

這條回復很短，但可能幫助你解決其中一部分的設計走查問題，我本身是一個視覺設計師，走查的本質是對比設計稿和還原效果之間的差別，其實很多時候開發童鞋是沒有相關的工具幫忙他們完成這樣的對比工作，用一些設計軟體來對比，對於開發來說難度又太大。

推薦一款我們內部使用的走查工具，他山石。可以完成90%以上的視覺還原問題的走查和對比配合三個手勢操作可以比較高效的完成日常走查，二期版本還會加入網格、取色等功能。可以試一試，希望對你有幫助。戳這裡他山石 - 打磨的力量

看到了這個問題，下意識的想到了前幾個月的自己。那會做完視覺稿，標註，切圖，扔給開發就萬事大吉了，開發做出來後，有的地方直接懶著吐槽了。

過於理論的流程什麼的就不闡述了，很多大神已經總結的很好了。說一說自己的親身感悟吧，我們公司不算大，主要業務是運營等方面，直到去年才開始在產品方面發力，目前是由一名資深的開發代理PM（我的內心是崩潰的），我負責UE和視覺方面，所以低保真和高保真稿子方面基本不會出現什麼事故。

由於前段時間換了個開發，缺少磨合，所以有些地方有點差強人意，所以不得不改變下方法。想想之前剛入行時，做完視覺後甩給開發一點都不跟進，大體有兩方面原因：第一，實在是懶，懶透腔了；第二，對自己的設計稿沒勇氣，更是不忍直視最終開發出來的界面。。。著重說下現在吧。

首先，在做一些比較複雜的視覺界面時，要先和開發溝通下，效果能否實現，實現出來的代價有多大，權衡利弊，在完成視覺稿後，我會非常非常認真的標註，切圖前先和開發確認哪些地方需要切，哪些不需要（這個最好還是和開發碰一下，畢竟你們的想法總是會有不同的）。比如，一個彈框會有好幾種切法，對於資深的開發和新手開發，你切圖的方式可能就會不同。

其次，有些細微的地方我會提前和開發打好招呼，讓他在布局那些地方的時候叫我，我在旁邊看著他做，哪不協調直接指出改正。。。

最後，每隔段時間（具體時間自己把握，太頻繁了開發也會反感）我會向開發要一個包，裝在我自己的手機上進行體驗，記下不足，再轉交給開發。

以上這簡單的三步肯定是和那些大神們的詳細流程無法比擬的，況且我這也是小公司。但，通過這個方法，自身能感受到，整體效果還是有很大的提升的。哦對了，如果你能丟給開發一份設計規範，你會輕鬆很多的。

最最後說一句，不要把希望全放到測試同學身上，或許他倆是情侶呢......