前言

最近我們產(chǎn)品做了一次全新改版的項目。作為此次項目的設(shè)計師，從項目的前期分析、設(shè)計、交付開發(fā)、驗收上線，整個流程，在項目走查驗收階段我們設(shè)計師投入了30人/天！在我們覺得應(yīng)該設(shè)計投入最少的階段，卻占了我們大量的工作 且最后還原度也遠(yuǎn)不達(dá)預(yù)期。

在這個項目中我遇到了哪些問題：

還原問題不單單是設(shè)計師把設(shè)計稿做的多精準(zhǔn)，標(biāo)注的多仔細(xì)，這么簡單就能解決的。是設(shè)計和開發(fā)，團(tuán)隊之間的合作共識問題。我把整個和開發(fā)對接工作分為前中后三個階段，在這里從頭來梳理一下，聊一聊設(shè)計師和開發(fā)如何高效對接，也是對自己的一次復(fù)盤總結(jié)。

一、評審/排期

1.1、設(shè)計師對還原的要求宣講

在評審環(huán)節(jié)，設(shè)計師本人一定要將自己的設(shè)計稿進(jìn)行宣講、幫助開發(fā)理解。注意給技術(shù)講述一些適配要求、設(shè)計規(guī)范、交互狀態(tài)及動效等，同時解答技術(shù)同學(xué)的一些疑問，這樣就能將一些可預(yù)見的問題解決掉，解決后期的溝通成本。

有一些地方有多種實現(xiàn)方式，如果前期沒有跟開發(fā)溝通清楚，就會導(dǎo)致最終實現(xiàn)的效果存在誤差，比如：下方這個tab項，單給一張圖，開發(fā)根本不知道設(shè)計師想要的實現(xiàn)方式是什么，固定間距還是固定菜單寬度，還是每項平分寬度，最后很大可能就會按照自己的理解去做了，導(dǎo)致出現(xiàn)重復(fù)返工的現(xiàn)象。

再比如一些點擊熱區(qū)，如果不手動標(biāo)明，有可能就做的很小

下圖是我們手動標(biāo)注的熱區(qū)

1.2、實際開發(fā)者要參與評審

每個開發(fā)負(fù)責(zé)的具體頁面模塊不一樣，別人對具體了解程度也不會不一致，所以在評審會議上，一定要具體開發(fā)者在場，如果對應(yīng)開發(fā)沒有發(fā)表意見，設(shè)計師可詢問，確保他已經(jīng)理解需求。

1.3、開發(fā)充分評估還原工作問題

設(shè)計師在講解自己的要求后，開發(fā)也要及時反饋是否有還原困難，如：是否有技術(shù)限制？是否有組件改動困難（牽一發(fā)而動全身）？實現(xiàn)成本過高（投入產(chǎn)出的性價比不夠）？等意見和原因，設(shè)計師也可拋出之前是否遇到過類似的阻礙，幫助開發(fā)去了解。

1.4、認(rèn)真記會議紀(jì)要

評審過程的問題和重要講解點，一定要記錄下來，會議中開發(fā)提出的一些問題及解決方案、或者沒有達(dá)成共識的地方，記錄下來等領(lǐng)導(dǎo)決策，在會議結(jié)束后以郵件形式、或wiki文檔發(fā)送前端們，抄送產(chǎn)品，確保會議內(nèi)容的傳達(dá)到位。后面也好跟蹤。

還有一點就是，我們之前遇到的情況，在宣講會上 講解的一些要求，開發(fā)在做的時候可能就忘記了，讓開發(fā)改他認(rèn)為設(shè)計沒有明確要求、會有點難推動，就會搞得雙方都有抱怨。有會議記錄也可避免此類情況發(fā)生

二、開發(fā)階段

2.1、還原有問題及時反饋

在前面我們做了詳盡的溝通和評審，但有時也避免不了在開發(fā)過程有些問題才發(fā)現(xiàn)暴露。這個就需要開發(fā)同學(xué)能重視還原問題，積極溝通反饋，和設(shè)計確認(rèn)商議 是否有其它可替代方案，切勿自己發(fā)揮，等到后期驗收的時候才說出問題可能會影響進(jìn)度

2.2、開發(fā)完成后對齊設(shè)計稿自查

開發(fā)者在完成自己負(fù)責(zé)的模塊界面時，可自己對齊設(shè)計稿自查一遍，參考【3.1驗收標(biāo)準(zhǔn)】的表格，可幫助判斷問題，在此階段也可發(fā)給設(shè)計者確認(rèn)效果。

三、驗收階段

3.1、測試同學(xué)確保交互和視覺還原度至少在70%左右

這里可以提前在項目排期階段，設(shè)計師將所需的驗收工時同步給技術(shù)和測試，將驗收時間考慮進(jìn)去

為什么要求測試同學(xué)保證還原度至少在70%呢？

因為如果不要求測試走查還原度，設(shè)計驗收的時候就會有大量的問題，最后變成設(shè)計在測試界面而不是驗收。設(shè)計師不像測試對整個流程的測試配置那么熟悉方便，反復(fù)驗收需要測試和設(shè)計不斷配合，雙方的工作量都會加大。

理想的狀態(tài)應(yīng)該是測試整個流程走通，視覺和交互還原問題也要著重測試，設(shè)計和產(chǎn)品在測試沒什么大問題后再進(jìn)行驗收。

參考【驗收標(biāo)準(zhǔn)】的表格，可幫助判斷還原問題

3.2、明確知道模塊的開發(fā)者

最好是提前知道模塊的開發(fā)者，這樣驗收的時候一對一進(jìn)行模塊的打版驗收效率更高

3.3、設(shè)計走查問題標(biāo)注優(yōu)先級

技術(shù)對功能上的BUG，可以自己很好的判斷哪些是嚴(yán)重的緊急的，但對于視覺和交互層面的感知就比較低。在提問題單的時候，我們可以幫他標(biāo)注出優(yōu)先級，告知開發(fā)哪些是比較嚴(yán)重的需要優(yōu)先修改的，不然 開發(fā)自己很難判斷，可能就會挑一些比較好改的先改了，重要的問題反而被擱置了。尤其在項目時間比較緊張的時候，有優(yōu)先級標(biāo)注 開發(fā)能夠看出哪些是可以為項目進(jìn)度做出妥協(xié)的，哪些是必須要修改的。

3.4、BUG單

設(shè)計提BUG單的不能簡單的說這里出錯了，請參考設(shè)計標(biāo)注重新調(diào)整。要直接給出正確的尺寸、增多少、減多少、這樣可幫助技術(shù)提高更高效率，也能避免開發(fā)自己去看又出現(xiàn)誤差、又要返工修改。

3.5、遺留問題有記錄

四、結(jié)語

設(shè)計師在驗收過程中容易遇到的一個比較頭疼的問題就是，技術(shù)和產(chǎn)品小伙伴可能因為項目上線時間緊，覺得視覺還原和頁面交互體驗上的問題不重要不給予修改，優(yōu)先保障功能上線。

除了這些原因，設(shè)計側(cè)也在檢討總結(jié)，自己有哪些做的不足的地方，所以 以上文檔也是對接下來工作的優(yōu)化方案。設(shè)計還原度也是日常考核之一，需要大家重視，好的產(chǎn)品要嚴(yán)格把控精心打磨，希望這次的總結(jié)、相關(guān)流程和經(jīng)驗，在接下來工作中能夠提升設(shè)計驗收效率和還原度。

藍(lán)藍(lán)設(shè)計建立了UI設(shè)計分享群，每天會分享國內(nèi)外的一些優(yōu)秀設(shè)計，如果有興趣的話，可以進(jìn)入一起成長學(xué)習(xí)，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作，也請與我們聯(lián)系。

文章來源：站酷   作者：飛行的考拉

分享此文一切功德，皆悉回向給文章原作者及眾讀者.

免責(zé)聲明：藍(lán)藍(lán)設(shè)計尊重原作者，文章的版權(quán)歸原作者。如涉及版權(quán)問題，請及時與我們?nèi)〉寐?lián)系，我們立即更正或刪除。

藍(lán)藍(lán)設(shè)計( m.shtzxx.cn )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)