開發說這個效果做不了，設計師怎么辦？

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

開發溝通指南

這一篇，我就要從幾個維度來講講，在真實項目環境中，開發說設計不出來的話，我們應該怎么辦。

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

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

開發會告訴你設計稿實現不了，就是在這個階段中發生的，那為什么他們會在這個階段說實現不了呢？

主要原因有四個：

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

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

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

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

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

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

但程序員的思考方式是不一樣的，程序寫代碼的第一目標必然是 “功能實現”。所以他們分配給界面樣式的時間和精力是不多的，如果視覺稿需要讓他們投入過多的精力，影響到功能的實現，那么他們肯定優先選擇功能而不是視覺效果。

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

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

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

以上就是程序員會講開發實現不出來的主要原因。

想要解決實現不了的問題，肯定要先定位出實現不了的原因屬于上面哪一類，然后才能對癥下藥。

第 1：技術實現不了的解決方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

跳槽……

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

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

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

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

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

1. 掌握基礎的前端技術邏輯
2. 前期進行開發可行性評估
3. 培養和開發團隊的協作默契

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

拓展閱讀

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

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

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

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

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

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

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

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

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

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

理解完前面的內容，就可以進入最后的重點。針對面試中開發說 “實現不了” 的回復框架：

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

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

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

這類問題主要考察的就是設計師針對項目實施的態度，是只在意你自己的想法，還是把團隊產出放到個人喜好之上。以及你的團隊協作潛力，一個缺乏協作精神的設計師，越有優秀的設計能力或者吹毛求疵的態度，越是項目研發中的負資產。

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

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

我們下篇再賤～

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