所謂術業有專攻，設計師不懂開發很正常，但設計稿能否落地最終還是得看程序員能否實現出來。這時候問題來了，有些設計師的創意很天馬行空，但拿到程序員面前程序員說不可能實現時，簡直心如死灰，內心萬馬奔騰：這都做不了。此刻程序員心理：連這個常識都不知道，我都不想說話了。

為什么大家都覺得對牛彈琴？設計師大多數是藝術生出身和右腦思維者，比較擅長空間想象、藝術等方面的學習和工作；程序員基本是理科生出身和左腦思維者，比較擅長邏輯推理等方面的學習和工作，所以可以認為兩者的思維方式不太一樣。

估計大多數設計師聽到“這個開發成本很大”這個根本無法實現”時都會堅信不疑，即使懷疑也不知道怎么去證明成本不是很大或者可以實現出來，然后跑去找降級方案，甚至最終方案和最佳方案有很大差距。

首先要非常非常客觀的說一件事，程序員最喜歡說的一句話“只要你給了方案我都能給你實現出來”這句話是基本沒錯的，因為只要有充足的時間去想和實現，沒有解決不了方案。那為什么又用“這個開發成本很大”“這個根本無法實現”而拒絕你的方案呢？最終還是時間問題，但決定時間最終還是由方案難度以及程序員的能力如智商，經驗和編程能力和人力所決定，抽象概括為一個反比例函數Y=Z/X（Z為常量）。

由于時間有限，程序員不想把時間浪費在一些對自己沒有產生價值的工作上如調視覺細節，我先簡單介紹一下程序員想做和不想做的事情：

說一點動效實現。動效實現一直是國內大部分程序員的短板，首先大部分計算機專業沒有專門教前端或者客戶端開發的課程，更不用說動效實現教學；加上網上缺乏相關資源以及動效實現強依賴設計（自己單干不了），所以程序員學習動效開發相當困難。好的動效需要慢慢調整出來十分消耗時間，所以大部分程序員不喜歡把時間浪費在動效實現上。逼著一個人干短板的事情估計誰也不愿意，設計師應該要理解。

在項目流程上，設計屬于開發的上游，所以設計師有義務對自己的設計稿把關后才交付給開發。身為一名具有開發背景的設計師，我來講講程序員是怎么思考你的設計稿的，再介紹一個比較簡單的開發成本評估方法有助于你自行評估自己的設計稿，這樣你的設計稿落地可能性會高一些。

先對比一下設計師和程序員如何看待整個產品：

從圖上可知道設計師關注的流程在程序員眼里等于整個產品的業務邏輯和全局架構的實現，思考點遠比流程要復雜很多；設計師也一直忽略（準確點是無法關注）性能的問題。

再了解一下程序員拿到你的設計稿如何第一時間快速評估技術成本的：

再了解一下程序員在開發時是如何審視整套方案并再次評估技術成本的（已與多名BAT程序員確認過）

由于預估很難做到深入評估，所以在后期開發時會暴露出更多與實現架構和業務邏輯相關的問題。設計師可以通過該圖對自己的設計稿進行技術成本預估，但最終評估需要結合實際實現架構和業務邏輯進行實際分析。

該圖標注的“設計師無法察覺”是專業技能上的壁壘，即使設計師懂點代碼最多只知道這個界面怎么搭建起來，但算法和實現架構等方面仍是接觸不到的，所以設計師可以不用指望懂點html css就能和程序員平起平坐“聊技術”，在一個自己毫無接觸過的領域和人家過招簡直就是找死關鍵是不知道怎么死。

上面那句話估計是大多設計師希望懂點代碼的原因，即使接觸不了技術壁壘，設計師仍有其他途徑了解技術成本高的背后原因以及找到能落地的最佳方案。

1. 多了解開發上的專業術語和自己開發團隊的獨有術語

2. 將代碼理解成一個拼圖

每塊拼圖都用一個術語或者專業名詞代替，了解該拼圖怎么使用(input)以及用途是什么(output)，每塊拼圖的output可能決定著下一塊拼圖的input。

3. 站在更高的層面看待問題

程序員和架構師的區別是程序員是寫代碼的，架構師是負責整體實現框架和拼圖設計以及將每塊拼圖順序整理好，再讓程序員去實現每塊拼圖。即使設計師不懂寫代碼，也可以站在架構師小弟的層面去學習看待整個產品架構。如果有類拼圖突然更改了使用方法，而這類拼圖又被沿用到各個領域，這時候你應該能大概判斷出這個實現成本有點大。

4. 有意識去判斷數據間的聯系，學會了解每個數據間的聯系

例如耳朵鼻子嘴巴都屬于一個集合“臉”，無名指食指屬于一個集合“手”，而“無名指動嘴就動”屬于不同集合間數據的聯動，本來無名指動跟嘴動就毫無關系，神醫辛辛苦苦把關系建立起來，然后你微微一笑告訴神醫其實我想無名指動則耳朵動，結果是神醫微微一笑看著你倒在血泊里。

5. 學會判斷產生高并發的問題

高并發的難度最主要是很多用戶同一時間訪問服務器抓取數據庫信息，甚至需要在服務器上對數據進行處理。可以理解為“無名指動自己趴下”的無理需求變為更為無理的“無名指動瞬間整個學校學生都趴下”，工作量和難度上升幾個指數級別。設計師需要判斷自己的設計稿是否存在數據實時動態變化并且大量用戶實時拉取該數據的情況，與程序員溝通以及做好相關處理。

6. 多用Google學會搜索

算法難度大不大這個要根據具體功能具體哪個程序員實現來判斷，設計師無法評估。如果真的解決不了算法問題，你可以在網上找到相應的算法或解決方案提供給程序員讓他們重新評估實現難度。（這個非常難做到）

該圖標注的“業務邏輯（設計師甚少考慮）”更多是指功能和流程，以及它們所影響的覆蓋面；再深入一點即是剛剛所述拼圖的順序以及改動拼圖所造成的影響。這需要設計師對產品整體功能和流程有全局的認識和把控。

以上方法更多關注整體開發成本，這有一定的學習成本和難度；接下來我介紹一下關于界面開發成本評估并可迅速上手的方法。

為了更好解釋開發成本，我將開發成本進一步拆分為技術成本，時間成本和心理成本。技術成本已在上文所述，界面實現除動效外開發成本不會很高；時間成本需要在實際項目中根據工作量與程序員

的能力和人數進行評估；心理成本是指該程序員愿不愿意做#很無奈但可以其他手段解決的一項成本#。設計師可以根據以下流程來預估開發成本。

△ ?校驗成本屬于時間成本的一部分；數字僅表示量化成本間的差距，為個人觀點僅供參考，最終成本需要按照實際情況而定。

最后再給一些設計稿標注的建議，有利于后期開發完成后的UI Review(視覺還原)。

1. 復雜的設計稿最好能標注圖層層級，有利于開發理解你的設計稿層級關系（貌似沒見過有設計師這樣做）

2. 可以簡單了解一下iOS，Android的布局方式如LinearLayout(線性布局)、AbsoluteLayout(絕對布局)、TableLayout(表格布局)、RelativeLayout(相對布局)等等，不同布局可以有更為合理的標注方法。

3. 了解Margin(容器外間距),Padding(容器內間距)是什么。所有的間距都是由這兩個屬性決定，而不只PSD里兩個圖層間的距離，設計師需要知道這一點。

4. 可以考慮在3px或4px倍數的基礎上設計。盡可能減少多樣化的間距，例如有些7px有些9px，在程序員的眼里7px跟9px沒什么區別，所以在寫代碼時不會嚴格按照你的標注進行開發，然后就有勞設計師的像素眼了。

5. 動效實現上盡可能自己先拆好分動作和時間后再交給開發，參數調節等可以讓開發實現完再統一修改。

設計和開發一樣都需要有理有據。這些經驗和技巧能幫助我在設計階段能更好地考慮開發成本，減少了后期因為開發成本原因重新改稿的幾率；更重要的是它能更好地輔助我實現我的想法，可以在限制條件下做到更好的設計，或者低成本實現最佳方案。以上就是我身為設計師和程序員的一些經驗，希望對大家有幫助。

歡迎關注作者的個人公眾號：薛志榮

「如何和開發愉快合作？」

1. 《值得設計師看看的5個開發小知識》
2. 《UI設計師進階教程！如何以開發的視角做設計？》

【優設網 原創文章 投稿郵箱：yuan@uisdc.com】

================明星欄目推薦================

優優教程網： UiiiUiii.com 是優設旗下優質中文教程網站，分享了大量PS、AE、AI、C4D等中文教程，為零基礎設計愛好者也準備了貼心的知識樹專欄。開啟免費自學新篇章，按照我們的專欄一步步學習，一定可以迅速上手并制作出酷炫的視覺效果。

設計導航：國內人氣最高的設計網址導航，設計師必備：http://hao.uisdc.com