編輯導語：設計驗收是設計師都會經曆的工作流程，但這其中也夾雜着許多問題。本篇文章作者分享了有關設計驗收的工作經驗，從驗收前、驗收中、驗收後展開分析，列舉了具體的解決方法，感興趣的一起來學習一下，希望對你有幫助。

設計驗收是每個設計師都會經曆的工作流程。你可能也曾被這些問題困擾：

• 前端開發的設計稿還原度，反複校對浪費大量時間；
• 線上界面效果差，被認為是設計稿的質量有問題；
• 設計驗收後的問題很多，怎麼才能向開發清楚地表述檢查出的問題？

這些問題都是常見現象。開發的設計稿還原度也一直是很多團隊在努力提升和克服的工作問題。目前暫時沒有捷徑來完成設計驗收，本文會分享些實用的工作經驗，希望對你有幫助。

一、驗收前：從源頭減少問題的産生

設計稿還原度低的一個重要原因是開發對于設計稿的細節忽略或理解有誤。在設計稿的交接過程多花些力氣，在驗收時就會更省力。你可以嘗試以下方法：

1. 重視設計交接過程

重視設計稿的設計說明和與開發溝通質量，消除雙方的信息差。這樣做一是可以保證開發對于細節理解得準确無誤，二是如果有開發難以實現的效果，可以提前找好替代方案。

2. 總結共性問題

在設計走查中出現的問題如果具有共性，就可以進行總結和沉澱，使用規則或組件進行約束。

• 總結基礎規則：設計師可以總結開發常會出現的高頻問題，比如間距、字号、字重和顔色等細節問題，整理出基礎規則列表，避免類似問題的一再發生。
• 沉澱通用組件：設計與開發在組件層面完成一緻性對齊，在組件上的細節分毫不差，在實際應用中就可以減少很多二次修改的時間，開箱即用，減少錯誤的出現。
• 對齊 Design Tokens：Design Tokens 作為設計規則的底層架構，可以被用作設計稿和開發稿的溝通語言。Design Tokens 相當于将設計組件進一步拆解，使其原子化，将組件的每一種屬性都轉變為一個前端變量。Token 本質上就是找到了組件、屬性和代碼之間的對應關系，統一了樣式和前端語言，使組件和設計系統可以被快速管理。你也可以在我之前的文章中看到對于 Token 的更詳細的描述。

3. 加強開發的自查能力

在完成開發後，先進行一輪開發自查，自查的方式以開發習慣為主。這就好像是你在考試交卷前，自己檢查一遍試題答案再交卷子，以減少錯誤率。

比如，設計師可以和開發一起做一份基礎的開發自查表單，在完成設計稿開發之後，可以先針對開發表裡的内容進行自查。當這些基礎内容沒有問題之後，再交由設計師做更深一步的走查。

再比如有些小廠開發人數不多，設計師也可以嘗試着給開發做基礎的自查培訓，介紹設計過程中的關鍵細節，提升開發的細節感受力。

二、驗收中：整理好設計驗收記錄

設計稿的驗收問題要注意整理和存檔，最好使用公開的實時文檔，或項目排期進度看闆，全員可見，作為重要的工作證據和追溯資料。

通常來說，設計驗收的輸出物沒有嚴格标準，設計師可以結合自己的工作狀況和習慣，自行處理和輸出，但要注意幾點：

1. 明确目标

設計驗收記錄中需要說明問題出現的原因和想要達到的目标，讓相關人員明确需要完成哪些工作，工作完成的标準是什麼，以及應該何時完成工作。

2. 實時同步

設計驗收結論要共享和同步給所有相關人員，并在相關人員完成任務後及時更新進度。

3. 做好存檔

每次的驗收結論命名以日期結尾，做好存檔。每輪驗收和驗收出的每一個問題都要指定到唯一負責人，便于問題修改、溝通和追責。

三、驗收後：以制度，克人心

如果驗收效果實在不佳，就要追責到人，除了督促開發完成修改，還要對其工作産生的問題究其原因。

可以建立簡單的評價體系和精神或物質上的獎懲制度，對開發的工作質量進行評估，以制度規範行為。

工作态度是感性而難以約束的；但是工作質量卻是可以使用數據統計、通過分數換算進行評價和判斷的。

舉個誇張點的例子，如果将開發在設計驗收時的錯誤數量和嚴重程度，與其工作的績效考核挂鈎，相信每個人都會做到謹小慎微，認真對待。

作者：元堯，長弓小子；

本文由@ 元堯 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議。

,