最近我們做了一次全新改版的項目。作為此次項目的設計師，從項目的前期分析、設計、交付開發、驗收上線，整個流程，在項目走查驗收階段我們設計師投入了30人/天！占了設計師整體投入的50%！在我們覺得應該設計投入最少的階段，卻占了我們大量的工作 且最后還原度也遠不達預期。
技術設計沒有達成共識，技術對交互體驗層面和視覺層面的問題敏感度很低
還原問題反饋不及時，有些問題項目后期驗收的時候才暴露
前期對還原度工作評估不準確，導致后期發現問題 來不及修改
還原問題不單單是設計師把設計稿做的多精準，標注的多仔細，這么簡單就能解決的。是設計和開發，團隊之間的合作共識問題。我把整個和開發對接工作分為前中后三個階段，在這里從頭來梳理一下，聊一聊設計師和開發如何高效對接，也是對自己的一次復盤總結。
在評審環節，設計師本人一定要將自己的設計稿進行宣講、幫助開發理解。注意給技術講述一些適配要求、設計規范、交互狀態及動效等，同時解答技術同學的一些疑問，這樣就能將一些可預見的問題解決掉，解決后期的溝通成本。
有一些地方有多種實現方式，如果前期沒有跟開發溝通清楚，就會導致最終實現的效果存在誤差，比如：下方這個tab項，單給一張圖，開發根本不知道設計師想要的實現方式是什么，固定間距還是固定菜單寬度，還是每項平分寬度，最后很大可能就會按照自己的理解去做了，導致出現重復返工的現象
再比如一些點擊熱區，如果不手動標明，有可能就做的很小
每個開發負責的具體頁面模塊不一樣，別人對具體了解程度也不會不一致，所以在評審會議上，一定要具體開發者在場，如果對應開發沒有發表意見，設計師可詢問，確保他已經理解需求。
設計師在講解自己的要求后，開發也要及時反饋是否有還原困難，如：是否有技術限制？是否有組件改動困難（牽一發而動全身）？實現成本過高（投入產出的性價比不夠）？等意見和原因，設計師也可拋出之前是否遇到過類似的阻礙，幫助開發去了解。
評審過程的問題和重要講解點，一定要記錄下來，會議中開發提出的一些問題及解決方案、或者沒有達成共識的地方，記錄下來等領導決策，在會議結束后以郵件形式、或wiki文檔發送前端們，抄送產品，確保會議內容的傳達到位。后面也好跟蹤。
還有一點就是，我們之前遇到的情況，在宣講會上 講解的一些要求，開發在做的時候可能就忘記了，讓開發改他認為設計沒有明確要求、會有點難推動，就會搞得雙方都有抱怨。有會議記錄也可避免此類情況發生
在前面我們做了詳盡的溝通和評審，但有時也避免不了在開發過程有些問題才發現暴露。這個就需要開發同學能重視還原問題，積極溝通反饋，和設計確認商議 是否有其它可替代方案，切勿自己發揮，等到后期驗收的時候才說出問題可能會影響進度。
開發者在完成自己負責的模塊界面時，可自己對齊設計稿自查一遍，參考【3.1驗收標準】的表格，可幫助判斷問題，在此階段也可發給設計者確認效果。
3.1、測試同學確保交互和視覺還原度至少在70%左右
這里可以提前在項目排期階段，設計師將所需的驗收工時同步給技術和測試，將驗收時間考慮進去
因為如果不要求測試走查還原度，設計驗收的時候就會有大量的問題，最后變成設計在測試界面而不是驗收。設計師不像測試對整個流程的測試配置那么熟悉方便，反復驗收需要測試和設計不斷配合，雙方的工作量都會加大。
理想的狀態應該是測試整個流程走通，視覺和交互還原問題也要著重測試，設計和產品在測試沒什么大問題后再進行驗收。
最好是提前知道模塊的開發者，這樣驗收的時候一對一進行模塊的打版驗收效率更高
技術對功能上的BUG，可以自己很好的判斷哪些是嚴重的緊急的，但對于視覺和交互層面的感知就比較低。在提問題單的時候，我們可以幫他標注出優先級，告知開發哪些是比較嚴重的需要優先修改的，不然 開發自己很難判斷，可能就會挑一些比較好改的先改了，重要的問題反而被擱置了。尤其在項目時間比較緊張的時候，有優先級標注 開發能夠看出哪些是可以為項目進度做出妥協的，哪些是必須要修改的。
設計提BUG單的不能簡單的說這里出錯了，請參考設計標注重新調整。要直接給出正確的尺寸、增多少、減多少、這樣可幫助技術提高更高效率，也能避免開發自己去看又出現誤差、又要返工修改。
設計師在驗收過程中容易遇到的一個比較頭疼的問題就是，技術和產品小伙伴可能因為項目上線時間緊，覺得視覺還原和頁面交互體驗上的問題不重要不給予修改，優先保障功能上線。
除了這些原因，設計側也在檢討總結，自己有哪些做的不足的地方，所以 以上文檔也是對接下來工作的優化方案。設計還原度也是日常考核之一，需要大家重視，好的產品要嚴格把控精心打磨，希望這次的總結、相關流程和經驗，在接下來工作中能夠提升設計驗收效率和還原度。
