設計還原是開發實現的效果不斷校正並與設計稿保持一致的過程。在項目開發的流程中，設計還原和功能測試一樣，是上線前最後的質檢工作。設計界面是直接呈現給用戶的，還原度的高低影響用戶對產品的第一印象。
設計還原這麼重要，在實際執行中是什麼樣的？
其實很多時候，設計驗收環節不太受到各方重視。設計師更多思考的是如何達到美觀的界面、流暢的交互等問題，認為開發能會完全按照設計稿標註來，而忽略掉後期的設計驗收；開發則關心的是實現這個功能需要花費多長時間，實現難度如何等等。大家站在不同的角度看待問題，雙方的目標沒有對齊，最終影響到工作效率也是必然的。
設計還原，終究是一個合作問題。還原度的高低與否，取決於設計-開發-測試這些環節的協作質量，也直接影響上線產品的用戶體驗。
在設計前期需要確認哪些模塊有可調用的開發組件，若沒有，需要評估開發成本，預留好製作規範組件的時間。如果不了解這些情況，後期會有調整設計稿或延期風險。
設計完整輸出
我們在做設計交付前期，需要把全部的頁面狀態、切圖標註、動效視頻等文件整理好，避免在開發過程中臨時進行補充，影響項目開發進度。關於設計稿內的切圖，我們要提前與研發溝通，切圖的範圍和形式，最後把設計稿上傳到公司統一使用的協作網站，如58使用的是自研開發協作平颱風火輪。
關於標註，現在的標註軟件雖然能解放設計師的雙手，但是它們只是生成各元素的基本樣式、尺寸等，對於重要模塊部分建議手動標註，告知開發設計說明及注意事項。
中期·積極溝通
在設計宣講前，確認項目組主要成員到場，包括前端、測試、產品、後端同學等。我們對已確認的設計稿進行宣講，結合設計文檔對設計理念、組件規範、動效、特殊樣式等模塊進行講述，幫助開發同學理解。同時開發同學也要及時反饋是否有還原困難，如：是否有技術限制？是否有組件改動困難？實現成本過高等問題。針對宣講過程當中的問題和解決方案以會議紀要的形式記錄下來，會議結束後根據達成的共識和重要結論郵件周知項目組全員。
及時同步信息
在項目正式上線前，都可能出現產品臨時更改需求，計劃趕不上變化，這種情況比較常見。有時候產品同學認為更改個顏色或交互形式是比較小的調整，只告知了設計師調整往往忽略了同步給開發。那麼在測試上線後暴露出的問題，可能導致了延期等狀況時，各方就出現責任劃分。所以信息的同步非常重要，在項目組成立時，把涉及到的項目成員建立項目溝通群，所有相關信息同步在群內，有問題及時溝通，必要時拉會面聊。
避免頻繁修改
除了產品需求上變更導致設計稿調整外，應避免對設計稿的頻繁修改。因為在隨意更新設計稿的時候，我們不清楚當前的開發進度，如果修改的部分已開發，會給他們產生不必要的工作量，也可能會影響開發同學的代碼規範。如果必須要修改，一定要及時說明原因，否則會有被開發同學「追殺」的風險。
後期·主動跟進
跟進開發進度
設計稿交付後，我們還需要實時跟進項目的進度，了解當前項目開發的時間節點，根據開發給出的時間排期，在計劃提測時間介入走查。如果開發反饋有延期風險，我們需要跟產品及時了解原因，然後評估是否對設計有影響。
建立走查機制
儘管我們前面做了詳細的溝通和宣講，但有時也避免不了在開發過程中發現有些問題才暴露出來。設計師需要在提測階段提前介入走查，給開發預留出修改時間，通過建立合理完善的走查機制，來提升團隊整體的協作效率。
①保證視覺還原度在80%左右
在項目排期階段可與開發溝通，要求對自身負責的部分進行設計自查，同時將設計實現效果納入測試同學的工作中，保證視覺還原度在80%以上，再介入視覺驗收工作。因為很多時候不要求測試走查設計還原度，我們在驗收的時候就會浪費很多時間和精力在那些對照視覺稿就能發現的簡單問題上，反覆驗收導致設計與測試的工作量變大。
②規範走查文檔
在視覺走查階段，我們應該建立線上協作走查文檔，支持設計、開發、測試、產品等項目成員共同管理和跟進走查進度，避免口頭溝通造成的信息遺漏、溝通誤差等扯皮事件。走查文檔中包含對設計走查問題的分類、分級等，再根據影響程度、實現難度、資源配比等情況綜合分析進行排期。
在走查過程中，設計師還需要給予充分的支持響應，必要時補充設計示意圖或交互動效幫助開發同學理解，避免信息偏差導致再次調整。
③關注特殊情況
特殊場景在走查中常常被忽略，等上線後在現實中碰到缺失異常狀態體驗會大打折扣，所以完成主流程的走查後，一定要記得考慮到特殊場景，包括括網絡異常、內容缺失、空狀態等。同時還要看下不同機型適配的問題，保證不同機型的界面呈現效果一致，包括關鍵信息及操作是否超出屏幕，是否出現覆蓋、拉伸等情況。
數據監測
功能上線後也不代表需求的完結，我們還要及時追蹤數據的情況。數據的量化指標可以很好佐證我們方案的價值，也能幫助我們在錯誤道路上及時轉向。我們可根據數據反映的情況及時調整對應的產品策略，促進我們設計上的修改、完善等工作。
留言列表