前言

“這個做不了、很難做的啊、我沒時間啊、改這個有什么意義嗎?不是上次剛改過么怎么又讓我改?”

“我都沒見過哪個設(shè)計師像你這樣，不就幾個像素而已?有必要扣這么細嗎，能用就行了啊。還改?!我覺得這已經(jīng)很好看了啊，這么搞很麻煩的啊……”

各位設(shè)計師是不是已經(jīng)開始按耐不住摩拳擦掌了，以上場景在跟開發(fā)提需求和設(shè)計走查的時候經(jīng)常碰到，或是無奈或是生氣，但開發(fā)就是有無數(shù)種理由拒絕你。

毫不客氣的說，這個問題一般都會在你職業(yè)生涯中的某個階段碰到，或早或晚，雖遲但到一般不缺席。想必很多設(shè)計師都踩過下面這個坑…

上線后還原不到位被領(lǐng)導(dǎo)職責“你這設(shè)計怎么做的，為什么這里設(shè)計成這樣?”一對設(shè)計稿，一把辛酸淚…你正想極力辯解，不好意思，領(lǐng)導(dǎo)說：“我 只 看 結(jié) 果。”

就問你氣不氣?氣不氣?

開發(fā)到底為什么拒絕你?

收起大刀，咱先分析一波。這個問題不會隨著技術(shù)的變化而改變，也不像是方法論擁有固定的解題策略，但是在面試中又經(jīng)常碰到，比如“開發(fā)不配合、還原度不高時怎么辦”。這足以說明很多公司都會有這個問題，其實說到底還是人的問題，那我們就來看看“當事人”是怎么說的。

由于某些原因?qū)舆^很多開發(fā)，也咨詢了幾個前端朋友。不管開發(fā)口頭拒絕的原因有多么千奇百怪，一般情況下，開發(fā)反感或者不愿意配合設(shè)計還原都可以歸納為以下幾個原因：

1. 業(yè)務(wù)緊，任務(wù)重

也許是項目趕著上線，也許是一堆需求還未交付，當開發(fā)手頭有更重要的事情要處理時，他沒辦法分心或者用額外的勞動力去做設(shè)計優(yōu)化的內(nèi)容。很多時候給定的工時就那些，若是跟績效掛鉤就更別提了。我做需求改 bug 已經(jīng)要加班了，還要我配合你調(diào)來調(diào)去的，是你還會有這個心情嗎?

因此設(shè)計師也要關(guān)注項目的整個排期，嘗試著去宏觀把握項目進度，做到理解或評估開發(fā)的工時。多站在對方的角度考慮現(xiàn)狀。再者就是要判斷走查結(jié)果的優(yōu)先級，開發(fā)側(cè)的用戶體驗因素如性能、bug 數(shù)等要優(yōu)先于界面還原。畢竟用戶體驗并不等于界面的開發(fā)實現(xiàn)。當連 bug 都沒修完的情況下，還死盯著幾個像素去摳顯然是不妥的。完全可以先把低優(yōu)先級的問題記錄下來，留著某個版本再一起更新優(yōu)化。

2. 有背職業(yè)方向

前端的方向一類偏視覺展示的(動效視覺還原組件搭建等)，一類偏數(shù)據(jù)層面的(算法之類)。共性都需要比較強的數(shù)據(jù)處理和邏輯能力。

有些開發(fā)會十分明確自己的方向，比如往算法類的會認為專注視覺還原側(cè)是在浪費時間，因此在面對該類需求時內(nèi)心會產(chǎn)生一定的排斥心理。他們經(jīng)常不關(guān)注體驗這種東西。

其實像還原這種的都算開發(fā)底層的基礎(chǔ)能力。就像 UI 有的偏交互有的偏視覺，但一個偏交互的 UI 說不愿意畫圖標這說不過去吧。說到底本職工作還是設(shè)計。

3. 水平不夠

設(shè)計圈里都流傳著這樣一句話“沒有實現(xiàn)不了的效果，只有不想做的開發(fā)”。

不想做更傾向于是態(tài)度問題，不會做是能力問題。但所有技術(shù)不都是由不會到會么，況且大部分的還原問題借助搜索引擎是可以解決的，只是要權(quán)衡學習成本與收益的問題。若是實在基礎(chǔ)的問題都不愿意去做，必要的時候可以讓設(shè)計領(lǐng)導(dǎo)同開發(fā)領(lǐng)導(dǎo)反饋。

4. 價值觀不一致

有部分開發(fā)會不認可設(shè)計，你跟他談對齊親密性，他跟你說聽不懂要下班;他不想也不愿意去接受或了解設(shè)計的作用，沉浸在自己的認知體系里，自然也就不會認同你。這種是很少數(shù)了，只能說是公司招人不慎，可以嘗試多次溝通，依然無果后，與領(lǐng)導(dǎo)反饋。

以上就是常見的開發(fā)不愿意配合的原因了，有些情況會由于客觀條件確實難以解決，有時候可能睜一只眼閉一只眼就過去了。

那么有什么其他的辦法呢?

設(shè)計師該怎么做?

開發(fā)本身的問題很多時候我們作為設(shè)計師沒辦法介入，作為設(shè)計師，更應(yīng)該從自身出發(fā)去解決問題。

掐指一算對接過的開發(fā)也不在少數(shù)，軟磨硬泡，用盡畢生所學與其斗智斗勇，在耗盡氣力之前終習得了一點心法同大家探討，文末也一同附上了所有用到的工具和寶典配合使用，希望對大家有幫助。

1. 良好的溝通是前提

所有的合作都是基于溝通進行下去的，好的溝通方式會直接決定結(jié)果。別一聽開發(fā)不愿意做上來就急眼干架，友誼的小船說翻就翻，都是同事，不出意外以后還要天天見面的。這樣只會顯得自己更不專業(yè)，冷靜冷靜…

首先要保持客觀，聚焦問題。作為設(shè)計師要明確方案解決的問題是什么，為什么要做這個方案，盡可能地深入剖析問題根源，試著對著一個問題連續(xù)問自己 5 個為什么。這樣在對接需求時，既能做到證明自己的方案是對的，同時也可以游刃有余的回復(fù)對方的疑問。

另一方面，在溝通或設(shè)計評審時，可以廣泛的聽取他人的建議，每個人的出發(fā)點和認知是不同的，這就意味著看待問題的角度會不一樣，多記錄并思考別人的視角會更加拓寬自己的思維，這也有利于設(shè)計交接。

說了這么多，舉幾個最常見的可直接落地的實際方案：

• 條件允許的話，搬個凳子直接坐在開發(fā)旁邊磨(前期最好也可以帶點小零食慰問品，收了禮總得給個面子改改吧，這招通常都很管用)，面對面溝通細節(jié)是最高效的。

有一些開發(fā)壓根不懂設(shè)計，基本的對齊都看不出來，不是不愿意做，是真的看不出來。不要笑，一大把。這種方式雖然前期比較耗時間，但既可以培養(yǎng)感情，同時比聊天式的溝通更清晰高效。因為面對面的溝通能夠感受到你的情緒和狀態(tài)，有句話怎么說來著“線上聊千遍，不如線下見一面”。

• 盡量跟開發(fā)混好點。比如有球局就一起去打打、有機會就一起吃吃飯、平時有聚會就多玩玩嘮嘮嗑。混熟了調(diào)個樣式什么的那還不是分分鐘的事情。
• 在解釋自己的方案時，可以用“我有解釋清楚嗎”而不是“我這么說你聽得懂吧?”多站在聽者的角度去闡述。

2. 有一定的前端基礎(chǔ)常識

別擔心，我并不會在這里提如何敲代碼。想必很多從事設(shè)計師的朋友一部分原因是被代碼勸退了，二選一選了設(shè)計。

設(shè)計師沒有要求一定要會寫代碼，但做到看懂一些常規(guī)的內(nèi)容其實不會很難，一方面提高我們走查還原的效率，一方面也是自己“專業(yè)”的體現(xiàn)，提高開發(fā)信任感，同時溝通也能更順暢。

熟悉主流 UI 框架

當前市面上最主要的就 3 個：移動端 H5 的 Vant，PC 端的 Element 和 Ant。官網(wǎng)都有組件庫的源文件，導(dǎo)入 sketch 就可以直接調(diào)用了。

這里順帶提一嘴，element 是基于 vue 開發(fā)的，而 ant 主流是 react，但也有 vue 版( https://2x.antdv.com/docs/vue/introduce-cn )

因此動手前一定要提前跟前端確認用哪套框架再進行設(shè)計。尤其是 B 端，非大團隊是沒有足夠的人力和資源去搞源生的。大部分公司前期的開發(fā)都是基于 ant 或 Element，可直接用官方組件做設(shè)計稿，市面上的話 Element 的占有率還是會偏多一些。

考慮到開發(fā)效率與成本，基本上樣式都是基于框架調(diào)整的，所以碰到差距非常大的樣式最好是提前跟前端確認。

走查工具的應(yīng)用

再提工具之前，建議大家學習了解一下“盒模型”的概念，它是前端設(shè)計布局還原設(shè)計稿的基礎(chǔ)，下面要講的工具也會用到，篇幅有限，關(guān)于盒模型的內(nèi)容就不展開了，有興趣的可以自行搜索。

不知道大家有沒有遇到過以下這種場景：

開發(fā)上線后發(fā)現(xiàn)實際效果跟預(yù)期的有點差距，可能想微調(diào)字體大小或者間距或者某個顏色，要么屁顛屁顛求開發(fā)大爺調(diào)整一下，要么就自己再用軟件做調(diào)整試錯，這些方法也不是不行，但是有種更快捷的方式。下面提到的兩個工具就可以幫到你。

瀏覽器審查定位，快速試錯

第一步：鍵盤 F12 或鼠標右鍵點擊“檢查”調(diào)出如圖所示的代碼界面。

第二步：點擊右上角的小箭頭，再移動到左側(cè)頁面尋找你想查看的任何元素，比如“UI 設(shè)計_百度百科”，鼠標移上去時就可以看到基礎(chǔ)的元素屬性了。

第三步：單擊剛剛要選擇的元素“UI 設(shè)計_百度百科”，在右側(cè)就會自動定位到對應(yīng)的代碼，雙擊可以自己隨便打字，按 enter 立即生效，有時候測試文本極限值的時候用這個方法就不用再打開 sketch 敲文本了。

第四步：定位元素，設(shè)計試錯。重頭戲來了，還是選中剛剛的“UI 設(shè)計_百度百科”為例，點擊代碼塊右上角的“Computed”，很好，現(xiàn)在映入眼簾的這個大色塊就是傳說中的盒模型了。簡單理解就是前端在實現(xiàn)時，每個元素都用類似于盒子的這種模式一層套一層實現(xiàn)的，沒錯，你也可以理解為套娃。

鼠標移動到對應(yīng)的某一層，就可以看到每一層對應(yīng)在界面的哪個位置。比如這里的 padding 就是對應(yīng)左側(cè)界面的綠色條高度：10px。

那快速試錯又怎么理解呢?比如我們現(xiàn)在想調(diào)整“UI 設(shè)計_百度百科”上面的間距，點擊下方的“Filter”，輸入 padding 就可以看到這個數(shù)值了。

點擊箭頭直達修改路徑，雙擊修改直接生效。

要改其他的屬性同理。這樣就避免了請開發(fā)大爺幫忙，也省去了用軟件去調(diào)整試錯設(shè)計效果了。

當然這只是很小的一個例子，應(yīng)用在各種場景后會有很多新發(fā)現(xiàn)的，就比如某些在線設(shè)計的網(wǎng)址可以用這種方式拿到原始圖片，大家可以自己多去嘗試。

走查神器：CSS Peeper

CSS Peeper 是一款 Chrome 瀏覽器插件。主要用來輔助走查，如果你是得了看到代碼就頭疼的病，F(xiàn)12 審查也幫不了你，那這款絕對是你的最佳良藥了。

1. 快速查看元素屬性以及間距。字號、行高、色值、字重、元素間距，哪里不懂點哪里，驗收原來還可以如此輕松。

2. 預(yù)覽網(wǎng)頁所有色值。只要有不按規(guī)范的基本無所遁形，全站色值給你扒過來，查顏閱色，我是專業(yè)的。

3. 一鍵下載網(wǎng)站圖片素材。下載圖片什么的那是信手拈來，圖標 banner 任意素材，只要你是圖，我就下的來。

就問你香不香吧。

以上兩款都可以幫助我們快速的驗收，回歸主題，這一節(jié)主要提到的是了解前端基礎(chǔ)常識，其實主要還是為了更好的交接，說到這就順帶提一下設(shè)計交付的小技巧：

1. 除了交付靜態(tài)圖外，還要帶上交互說明。比如基礎(chǔ)的字段極限值、圖標的 hover、禁用狀態(tài)、適配方案等等，這些是產(chǎn)品不一定考慮的到的，在設(shè)計執(zhí)行過程中可以另起一個畫板一并寫下來，避免開發(fā)時的頻繁溝通。

另外涉及微交互/難實現(xiàn)或難描述的樣式，都可以拿現(xiàn)成已上線的成品給到開發(fā)去做參考，直接調(diào)用代碼、學習或改動都可以增加他們的效率或者提高他們?nèi)プ龅囊庠浮．吘拐f再多不如見一面，動態(tài)效果總比文案描述要容易理解，不是所有開發(fā)都能夠看一眼靜態(tài)圖就知道怎么實現(xiàn)。

2. 設(shè)計稿完成后在交付開發(fā)時要有一次正式的交接，也可以帶上測試，大概闡述一下設(shè)計稿的一些還原、交互難點以及注意點，畢竟還未正式介入開發(fā)，若有問題可以及時處理。小的問題一般在開發(fā)執(zhí)行時才會碰到，到時再給到設(shè)計支持就行了。

3. 注意標注平臺的設(shè)計稿布局和分組。先給大家感受一下普遍的在線平臺設(shè)計圖，包括但不限于藍湖、慕客、Codesign 等。

很多時候畫布一多，設(shè)計稿全堆一起，就算是設(shè)置好對齊，隔開間距，但還是遭不住一多就難以定位的問題。就算是產(chǎn)品自帶的分散功能也沒辦法解決。

開發(fā)一點進來，我是誰?我在哪?我要點哪里?圖一多就亂難免會引起一定的不適感。

那么有什么解決辦法嗎?

這個時候可以把設(shè)計稿按類別/模塊整理清楚，一個模塊的設(shè)計稿盡量不要超過 10 張，多了就考慮建一個子類別，另外要多建一個畫板做好分組。同時平臺自帶的分組功能也要應(yīng)用上，設(shè)計稿的命名也要準確便于利用搜索去定位。

最后就是按版本建立大的文件夾存放設(shè)計稿。切忌所有的稿都放在一個畫布里，多了不方便找是其次的，卡到想你錘爛屏幕的心才是最難受的。

既然一直談體驗，那么看稿的開發(fā)就是我們的核心用戶了，好的閱覽體驗說不定能帶來更高的代碼效率呢。千萬不要小看這些細節(jié)，都是一些小事情，無外乎命個名以及拖動拖動畫板，耐心一點也就幾分鐘的事。這些都是個人能力與專業(yè)的體現(xiàn)。

3. 建立走查機制

前面講的都是基于個人角度出發(fā)，而建立走查機制有點偏團隊側(cè)了。將走查納入整個產(chǎn)品設(shè)計流程的一部分，提測后就可以進入走查階段了，過程中需要記錄并與開發(fā)溝通修改還原問題。

一來可追溯防背鍋(你懂的)，二來讓還原的問題有沉淀，方便我們?nèi)ビ涗浐蛷?fù)盤。

類似這樣的表格模板，因為各個團隊大小和工作模式都不一樣，所以字段會有所差異，有的也有產(chǎn)、設(shè)、測共同維護的表。這個可以按實際情況參考這個模板適當增加刪減，另外走查時除了視覺類的，也可以通過交互自查表去做一些驗證，查缺補漏。

其中特別注意的一點就是走查反饋盡量寫的細致一些。比如截圖后在圖片上帶上箭頭指向，同時配合文字填寫在“問題描述”那一列里，是間距差了還是不對齊等等，有色值給錯的就把正確的色值也標注上。

最后，就算存在趕時間趕項目的情況，也要有基礎(chǔ)的設(shè)計底線，有些原則性的內(nèi)容不能隨意更改，比如通用的設(shè)計準則、一致性等，設(shè)計師需要根據(jù)實際情況把握好這個平衡點，對走查內(nèi)容做篩選沉淀。

4. 提升設(shè)計在團隊的影響力

這里的“設(shè)計”不僅是指設(shè)計師本人，還可以引申到具體的設(shè)計輸出、設(shè)計團隊等一切跟設(shè)計相關(guān)的人和事務(wù)。

比如做一些設(shè)計知識分享、設(shè)計團隊(或個人)項目的復(fù)盤總結(jié)，讓結(jié)果呈現(xiàn)更加的專業(yè)化，期間還可以引入用戶的聲音、用戶研究結(jié)論、數(shù)據(jù)分析等。這些都是建立信任、提高影響力的方式，長期執(zhí)行下來會帶來很大價值的。

5. 培養(yǎng)開發(fā)的用戶體驗意識

開發(fā)的設(shè)計意識越高，設(shè)計落地自然就越順暢。一方面通過上面提到的技術(shù)分享耳濡目染，不斷提高開發(fā)側(cè)的設(shè)計認知。

另一方面相關(guān)考核可以把開發(fā)側(cè)的用戶體驗因素權(quán)重提高。比如，穩(wěn)定性、性能、系統(tǒng)資源占用與消耗、bug 數(shù)、bug 解決率等，同時在招聘時也適當做一些篩選。再者就是常說的界面還原度了，視覺、交互動效與優(yōu)化等，可以通過驗收次數(shù)等來做一定的量化。

不過要達到這一點比較難，尤其是剛建立的小團隊。過程涉及多方協(xié)作，還要具體看開發(fā)側(cè)的認知和配合情況，需要基于人和現(xiàn)有的工作流去建立起設(shè)計共識，因此還是得細水長流，逐個攻破。

結(jié)尾

以上提到的種種是對開發(fā)不配合，設(shè)計難還原等相關(guān)問題的思考，經(jīng)驗有限，不一定能解決所有情況，具體的落地也會因人而異。如果實在接受不了也改變不了現(xiàn)狀，在實力允許的情況下大不了就換咯，大團隊在流程上肯定要更規(guī)范和成熟的。

我也遇到過很貼心的開發(fā)小哥，他甚至可以與你一起探討解決方案，視覺還原什么的都是基操，壓根不用你擔憂。這種的開發(fā)只能說是可遇不可求了，碰到了一定抓住好好珍惜~