設計師如何高效驗收？高手深度總結這3點！

在下梳理了近些年經歷的項目中，關于驗收的一些小點～希望能夠幫到你......

高效驗收干貨：

前言

“驗收”在我們設計工作中是必不可少的一個環節，是項目上線前的最后一道質量保障，不僅檢驗開發后的實際頁面跟設計稿的還原質量，也包括發現產品使用后的真實體驗問題。

本文將從“怎樣高效驗收以及驗收中有哪些必須注意的點”來分享，讓設計方案更好落地；

一、協同多方建立“共識”

提高設計還原度從根本上要解決之一的是研發還原度。很多情況下，是因為團隊內大家對用戶體驗的認知不一致，導致目標沒有對齊，所以多方協作前，最好達成下面幾個共識：

1. 提高整個團隊“用戶體驗”意識

很多時候研發測試都對體驗層敏感度較低，所以需要設計-研發-測試三方達成共識，建立落地要求，對最終的產出結果建立相同的目標和預期；

可聯動研發、測試，分享并強化用戶體驗的滲透，引起大家對用戶體驗的重視，再將用戶體驗相關指標寫入研發 OKR、對齊目標，這樣團隊內大家整體用戶體驗意識都會提高，有利于推動設計還原，而且對后續聯動研發做體驗優化項目有很大的幫助；

否則各方自上而下都不重視還原度的問題，對設計還原造成很大的阻力，直接影響上線產品后的用戶體驗。

2. 推動技術建立“自查機制”

提測前，研發對自身負責的功能代碼進行自查，保證視覺還原度在 80%以上，我們再介入設計驗收工作，這樣能大幅提高設計驗收效率，一些比較明顯的視覺問題，能在技術階段被發現并解決，節省大家的時間。

同時最好將設計還原納入測試驗收工作中，不能完全不驗收設計效果（因為很多時候不要求測試走查設計還原度，我們在驗收的時候就會浪費很多時間和精力在那些對照視覺稿就能發現的簡單問題上，反復驗收導致設計與測試的工作量都變大）。

3. 前期充分溝通

在完成設計工作后，一定要跟研發、測試同學以及項目相關利益人進行評審，開會詳細講述頁面樣式、組件規范、動效、交互以及一些特殊細節的還原點，并對一些關鍵體驗問題的實現做詳細溝通，避免理解偏差，比如：是否實現困難、開發成本高、有沒有設計可接受的折中方案等等；

這樣在前期會解決掉很多問題，讓研發理解更為透徹，對開發時間評估也更準確。（避免后期因為時間緊張而影響設計還原、遺漏某些設計效果）

另外，還有一些要注意的 tips：

1. 提前做好上線通知：涉及到標準版本上線，項目確定好上線時間后，需要 PMO 也同步到設計側，這樣方便后續驗收工作的排期；否則在臨近上線時被通知開始驗收，設計排期會被壓縮，設計就需要加班來驗收，因為最近的設計資源都已排滿；
2. 留意設計細節的備注：進入開發之前，一些設計的細節需要跟研發仔細碰一下，比如旁邊的一些設計備注和注意事項，有的研發會自動忽略，導致驗收的時候會有一些間距和切圖的問題；
3. 查漏補缺：跟研發提前打好招呼，如果設計圖上有遺漏的特殊狀態、或者未考慮全的字段長短顯示等效果，都可以隨時跟設計溝通，來提前補漏這些；

重視組件問題：要注意通用組件有調整時，一定要跟研發說明，是新增組件，還是用以前的組件，即使頁面上樣式有變化，但其實用的是同一組件。

（比如：OCR 后置時的輸入框組件，前期評審時研發沒注意到這個樣式有變化，我也沒問這個是不是用的組件，在后期驗收時，研發說的是用的組件，不能修改，否則會影響其他頁面的樣式，也沒時間做新的，但可以在這個頁面做樣式修改，但這樣后面這種組件的樣式就比較亂，不太好統一，所以需求提前做詳細溝通）；

針對會議中遇到的問題及解決方案，記得在群里同步待辦和會議紀要，并周知項目組全員，讓這個會議有始有終。

二、驗收前的準備

在驗收之前，本文梳理了 4 個需要做的準備工作。

1. 提前準備好配置素材

設計師在設計頁面的時候會提前輸出一些運營占位素材。

為了真實地體驗上線后的視覺效果，驗收前幾天，我們需要提前準備好驗收時所需要的切圖素材，比如：金剛位、底部 tab icon、瓷片區素材、banner 等等，壓縮后提供給測試同學，以便在我們驗收之前配置好頁面。

如果沒有提供素材呢？？

你會發現等到你驗收時的頁面簡直無法直視，很多間距沒辦法查看，因為測試同學會隨便配置圖片，他們關注的點是流暢的功能以及極端情況的可用性，對視覺問題不太敏感。這個時間你再提供配置素材，就會壓縮大家的驗收時間，小項目還好，大項目就會讓自己手忙腳亂，時間緊張容易出錯，而且測試也就不是很配合，會收到他們的白眼哈哈哈。

（基本上大家合作順暢后，如果忘記提供素材，測試同學也會提前跟我們索要，不會影響驗收進度）

tips：設計進入驗收環節前，跟測試同學溝通好配置素材的時間節點，提前提供素材壓縮包。

2. 設計文件完整輸出

設計交付前期需要準備的產出物包含：規范、設計稿、切圖標注、動效等文件，避免后期臨時不斷新增、修改設計稿，影響項目開發進度，造成延期風險。

同時我們自己也要進行設計自查，除了檢查交付物的完整性，比如容易遺漏的點擊態、占位符、異常態等頁面，還要格外注意檢查切圖的正確性，是否滿足我們原有的尺寸大小，這個涉及到間距問題，以及組件配置圖片的大小。（比如我們用的藍湖軟件，上傳切圖后需要再檢查每個頁面的切圖，查看大小以及透明度等問題，否則后期開發會有很多問題是切圖范圍的）而且有些切圖需要提前跟研發溝通切片范圍，以防后期跟研發方案有出入又重復修改。

還有一些要注意的 tips：

1. 涉及到重大改版頁面，建議主頁面做雙端設計稿，ios 和 android 端，因為有些間距和字體大小還是不太一樣，這樣前端開發起來也方便，我們驗收起來也少了很多扯皮；
2. 涉及到交付動效時，前期可用 demo 與前端做簡單溝通，商議實現方案的可行性和技術方案難度，來選擇格式是否用 gif、Lottie 或者代碼直接去寫，最后再進行動效設計；

3. 制定驗收標準

為了達到統一的驗收標準，在驗收前期我們需要制定相關規定，有效保證驗收質量。

4. 提前安排驗收時間

當 PMO 在群里同步上線時間后，我們可提前規劃時間，將需要驗收的項目提前安排到自己的排期表里，防止后面遺漏而手忙腳亂，影響驗收進度。

（尤其是一些大的項目要提前介入驗收，且驗收時間都比較久，所以更得提前安排進排期表）

三、驗收中：工作流標準化

在開始介入驗收時，要注意 5 個事項：

1. 內部規范走查文檔

在發現問題這個階段，我們需要輸出完善的線上協作驗收文檔，方便設計、研發、測試、產品多方同學共同去查看編輯，并實時跟進驗收完成進度，追蹤問題進展。

這樣一來不僅會避免大家口頭溝通造成的信息遺漏、溝通誤差等扯皮推諉事件，造成不必要麻煩，同時也為后期復盤做信息儲備。

驗收文檔包含：問題描述、相對應的修改意見、問題優先級、及相關研發人員和完成度。

tips：

問題描述除了要清晰地表達出所在問題，最好再提供還原效果和設計稿兩張截圖的對比圖，這樣會更直觀地反饋問題。

將問題指派給相對應的研發負責人后，最好再標注上是否已修改，方便后面繼續復查該問題，當全部復查完成并達到交付標準，即可選擇該問題已解決。

2. 及時溝通

如有必要的修改，一定要群里同步到相關角色，并及時說明修改原因；（如果悄悄地更新設計圖并沒有同步給研發，可能會給研發帶來不必要的工作量，像藍湖有版本更新記錄，被發現了會直接社死...）

3. 學會拒絕驗收

在剛開始驗收拿到安裝包后，如果發現還原度很低（開發實現效果跟設計稿差異較大），幾乎滿屏都是這樣的錯亂問題，比如：間距、字體、顏色等嚴重不符合設計稿，可拒絕驗收，直接退回重新開發，不接受驗收。（否則驗收成本過高，浪費過多資源在無意義的工作上，也降低了對研發還原度的要求。）

4. 及時協調資源

碰到大項目驗收時，最好再協調組內的其他小伙伴一起幫忙驗收，分別驗收 ios、Android、H5 端，這樣能確保驗收工作正常推進；（之前首頁改版驗收以為自己 3 天能驗完，其實是安卓技術沒有改完問題，因為總有配合度不高的研發；而且碰到狀態比較多的時候，來回切客群，切賬號，都比較耽擱時間）。

5. 關注特殊情況

在驗收中走完主流程后，一定要記得考慮特殊/極端情況，比如：異常/缺省狀態、字符換行、熱區大小、特殊數字、banner 單張不能輪播、原生 H5 導航區別等情況，同時還要關注多端適配、不同機型適配、大小屏內容的展示、保證不同機型的頁面呈現效果一致，包括關鍵信息及操作是否超出屏幕，圖片是否出現覆蓋、拉伸等情況。

還有一些要注意的 tips：

1. 信息加載/上傳后，在固定區域內，顯示內容需要上下可滑動，有時前端會忘記加這個交互點。
2. 涉及到輸入框時，一定要注意鍵盤不能遮擋輸入框；
3. 特殊字體應用時須注意：在各個端(ios/安卓/H5)查看是否基線 baseline 有問題，比如對應的間距問題；像我們用的 din-pro 數字字體，基線在安卓上會往下，所以基本都得調整 padding 或者 margin 去對齊系統，這樣有什么缺點呢，就是后續如果換字體，需要覆蓋替換已有的顯示，還得注意新字體的 baseline 也要低一下，不然就會出現大量的錯亂；所以以后在載入前得驗收一下，看看雙端顯示效果；
4. 安卓驗收時，怎么選擇機型去驗收？因為安卓的手機機型太多，適配也比較麻煩，可以讓技術拉出 APP 用戶的 TOP10 機型，著重驗收這幾款機型。

涉及到配置富文本里面文字和圖片的自適應屏幕問題：圖片適配屏幕，文案適配屏幕換行（但實際沒必要用富文本，因為研發控制不了行高間距等，運營人員配置時看不出來效果，很容易配置的樣式很難看….還不如直接前端寫死樣式）

四、驗收后（上線前）

在驗收完成后，還要注意 4 個事項：

1. 提前準備上線后的運營配置素材

臨上線前期，需要交付給運營同學所需要的設計素材。每個組件都要按照運營提供的文案以及不同客群準備好素材，每個組件都要檢查，有一次就漏掉了一個組件，因為之前運營說新版不配這個，后來臨時要上；

要注意的 tips：

1. 配置前一天再次詢問最近是否有新增素材，根據以往經驗，一般都會臨時有新增，有的需要重新設計，有的則需要兼容新規范尺寸，否則很容易會手忙腳亂。
2. 涉及到需要運營同學配置的顏色，不要加透明度，因為一般后臺配置都不支持透明度選項，否則會出現運營同學配置的顏色跟設計稿不一致的情況；

2. 制定運營配置規范

制定新組件規范時，別忘記輸出運營配置位的規范，主要是為了同步運營同學，這個新組件配置字符時的最長長度以及圖片上傳時的尺寸大小，給予運營配置文案時的顯示參考。

輸出素材時特別注意有些組件會有相似命名，此處要特別標注具體用的是哪一個組件，比如彈窗組件維度下會劃分出好幾種類型：通用型、全屏、雙熱區、自動跳轉等，同樣都是彈窗組件，但實際差異很大，配錯了就會導致線上圖片顯示異常，造成不必要的線上事故。

3. 未解決問題怎么辦

通常很多時候，由于多種不可控因素存在，比如技術方案或者工期等，并不是每個驗收發現的問題都能完美解決。

對于個別未能解決的問題，優先級比較高的，建議研發給出合理解釋，記錄并抄送給相關負責人，標注未來可能出現的風險項，同時可嘗試與產品或項目經理溝通，推動迭代優化的具體時間，避免「下次一定」的無效承諾。

有些來不及修復的優先級低的問題，可跟研發達成一致，放到下次迭代中解決，并同步給產品新增此優化項。

在解決問題的這個過程中，我們可能會發現以前沒注意到的視覺/交互問題，有些是跟設計強相關的，有些則需要研發去研究技術方案；比如多場景下的協議彈窗，因為歷史原因，icon 風格不太統一，且后期有兩兩組合情況，視覺效果會大打折扣，所以需要花時間整理不同場景下的彈窗樣式，后期統一更新視覺風格；還有的比如配置動圖素材建議支持 lottie 技術，就需要推動研發去調研可行性方案。

4. 數據監測

項目上線后，并不代表我們的設計工作就結束了，還需要實時監測該項目的數據變化，判斷該設計方案是否達成核心指標、完成業務目標，以此來驗證該設計方案的價值。根據數據反饋結果，制定相應的優化策略，為后續產品的迭代做數據依據。

結語

驗收是貫穿整個項目全周期的設計流程，團隊高效協作十分關鍵，且隨時根據團隊變化而優化工作流程，多溝通多復盤，才能讓項目更完美地落地。

以上是我在工作中遇到的一些驗收問題以及感悟，分享給大家，歡迎交流～

歡迎關注作者微信公眾號：「渣渣設計1」