“這個做不了、很難做的啊、我沒時間啊、改這個有什么意義嗎？不是上次剛改過么怎么又讓我改？”
“我都沒見過哪個設計師像你這樣，不就幾個像素而已？有必要扣這么細嗎，能用就行了啊。還改？！我覺得這已經很好看了啊，這么搞很麻煩的啊……”
各位設計師是不是已經開始按耐不住摩拳擦掌了，以上場景在跟開發提需求和設計走查的時候經常碰到，或是無奈或是生氣，但開發就是有無數種理由拒絕你。
毫不客氣的說，這個問題一般都會在你職業生涯中的某個階段碰到，或早或晚，雖遲但到一般不缺席。想必很多設計師都踩過下面這個坑…
上線后還原不到位被領導職責“你這設計怎么做的，為什么這里設計成這樣?”一對設計稿，一把辛酸淚…你正想極力辯解，不好意思，領導說：“我 只 看 結 果。”
就問你氣不氣？氣不氣？
收起大刀，咱先分析一波。這個問題不會隨著技術的變化而改變，也不像是方法論擁有固定的解題策略，但是在面試中又經常碰到，比如“開發不配合、還原度不高時怎么辦”。這足以說明很多公司都會有這個問題，其實說到底還是人的問題，那我們就來看看“當事人”是怎么說的。
由于某些原因對接過很多開發，也咨詢了幾個前端朋友。不管開發口頭拒絕的原因有多么千奇百怪，一般情況下，開發反感或者不愿意配合設計還原都可以歸納為以下幾個原因：
1. 業務緊，任務重
也許是項目趕著上線，也許是一堆需求還未交付，當開發手頭有更重要的事情要處理時，他沒辦法分心或者用額外的勞動力去做設計優化的內容。很多時候給定的工時就那些，若是跟績效掛鉤就更別提了。我做需求改 bug 已經要加班了，還要我配合你調來調去的，是你還會有這個心情嗎？
因此設計師也要關注項目的整個排期，嘗試著去宏觀把握項目進度，做到理解或評估開發的工時。多站在對方的角度考慮現狀。再者就是要判斷走查結果的優先級，開發側的用戶體驗因素如性能、bug 數等要優先于界面還原。畢竟用戶體驗并不等于界面的開發實現。當連 bug 都沒修完的情況下，還死盯著幾個像素去摳顯然是不妥的。完全可以先把低優先級的問題記錄下來，留著某個版本再一起更新優化。
2. 有背職業方向
前端的方向一類偏視覺展示的（動效視覺還原組件搭建等），一類偏數據層面的（算法之類）。共性都需要比較強的數據處理和邏輯能力。
有些開發會十分明確自己的方向，比如往算法類的會認為專注視覺還原側是在浪費時間，因此在面對該類需求時內心會產生一定的排斥心理。他們經常不關注體驗這種東西。
其實像還原這種的都算開發底層的基礎能力。就像 UI 有的偏交互有的偏視覺，但一個偏交互的 UI 說不愿意畫圖標這說不過去吧。說到底本職工作還是設計。
3. 水平不夠
設計圈里都流傳著這樣一句話“沒有實現不了的效果，只有不想做的開發”。
不想做更傾向于是態度問題，不會做是能力問題。但所有技術不都是由不會到會么，況且大部分的還原問題借助搜索引擎是可以解決的，只是要權衡學習成本與收益的問題。若是實在基礎的問題都不愿意去做，必要的時候可以讓設計領導同開發領導反饋。
4. 價值觀不一致
有部分開發會不認可設計，你跟他談對齊親密性，他跟你說聽不懂要下班；他不想也不愿意去接受或了解設計的作用，沉浸在自己的認知體系里，自然也就不會認同你。這種是很少數了，只能說是公司招人不慎，可以嘗試多次溝通，依然無果后，與領導反饋。
以上就是常見的開發不愿意配合的原因了，有些情況會由于客觀條件確實難以解決，有時候可能睜一只眼閉一只眼就過去了。
那么有什么其他的辦法呢？
開發本身的問題很多時候我們作為設計師沒辦法介入，作為設計師，更應該從自身出發去解決問題。
掐指一算對接過的開發也不在少數，軟磨硬泡，用盡畢生所學與其斗智斗勇，在耗盡氣力之前終習得了一點心法同大家探討，文末也一同附上了所有用到的工具和寶典配合使用，希望對大家有幫助。
1. 良好的溝通是前提
所有的合作都是基于溝通進行下去的，好的溝通方式會直接決定結果。別一聽開發不愿意做上來就急眼干架，友誼的小船說翻就翻，都是同事，不出意外以后還要天天見面的。這樣只會顯得自己更不專業，冷靜冷靜...
首先要保持客觀，聚焦問題。作為設計師要明確方案解決的問題是什么，為什么要做這個方案，盡可能地深入剖析問題根源，試著對著一個問題連續問自己 5 個為什么。這樣在對接需求時，既能做到證明自己的方案是對的，同時也可以游刃有余的回復對方的疑問。
另一方面，在溝通或設計評審時，可以廣泛的聽取他人的建議，每個人的出發點和認知是不同的，這就意味著看待問題的角度會不一樣，多記錄并思考別人的視角會更加拓寬自己的思維，這也有利于設計交接。
說了這么多，舉幾個最常見的可直接落地的實際方案：
1. 條件允許的話，搬個凳子直接坐在開發旁邊磨（前期最好也可以帶點小零食慰問品，收了禮總得給個面子改改吧，這招通常都很管用），面對面溝通細節是最高效的。
有一些開發壓根不懂設計，基本的對齊都看不出來，不是不愿意做，是真的看不出來。不要笑，一大把。這種方式雖然前期比較耗時間，但既可以培養感情，同時比聊天式的溝通更清晰高效。因為面對面的溝通能夠感受到你的情緒和狀態，有句話怎么說來著“線上聊千遍，不如線下見一面”。
2. 盡量跟開發混好點。比如有球局就一起去打打、有機會就一起吃吃飯、平時有聚會就多玩玩嘮嘮嗑?；焓炝苏{個樣式什么的那還不是分分鐘的事情。
3. 在解釋自己的方案時，可以用“我有解釋清楚嗎”而不是“我這么說你聽得懂吧？”多站在聽者的角度去闡述。
2. 有一定的前端基礎常識
別擔心，我并不會在這里提如何敲代碼。想必很多從事設計師的朋友一部分原因是被代碼勸退了，二選一選了設計。
設計師沒有要求一定要會寫代碼，但做到看懂一些常規的內容其實不會很難，一方面提高我們走查還原的效率，一方面也是自己“專業”的體現，提高開發信任感，同時溝通也能更順暢。
熟悉主流 UI 框架
當前市面上最主要的就 3 個：移動端 H5 的 Vant，PC 端的 Element 和 Ant。官網都有組件庫的源文件，導入 sketch 就可以直接調用了。
這里順帶提一嘴，element 是基于 vue 開發的，而 ant 主流是 react，但也有 vue 版（ https://2x.antdv.com/docs/vue/introduce-cn ）
因此動手前一定要提前跟前端確認用哪套框架再進行設計。尤其是 B 端，非大團隊是沒有足夠的人力和資源去搞源生的。大部分公司前期的開發都是基于 ant 或 Element，可直接用官方組件做設計稿，市面上的話 Element 的占有率還是會偏多一些。
考慮到開發效率與成本，基本上樣式都是基于框架調整的，所以碰到差距非常大的樣式最好是提前跟前端確認。
走查工具的應用
再提工具之前，建議大家學習了解一下“盒模型”的概念，它是前端設計布局還原設計稿的基礎，下面要講的工具也會用到，篇幅有限，關于盒模型的內容就不展開了，有興趣的可以自行搜索。
不知道大家有沒有遇到過以下這種場景：
開發上線后發現實際效果跟預期的有點差距，可能想微調字體大小或者間距或者某個顏色，要么屁顛屁顛求開發大爺調整一下，要么就自己再用軟件做調整試錯，這些方法也不是不行，但是有種更快捷的方式。下面提到的兩個工具就可以幫到你。
瀏覽器審查定位，快速試錯
第一步：鍵盤 F12 或鼠標右鍵點擊“檢查”調出如圖所示的代碼界面。
第二步：點擊右上角的小箭頭，再移動到左側頁面尋找你想查看的任何元素，比如“UI 設計_百度百科”，鼠標移上去時就可以看到基礎的元素屬性了。
第三步：單擊剛剛要選擇的元素“UI 設計_百度百科”，在右側就會自動定位到對應的代碼，雙擊可以自己隨便打字，按 enter 立即生效，有時候測試文本極限值的時候用這個方法就不用再打開 sketch 敲文本了。
第四步：定位元素，設計試錯。重頭戲來了，還是選中剛剛的“UI 設計_百度百科”為例，點擊代碼塊右上角的“Computed”，很好，現在映入眼簾的這個大色塊就是傳說中的盒模型了。簡單理解就是前端在實現時，每個元素都用類似于盒子的這種模式一層套一層實現的，沒錯，你也可以理解為套娃。
鼠標移動到對應的某一層，就可以看到每一層對應在界面的哪個位置。比如這里的 padding 就是對應左側界面的綠色條高度：10px。
那快速試錯又怎么理解呢？比如我們現在想調整“UI 設計_百度百科”上面的間距，點擊下方的“Filter”，輸入 padding 就可以看到這個數值了。
點擊箭頭直達修改路徑，雙擊修改直接生效。
要改其他的屬性同理。這樣就避免了請開發大爺幫忙，也省去了用軟件去調整試錯設計效果了。
為了方便大家理解，我錄了個小視頻，大家可以直接配合食用。
以上的方法技巧比較投機，適合實在害怕或者沒有時間學習代碼的同學，用這個方法可以幫助你省下很多時間。
當然這只是很小的一個例子，應用在各種場景后會有很多新發現的，就比如某些在線設計的網址可以用這種方式拿到原始圖片，大家可以自己多去嘗試。
走查神器：CSS Peeper
CSS Peeper 是一款 Chrome 瀏覽器插件。主要用來輔助走查，如果你是得了看到代碼就頭疼的病，F12 審查也幫不了你，那這款絕對是你的最佳良藥了。
1. 快速查看元素屬性以及間距。字號、行高、色值、字重、元素間距，哪里不懂點哪里，驗收原來還可以如此輕松。
2. 預覽網頁所有色值。只要有不按規范的基本無所遁形，全站色值給你扒過來，查顏閱色，我是專業的。
3. 一鍵下載網站圖片素材。下載圖片什么的那是信手拈來，圖標 banner 任意素材，只要你是圖，我就下的來。
就問你香不香吧。
以上兩款都可以幫助我們快速的驗收，回歸主題，這一節主要提到的是了解前端基礎常識，其實主要還是為了更好的交接，說到這就順帶提一下設計交付的小技巧：
1. 除了交付靜態圖外，還要帶上交互說明。比如基礎的字段極限值、圖標的 hover、禁用狀態、適配方案等等，這些是產品不一定考慮的到的，在設計執行過程中可以另起一個畫板一并寫下來，避免開發時的頻繁溝通。
另外涉及微交互/難實現或難描述的樣式，都可以拿現成已上線的成品給到開發去做參考，直接調用代碼、學習或改動都可以增加他們的效率或者提高他們去做的意愿。畢竟說再多不如見一面，動態效果總比文案描述要容易理解，不是所有開發都能夠看一眼靜態圖就知道怎么實現。
2. 設計稿完成后在交付開發時要有一次正式的交接，也可以帶上測試，大概闡述一下設計稿的一些還原、交互難點以及注意點，畢竟還未正式介入開發，若有問題可以及時處理。小的問題一般在開發執行時才會碰到，到時再給到設計支持就行了。
3. 注意標注平臺的設計稿布局和分組。先給大家感受一下普遍的在線平臺設計圖，包括但不限于藍湖、慕客、Codesign 等。
很多時候畫布一多，設計稿全堆一起，就算是設置好對齊，隔開間距，但還是遭不住一多就難以定位的問題。就算是產品自帶的分散功能也沒辦法解決。
開發一點進來，我是誰？我在哪？我要點哪里？圖一多就亂難免會引起一定的不適感。
那么有什么解決辦法嗎？
這個時候可以把設計稿按類別/模塊整理清楚，一個模塊的設計稿盡量不要超過 10 張，多了就考慮建一個子類別，另外要多建一個畫板做好分組。同時平臺自帶的分組功能也要應用上，設計稿的命名也要準確便于利用搜索去定位。
最后就是按版本建立大的文件夾存放設計稿。切忌所有的稿都放在一個畫布里，多了不方便找是其次的，卡到想你錘爛屏幕的心才是最難受的。
既然一直談體驗，那么看稿的開發就是我們的核心用戶了，好的閱覽體驗說不定能帶來更高的代碼效率呢。千萬不要小看這些細節，都是一些小事情，無外乎命個名以及拖動拖動畫板，耐心一點也就幾分鐘的事。這些都是個人能力與專業的體現。
3. 建立走查機制
前面講的都是基于個人角度出發，而建立走查機制有點偏團隊側了。將走查納入整個產品設計流程的一部分，提測后就可以進入走查階段了，過程中需要記錄并與開發溝通修改還原問題。
一來可追溯防背鍋（你懂的），二來讓還原的問題有沉淀，方便我們去記錄和復盤。
類似這樣的表格模板，因為各個團隊大小和工作模式都不一樣，所以字段會有所差異，有的也有產、設、測共同維護的表。這個可以按實際情況參考這個模板適當增加刪減，另外走查時除了視覺類的，也可以通過交互自查表去做一些驗證，查缺補漏。
其中特別注意的一點就是走查反饋盡量寫的細致一些。比如截圖后在圖片上帶上箭頭指向，同時配合文字填寫在“問題描述”那一列里，是間距差了還是不對齊等等，有色值給錯的就把正確的色值也標注上。
最后，就算存在趕時間趕項目的情況，也要有基礎的設計底線，有些原則性的內容不能隨意更改，比如通用的設計準則、一致性等，設計師需要根據實際情況把握好這個平衡點，對走查內容做篩選沉淀。
4. 提升設計在團隊的影響力
這里的“設計”不僅是指設計師本人，還可以引申到具體的設計輸出、設計團隊等一切跟設計相關的人和事務。
比如做一些設計知識分享、設計團隊（或個人）項目的復盤總結，讓結果呈現更加的專業化，期間還可以引入用戶的聲音、用戶研究結論、數據分析等。這些都是建立信任、提高影響力的方式，長期執行下來會帶來很大價值的。
5. 培養開發的用戶體驗意識
開發的設計意識越高，設計落地自然就越順暢。一方面通過上面提到的技術分享耳濡目染，不斷提高開發側的設計認知。
另一方面相關考核可以把開發側的用戶體驗因素權重提高。比如，穩定性、性能、系統資源占用與消耗、bug 數、bug 解決率等，同時在招聘時也適當做一些篩選。再者就是常說的界面還原度了，視覺、交互動效與優化等，可以通過驗收次數等來做一定的量化。
不過要達到這一點比較難，尤其是剛建立的小團隊。過程涉及多方協作，還要具體看開發側的認知和配合情況，需要基于人和現有的工作流去建立起設計共識，因此還是得細水長流，逐個攻破。
以上提到的種種是對開發不配合，設計難還原等相關問題的思考，經驗有限，不一定能解決所有情況，具體的落地也會因人而異。如果實在接受不了也改變不了現狀，在實力允許的情況下大不了就換咯，大團隊在流程上肯定要更規范和成熟的。
我也遇到過很貼心的開發小哥，他甚至可以與你一起探討解決方案，視覺還原什么的都是基操，壓根不用你擔憂。這種的開發只能說是可遇不可求了，碰到了一定抓住好好珍惜~
歡迎關注作者微信公眾號：「Andy聊設計」
復制本文鏈接 文章為作者獨立觀點不代表優設網立場，未經允許不得轉載。
熱評 小依