我們公司前段時間進行了3.0項目的開發，本次項目的進展整體上還是比較順利的，但是還是遇到了很多小插曲，其中最讓人崩潰的就是驗收環節，簡直就是跟技術的一場拉鋸戰。當然這場戰爭的始作俑者并不是某一方，而是每個角色身上都有各種各樣的問題。今天就想來客觀的陳述一下整個過程，希望在下次進行項目推進的時候可以有所改進。
目錄：
前提：之前我們公司對設計還原度要求很低，且技術有較高的話語權，他們就覺得UI界面不重要，所以之前我們是沒有設計驗收環節的，界面的問題提上去也是石沉大海，我們每次進行設計驗收都很沮喪，也不會特別摳細節。
但是最近公司高管有了很大的變動，新來的CEO、CTO和產品總監都對設計要求特別高，當然也就特別看重線上效果，所以就有了這次正式的設計驗收環節。
首先，我想總結一下我們在這次驗收中遇到的幾個主要問題：
首先檢討一下設計同學的問題，為了圖自己省事，直接用Sketch Measure 導出標注文件給到技術了，對于有適配需要的地方也沒有進行單獨的標記和說明。所以技術同學就會按照自己對頁面的理解進行布局，到驗收的時候設計同學才發現不是自己想要的結果，這個時候要改動的話就會比較困難。因為一開始的框架就不對，技術也沒有時間重新寫一遍，所以就會有很多問題被擱置。
直接導出的標注對界面的準確性要求也特別高，你必須保證所有的界面都準確無誤，不然就會遇到開發者提出的來自靈魂的質問：“為什么這里是15px，那里是16px，兩邊不一樣，究竟讓我們怎么寫？”
聽到這句話是不是有點不服，但是就是你錯了呀。所以時間允許時還是要手動標注，不但可以減少這種質疑，在標注的時候還會對頁面的細節進行盤查，會發現一些遺漏的狀態和缺失的細節，這樣下來最終提交給技術的設計稿會更加完善。
再者，缺少設計稿評審的環節，這個環節主要給技術講述一些適配要求、交互狀態及動效（我們公司近期撤了交互崗位，所以交互的相關工作需要設計同學進行考慮）；同時解答技術同學的一些疑問，這樣就能將一些可預見的問題解決掉，解決后期的溝通成本。
解決方案：
這個首先當然是設計師的失責，因為我們提交給技術的設計稿的第一要素就是完整度，到開發進入尾聲才發現缺失，那技術同學只有說“對不起，排期吧”。然后設計同學還一肚子委屈，覺得開發不配合。
下面是設計稿中常見的缺失內容：
這些都應該是在出設計稿的時候就考慮清楚的問題，因為技術是根據你的設計稿進行技術排期的，如果你的頁面不完整，后期再增補導致項目延期，這個責任在誰呢？
這里的不配合不是說技術同學偷懶不想干活，原因是多方面的：
解決方案：
之前沒有完整驗收的經驗，所以我們基本上是看到哪里是哪里，沒有一個系統的驗收框架，這樣就會導致在驗收的時候會有缺失，然后會被其他同事發現還挺尷尬的，測試是由測試用例的。所以我們也應該輸出一份設計審核清單，對照表格進行驗收，才能避免遺漏。
從源頭來說這個是我們自己的問題，因為沒有將通用模塊進行組件化整理。同時技術同學也沒有這個意識（或者是組內配合度不夠），因為我們本次項目是視覺升級，所以有些模塊的開發者會根據設計稿新出，有些是直接調用之前的樣式，這樣導致的結果就是不同模塊的彈層樣式不一致的尷尬結果。
解決方案：
通用模塊樣式進行組件化整理，比如Toast、對話框、錯誤提示等。協助技術進行組件化開發。
比如說圖片尺寸錯了，有些設計師就直接標注出來說這里出錯了，請參考設計標注重新調整。另一個設計師不僅標注哪里錯了，還直接標出這個圖片尺寸是多大。很明顯技術看第二個設計師給的驗收文檔更改的效率更高。
◆