有很多同學(xué)面試都遇到過這樣一個問題（包括我）：如果你做的設(shè)計開發(fā)說實現(xiàn)不了，你會怎么辦？這是一個直接反映設(shè)計師在自己領(lǐng)域業(yè)務(wù)水平的問題，也是 UI 設(shè)計工作中最常遇到的阻力之一，是設(shè)計師和前端程序員的主要矛盾來源。

開發(fā)溝通指南

這一篇，我就要從幾個維度來講講，在真實項目環(huán)境中，開發(fā)說設(shè)計不出來的話，我們應(yīng)該怎么辦。

想要解決開發(fā)做不了的問題首先要了解他們做不了的原因。

在正常的團(tuán)隊協(xié)作中，正式進(jìn)入前端開發(fā)階段前，有需求評審、交互評審和視覺評審。需求評審即產(chǎn)品經(jīng)理的工作產(chǎn)出評審，告知團(tuán)隊這個階段要實現(xiàn)的功能有哪些。而交互和視覺評審，則是設(shè)計師交付給團(tuán)隊，產(chǎn)品怎么操作，界面長什么樣的過程。這個過程不一定是要在會議室中一群人看設(shè)計師演示交互原型或 PPT，只要是設(shè)計沒有完全定稿針對它的討論都可以算是評審過程。

開發(fā)會告訴你設(shè)計稿實現(xiàn)不了，就是在這個階段中發(fā)生的，那為什么他們會在這個階段說實現(xiàn)不了呢？

主要原因有四個：

1. 技術(shù)上有難度，實現(xiàn)不了
2. 時間不夠充裕，來不及做
3. 單純看你不爽，對人不對事
4. 看破職場沉浮，一心躺平

針對第一點，稍微有點經(jīng)驗的程序員都不會在看到設(shè)計稿后判斷不了自己能不能實現(xiàn)，不會把設(shè)計稿拿回去代碼寫到一半，再跑回來和你說實現(xiàn)不了。

這里的不能實現(xiàn)包含三種情況，第一種是技術(shù)上真沒辦法實現(xiàn)，比如使用了一些非常復(fù)雜的 3D 著色器、渲染效果。

第二種是開發(fā)的能力有限，以他目前的水平做不出來。尤其是小公司中的初級前端群體，因為經(jīng)驗和技術(shù)能力不足，往往復(fù)雜點的效果就不知道怎么下手，所以自然實現(xiàn)不出來。

第三種，就是為了實現(xiàn)這個效果的代價過大，覺得完全沒有必要，這是最常見的情況。比如團(tuán)隊已經(jīng)使用某開源框架做前端了，結(jié)果你設(shè)計稿效果和官方組件南轅北轍，為了和你的設(shè)計效果保持一致，得花費幾倍的時間精力。

可能設(shè)計新人會覺得奇怪，程序員還原設(shè)計稿效果不是天經(jīng)地義的嘛？

但程序員的思考方式是不一樣的，程序?qū)懘a的第一目標(biāo)必然是 “功能實現(xiàn)”。所以他們分配給界面樣式的時間和精力是不多的，如果視覺稿需要讓他們投入過多的精力，影響到功能的實現(xiàn)，那么他們肯定優(yōu)先選擇功能而不是視覺效果。

多數(shù) B 端項目中程序員的時間都是不夠用的，所以也導(dǎo)致復(fù)雜的視覺效果基本都會被他們駁回。這就關(guān)聯(lián)到第二點，時間不夠充裕的問題。因為時間緊迫，一些開發(fā)成本過高的視覺效果，即使程序員認(rèn)可你的設(shè)計方案，也想這么輸出，但是根本沒有充裕時間完成，所以只能拒絕。

再到第三點，程序員就是對你有意見，只要設(shè)計稿稍微復(fù)雜，就算做的了也有時間但就是不想和你配合，也會想方設(shè)法找理由給借口說做不了。同事發(fā)展到這個地步并不少見，根據(jù)我多年的經(jīng)驗和觀察，除了少數(shù)心理健康有待商榷的程序員以外，這種情況多數(shù)由設(shè)計師的不專業(yè)行為長期積累而引發(fā)的，被對接程序員嫌棄……

最后一點，就是和你對接的前端看破滾滾紅塵，參透職場的真理，認(rèn)清剝削的真相，選擇躺平了……躺平了……平了……了……這和上一點類似都是消極對待工作，只是這次他沒針對你了，而是針對項目團(tuán)隊在座的各位。這種程序員高頻出現(xiàn)在國企或其它大型企業(yè)中，有比較長的工作年限，得過且過沒有任何的工作熱情了。或者是已經(jīng)打定主意要離職，已經(jīng)抱著你們愛咋咋滴和我已經(jīng)沒關(guān)系的心態(tài)了。

以上就是程序員會講開發(fā)實現(xiàn)不出來的主要原因。

想要解決實現(xiàn)不了的問題，肯定要先定位出實現(xiàn)不了的原因?qū)儆谏厦婺囊活悾缓蟛拍軐ΠY下藥。

第 1：技術(shù)實現(xiàn)不了的解決方案

如果是技術(shù)上的困難導(dǎo)致無法實現(xiàn)，那么設(shè)計師修改方案是必須的。但改動前，要盡量和程序員詢問技術(shù)實現(xiàn)不了的原理，再針對性的做出調(diào)整。比如我們之前做過的一個篩選面板優(yōu)化，增加了右下角 “查詢” 按鈕，需要每次篩選完成后點 “查詢” 才能刷新篩選結(jié)果，而不是像京東這些網(wǎng)站的篩選項一樣點擊后立刻刷新。

這是因為開發(fā)做不到結(jié)果秒出，一般項目的后端數(shù)據(jù)庫搭建非常簡陋，檢索效率極低，每次查詢請求到輸出結(jié)果需要數(shù)秒到數(shù)十秒不等。所以，增加查詢按鈕多一個操作步驟反而是效率更高的做法。

還有特別常見的情況，就是設(shè)計師自己辛辛苦苦畫了花里胡哨的圖表、可視內(nèi)容，還加上各種酷炫的動畫和特效，但是開發(fā)做出來和設(shè)計稿完全不一致。

這就是因為一般開發(fā)掌握的圖形技術(shù)往往非常有限，或者使用的引擎本身也不具備實現(xiàn)相關(guān)模型、效果的渲染。這需要設(shè)計師和程序員進(jìn)一步確認(rèn)可以實現(xiàn)的效果特征有哪些，支持什么程度的模型，可以應(yīng)用哪種著色器、光源，再根據(jù)這些特性重新優(yōu)化設(shè)計方案。

解決技術(shù)實現(xiàn)上的難度，就是找出問題在交互的步驟上還是視覺上（動畫也算），然后圍繞這個方向和開發(fā)進(jìn)一步商議出可以實現(xiàn)的方案，再動手去修改。

第 2：時間不夠充裕，來不及做

時間來不及也是非常常見的情況，尤其在設(shè)計師設(shè)計出非常多全新的樣式和細(xì)節(jié)時。多數(shù)項目都會使用類似 Ant、Element、Tdesign 之類的開源前端框架，如果你制定了大量新組建或修改了原有組件的樣式或細(xì)節(jié)，那么調(diào)整起來是非常耗時的，即使是一些看似簡單的微小改動。

因為成熟的大型開源項目，每一個元素的樣式、邏輯都作用了大量的代碼，這些代碼又分布在不同的樣式表或者腳本中。往往做一點小改動，就會發(fā)生莫名其妙的 BUG，這種情況就要倒逼程序員去檢查和理解與它關(guān)聯(lián)的所有代碼信息。即使成功把這個細(xì)節(jié)改好了，保不準(zhǔn)其它關(guān)聯(lián)到的元素會出現(xiàn)問題，引發(fā)一連串的連鎖反應(yīng)……

所以通常在前端時間不足的情況下，最簡單的解決辦法就是減少新樣式的使用，盡可能使用框架自帶樣式或者過去開發(fā)的原有樣式。這不是說每次迭代時間緊迫設(shè)計師永遠(yuǎn)不思進(jìn)取，對所有設(shè)計 Ctrl+C/V 就結(jié)束了，而是要做權(quán)重評估，哪些樣式的改動不僅重要性不高而且花費的時間特別多，哪些是非常必要且無法忽視的更新。

之后，就是要和開發(fā)進(jìn)行討價還價的時候，放棄一部分次要的樣式，集中精力來處理一些重要的內(nèi)容。要有目的性的把整體視覺樣式迭代拆分成多個版本來完成，每個版本見縫插針，而不是一口吃成胖子指望前端工程師進(jìn)行 007 強行軍。

第 3：單純和你有矛盾，不想做你的需求

產(chǎn)品、設(shè)計、程序員之間如果有矛盾，一般不會是一天兩天產(chǎn)生的，而是長期積累下來的。如果關(guān)系已經(jīng)惡化到不能調(diào)和，那么需求的執(zhí)行只能依靠公司規(guī)章，或者同對方上級溝通強行推進(jìn)（也可能推不動）。

如果關(guān)系還有挽回的余地，你又想順利推進(jìn)設(shè)計落地，那只有主動低頭示好一條路能走了。因為設(shè)計和開發(fā)是沒有從屬關(guān)系的，只能曉之以情動之以禮，強勢的壓迫只會獲得相反的結(jié)果。提升自己的專業(yè)能力，溝通能力，全局觀，站在別人角度思考做出有效的讓步，才能長期維護(hù)協(xié)作關(guān)系的緊密性。

第 4：看破職場沉浮，一心躺平

這種情況接近無解，當(dāng)一個員工選擇徹底躺平，就已經(jīng)放棄追求和責(zé)任感。除非你們的私交非常好可以站在基友、朋友的角度上做感化，否則只能全部改成最簡單的方案。

如果和你對接的前端都已經(jīng)躺了，而你又是個有追求的設(shè)計，那給你們唯一的建議：

跳槽……

上面的建議，與其說是解決方案，不如說是如何 “妥協(xié)” 的方案。

這是一種無奈的客觀要求，任何行業(yè)的設(shè)計，都是一個針對理想方案和現(xiàn)實情況進(jìn)行妥協(xié)的過程。強如蘋果，也在極度追求輕薄后重新增加了筆記本的厚度和散熱模塊尺寸（變成磚頭）。

固然我們可以用圓滑的處事方法和職場生存技巧處理樣式實現(xiàn)不了的問題，但一個真正有職業(yè)精神和追求的設(shè)計師，會在項目初期就做好開發(fā)可行性的研究判斷，而不是等到設(shè)計都輸出完了再做調(diào)整。

讓可以遇見的問題扼殺在搖籃中，項目的推進(jìn)效率才會更高，留給視覺交互的開發(fā)時間才會更多。

想要盡量避免開發(fā)做不了的問題，就要滿足下面的條件：

1. 掌握基礎(chǔ)的前端技術(shù)邏輯
2. 前期進(jìn)行開發(fā)可行性評估
3. 培養(yǎng)和開發(fā)團(tuán)隊的協(xié)作默契

掌握前端技術(shù)邏輯這個觀點以往的分享已經(jīng)講爛了，但還是不能不提，沒有任何前端技術(shù)認(rèn)識是絕對沒辦法判斷設(shè)計的可行性的。

拓展閱讀

掌握 HTML + CSS 認(rèn)識靜態(tài)頁面的布局，是唯一要涉及到需要自己上手做練習(xí)的地方，這個我們過去錄制過對應(yīng)的教學(xué)，頂多一周就能掌握。其它的部分，就是理解 JS 或 React、VUE 是什么，前端語言的基本認(rèn)識和功能實現(xiàn)邏輯，還有諸如響應(yīng)式、API、封裝、異步等術(shù)語的意思。

除了 JS 建議花一周時間看一些入門教程，其它的專業(yè)術(shù)語學(xué)習(xí)，就是在工作中碰到什么百度什么，全都有非常基礎(chǔ)的科普掃盲。

第二，就是在每次項目前期，將你認(rèn)為可能會遇到的技術(shù)問題提前和開發(fā)商議。比如特殊的業(yè)務(wù)組件的復(fù)雜交互方法，界面框架響應(yīng)式的變更，特殊動效的動畫形式，圖表的自定樣式等等。

掌握越多的前端知識，可以發(fā)現(xiàn)的問題就越精準(zhǔn)。在構(gòu)思設(shè)計方案的階段覺得有開發(fā)難度，又拿捏不準(zhǔn)的地方就一定要提前和開發(fā)通氣，排除掉不合理的，確定出具體的實現(xiàn)方向。

這可以避免很多沒必要的問題，以及建立開發(fā)在界面實現(xiàn)方向工作量的預(yù)期，這點非常重要。因為設(shè)計稿沒拿出來之前，對前端開發(fā)來說就是盲盒，很可能會收到一份意想不到的 “大禮”。只要預(yù)期可以建立，項目進(jìn)度又不是非常迫切的話，專業(yè)的前端都是愿意盡量配合設(shè)計師實現(xiàn)一些更優(yōu)或者更有挑戰(zhàn)的效果。

在過去，我和不同團(tuán)隊的前端工程師都會預(yù)留一部分的時間，進(jìn)行特殊的效果嘗試，嘗試不同的技術(shù)方案和可能性，即使他們最終不一定能落地，但這可以非常好的提升各自的專業(yè)水平和眼界。

有效的前期溝通也是專業(yè)性和獲得話語權(quán)的關(guān)鍵操作，因為溝通意味著協(xié)商，協(xié)商意味著尊重，對技術(shù)人員尊重的缺失就是后面會被針對的主要問題之一（另一個是菜）。試想一下，你們的老板還是運營、市場人員，不咨詢你的意見也不管你的能力范圍，指定要下面這些效果的 Banner 還是 H5，你會怎么想？

能滿足前面兩點，就能追求第三點，培養(yǎng)和開發(fā)團(tuán)隊的默契了。優(yōu)秀的產(chǎn)品團(tuán)隊產(chǎn)品、設(shè)計、開發(fā)都要有一定的協(xié)作默契，這樣可以減少很多不必要的溝通成本。默契是多方面的，包括了解雙方的工作流程，每個階段要做什么，怎么配合。另一方面，是了解對方的技術(shù)水平，擅長哪個方面，做出正確的評估，交付對應(yīng)的成果。

這是在半年到一年以內(nèi)可以實現(xiàn)的目標(biāo)，當(dāng)你了解對接的前端工程師主要熟悉哪些技術(shù)棧、框架，技術(shù)水平、工作投入程度，你就會對怎么溝通，提供給對方什么樣的設(shè)計內(nèi)容有更深入的見解。

雖然我們不能確保每次項目中所有界面技術(shù)問題全能在前期完美解決，但我們的目標(biāo)就是盡可能減少到項目后期開發(fā)說 “做不出來”，再浪費時間在爭吵誰聽誰的問題上。

理解完前面的內(nèi)容，就可以進(jìn)入最后的重點。針對面試中開發(fā)說 “實現(xiàn)不了” 的回復(fù)框架：

找出原因：開發(fā)說實現(xiàn)不了，我首先要和對方確認(rèn)并判斷實現(xiàn)不了的原因是什么，是技術(shù)上的難點還是時間不夠，而不是無理由強行推進(jìn)自己的設(shè)計方案。

解決方案：如果是技術(shù)上的問題，我會和程序員商量解決方案再做調(diào)整，來適應(yīng)落地需要。如果是時間不夠，那么我就會評估相關(guān)內(nèi)容的優(yōu)先級，放棄一些低優(yōu)先級的設(shè)計需求留到后面版本再實現(xiàn)，集中精力在核心需求的開發(fā)上。

提前避免：當(dāng)然，除此之外我會盡力避免在設(shè)計完以后才知道實現(xiàn)不了。第一是我會積極掌握前端的相關(guān)技術(shù)內(nèi)容，具備技術(shù)難度的初級評估能力。第二是我會在每次動手設(shè)計前，通過一些基礎(chǔ)原型和程序員做更具體的開發(fā)可行性評估，提前調(diào)整不合理的方案。第三，我會在長期的研發(fā)過程中培養(yǎng)和前端團(tuán)隊的默契，盡可能提升設(shè)計落地的效率，從而預(yù)留出更多時間來實現(xiàn)更好的用戶體驗或視覺效果。

這類問題主要考察的就是設(shè)計師針對項目實施的態(tài)度，是只在意你自己的想法，還是把團(tuán)隊產(chǎn)出放到個人喜好之上。以及你的團(tuán)隊協(xié)作潛力，一個缺乏協(xié)作精神的設(shè)計師，越有優(yōu)秀的設(shè)計能力或者吹毛求疵的態(tài)度，越是項目研發(fā)中的負(fù)資產(chǎn)。

所以，上面的回復(fù)框架大家可以根據(jù)自己的理解修改，或加入過去實際經(jīng)歷過的案例做說明，讓它更有說服力！

本次的分享就到這里，如果還有一些遇到不知道如何回答的面試問題，也可以發(fā)到下方留言中。

我們下篇再賤～

歡迎關(guān)注作者的微信公眾號：「超人的電話亭」