編輯導語：設計驗收是設計師都會經歷的工作流程，但這其中也夾雜著許多問題。本篇文章作者分享了有關設計驗收的工作經驗，從驗收前、驗收中、驗收後展開分析，列舉了具體的解決方法，感興趣的一起來學習一下，希望對你有幫助。
設計驗收是每個設計師都會經歷的工作流程。你可能也曾被這些問題困擾：
前端開發的設計稿還原度，反覆校對浪費大量時間；
線上介面效果差，被認為是設計稿的質量有問題；
設計驗收後的問題很多，怎麼才能向開發清楚地表述檢查出的問題？
這些問題都是常見現象。開發的設計稿還原度也一直是很多團隊在努力提升和克服的工作問題。目前暫時沒有捷徑來完成設計驗收，本文會分享些實用的工作經驗，希望對你有幫助。
一、驗收前：從源頭減少問題的產生
設計稿還原度低的一個重要原因是開發對於設計稿的
細節忽略
或
理解有誤
。在設計稿的交接過程多花些力氣，在驗收時就會更省力。你可以嘗試以下方法：
1. 重視設計交接過程
重視設計稿的
設計說明
和與開發
溝通質量
，消除雙方的資訊差。這樣做一是可以保證開發對於細節理解得準確無誤，二是如果有開發難以實現的效果，可以提前找好替代方案。
2. 總結共性問題
在設計走查中出現的問題如果具有共性，就可以進行總結和沉澱，使用
規則或元件
進行約束。
總結基礎規則：
設計師可以總結開發常會出現的
高頻問題
，比如間距、字號、字重和顏色等細節問題，整理出基礎規則列表，避免類似問題的一再發生。
沉澱通用元件：
設計與開發在
元件層面
完成
一致性
對齊，在元件上的細節分毫不差，在實際應用中就可以減少很多二次修改的時間，開箱即用，減少錯誤的出現。
對齊 Design Tokens：
Design Tokens 作為設計規則的底層架構，可以被用作設計稿和開發稿的溝通語言。Design Tokens 相當於將設計元件進一步拆解，使其
原子化
，將元件的
每一種屬性都轉變為一個前端變數
。Token 本質上就是找到了
元件、屬性和程式碼之間的對應關係
，統一了樣式和前端語言，使元件和設計系統可以被快速管理。你也可以在我之前的文章中看到對於 Token 的更詳細的描述。
3. 加強開發的自查能力
在完成開發後，先進行一輪開發自查，自查的方式以開發習慣為主。這就好像是你在考試交卷前，自己
檢查一遍試題答案再交卷子
，以減少錯誤率。
比如，設計師可以和開發一起做一份基礎的
開發自查表單
，在完成設計稿開發之後，可以先針對開發表裡的內容進行自查。當這些基礎內容沒有問題之後，再交由設計師做更深一步的走查。
再比如有些小廠開發人數不多，設計師也可以嘗試著給開發做
基礎的自查培訓
，介紹設計過程中的關鍵細節，提升開發的細節感受力。
二、驗收中：整理好設計驗收記錄
設計稿的驗收問題要注意整理和存檔，最好使用
公開的實時文件
，或專案排期
進度看板
，全員可見，作為重要的工作證據和追溯資料。
通常來說，設計驗收的輸出物沒有嚴格標準，設計師可以結合自己的工作狀況和習慣，自行處理和輸出，但要注意幾點：
1. 明確目標
設計驗收記錄中需要說明問題出現的原因和想要達到的目標，讓相關人員明確
需要完成哪些工作
，工作完成的
標準
是什麼，以及應該
何時
完成工作。
2. 實時同步
設計驗收結論要共享和同步給所有相關人員，並在相關人員完成任務後及時
更新進度
。
3. 做好存檔
每次的驗收結論命名以日期結尾，做好存檔。每輪驗收和驗收出的每一個問題都要指定到
唯一負責人
，便於問題修改、溝通和追責。
三、驗收後：以制度，克人心
如果驗收效果實在不佳，就要追責到人，除了督促開發完成修改，還要對其工作產生的問題
究其原因
。
可以建立簡單的
評價體系
和精神或物質上的
獎懲制度
，對開發的工作質量進行評估，以制度規範行為。
工作態度是感性而難以約束的；但是工作質量卻是可以使用資料統計、透過分數換算進行評價和判斷的。
舉個誇張點的例子，如果將開發在設計驗收時的錯誤數量和嚴重程度，與其工作的績效考核掛鉤，相信每個人都會做到謹小慎微，認真對待。
作者：元堯，微信公眾號：長弓小子；
本文由@ 元堯 原創釋出於人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議。
