設計師也能做到的開發成本預估
所謂術業有專攻，設計師不懂開發很正常，但設計稿能否落地最終還是得看程式師能否實現出來。
為什麼大家都覺得對牛彈琴？設計師大多數是藝術生出身和右腦思維者，比較擅長空間想像、藝術等方面的學習和工作；程式師基本是理科生出身和左腦思維者，
估計大多數設計師聽到“這個開發成本很大”“這個根本無法實現”時都會堅信不疑，即使懷疑也不知道怎麼去證明成本不是很大或者可以實現出來，然後跑去找降級方案，甚至最終方案和最佳方案有很大差距。
首先要非常非常客觀的說一件事，程式師最喜歡說的一句話“只要你給了方案我都能給你實現出來”這句話是基本沒錯的，
由於時間有限，
說一點動效實現。動效實現一直是國內大部分程式師的短板，首先大部分電腦專業沒有專門教前端或者用戶端開發的課程，
在專案流程上，設計屬於開發的上游，所以設計師有義務對自己的設計稿把關後才交付給開發。
先對比一下設計師和程式師如何看待整個產品：
從圖上可知道設計師關注的流程在程式師眼裡等於整個產品的業務邏輯和全域架構的實現，思考點遠比流程要複雜很多；設計師也一直忽略（準確點是無法關注）性能的問題。
再瞭解一下程式師拿到你的設計稿如何第一時間快速評估技術成本的：
（在新標籤頁中打開，即可查看大圖）
再瞭解一下程式師在開發時是如何審視整套方案並再次評估技術成本的(已與多名BAT程式師確認過)
由於預估很難做到深入評估，所以在後期開發時會暴露出更多與實現架構和業務邏輯相關的問題。設計師可以通過該圖對自己的設計稿進行技術成本預估，但最終評估需要結合實際實現架構和業務邏輯進行實際分析。
該圖標注的“設計師無法察覺”是專業技能上的壁壘，即使設計師懂點代碼最多只知道這個介面怎麼搭建起來，但演算法和實現架構等方面仍是接觸不到的，所以設計師可以不用指望懂點html css就能和程式師平起平坐“聊技術”，在一個自己毫無接觸過的領域和人家過招簡直就是找死關鍵是不知道怎麼死。
上面那句話估計是大多設計師希望懂點代碼的原因，即使接觸不了技術壁壘，設計師仍有其他途徑瞭解技術成本高的背後原因以及找到能落地的最佳方案。
多瞭解開發上的專業術語和自己開發團隊的獨有術語。將代碼理解成一個拼圖。每塊拼圖都用一個術語或者專業名詞代替，瞭解該拼圖怎麼使用(input)以及用途是什麼(output)，每塊拼圖的output可能決定著下一塊拼圖的input。站在更高的層面看待問題。程式師和架構師的區別是程式師是寫代碼的，架構師是負責整體實現框架和拼圖設計以及將每塊拼圖順序整理好，再讓程式師去實現每塊拼圖。即使設計師不懂寫代碼，也可以站在架構師小弟的層面去學習看待整個產品架構。如果有類拼圖突然更改了使用方法，而這類拼圖又被沿用到各個領域，這時候你應該能大概判斷出這個實現成本有點大。有意識去判斷資料間的聯繫，學會瞭解每個資料間的聯繫。例如耳朵鼻子嘴巴都屬於一個集合“臉”，無名指食指屬於一個集合“手”，而“無名指動嘴就動”屬於不同集合間資料的聯動，本來無名指動跟嘴動就毫無關係，神醫辛辛苦苦把關係建立起來，然後你微微一笑告訴神醫其實我想無名指動則耳朵動，結果是神醫微微一笑看著你倒在血泊裡。學會判斷產生高併發的問題。高併發的難度最主要是很多用戶同一時間訪問伺服器抓取資料庫資訊，甚至需要在伺服器上對資料進行處理。可以理解為“無名指動自己趴下”的無理需求變為更為無理的“無名指動瞬間整個學校學生都趴下”，工作量和難度上升幾個指數級別。設計師需要判斷自己的設計稿是否存在資料即時動態變化並且大量使用者即時拉取該資料的情況，與程式師溝通以及做好相關處理。多用Google學會搜索。演算法難度大不大這個要根據具體功能具體哪個程式師實現來判斷，設計師無法評估。如果真的解決不了演算法問題，你可以在網上找到相應的演算法或解決方案提供給程式師讓他們重新評估實現難度。#這個非常難做到#該圖標注的“業務邏輯（設計師甚少考慮）”更多是指功能和流程，以及它們所影響的覆蓋面；再深入一點即是剛剛所述拼圖的順序以及改動拼圖所造成的影響。這需要設計師對產品整體功能和流程有全域的認識和把控。
以上方法更多關注整體開發成本，這有一定的學習成本和難度；接下來我介紹一下關於介面開發成本評估並可迅速上手的方法。
為了更好解釋開發成本，我將開發成本進一步拆分為技術成本，時間成本和心理成本。技術成本已在上文所述，介面實現除動效外開發成本不會很高；時間成本需要在實際專案中根據工作量與程式師的能力和人數進行評估；心理成本是指該程式師願不願意做#很無奈但可以其他手段解決的一項成本#。設計師可以根據以下流程來預估開發成本。
*校驗成本屬於時間成本的一部分；數字僅表示量化成本間的差距，為個人觀點僅供參考，最終成本需要按照實際情況而定。
最後再給一些設計稿標注的建議，有利於後期開發完成後的UI Review(視覺還原)。
複雜的設計稿最好能標注圖層層級，有利於開發理解你的設計稿層級關係（貌似沒見過有設計師這樣做）可以簡單瞭解一下iOS，Android的佈局方式如LinearLayout(線性佈局)、AbsoluteLayout(絕對佈局)、TableLayout(表格佈局)、RelativeLayout(相對佈局)等等，不同佈局可以有更為合理的標注方法。瞭解Margin(容器外間距),Padding(容器內間距)是什麼。所有的間距都是由這兩個屬性決定，而不只PSD裡兩個圖層間的距離，設計師需要知道這一點。可以考慮在3px或4px倍數的基礎上設計。盡可能減少多樣化的間距，例如有些7px有些9px，在程式師的眼裡7px跟9px沒什麼區別，所以在寫代碼時不會嚴格按照你的標注進行開發，然後就有勞設計師的圖元眼了。動效實現上盡可能自己先拆好分動作和時間後再交給開發，參數調節等可以讓開發實現完再統一修改。設計和開發一樣都需要有理有據。這些經驗和技巧能幫助我在設計階段能更好地考慮開發成本，減少了後期因為開發成本原因重新改稿的幾率；更重要的是它能更好地輔助我實現想法，也可以在限制條件下做到更好的設計，或者低成本實現最佳方案。
以上就是我身為設計師和程式師的一些經驗，希望對大家有幫助。
作者：薛志榮（微信公眾號：薛志榮），百度交互設計師，二年級生
本文由 @薛志榮 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自 unsplash
思考點遠比流程要複雜很多；設計師也一直忽略（準確點是無法關注）性能的問題。再瞭解一下程式師拿到你的設計稿如何第一時間快速評估技術成本的：
（在新標籤頁中打開，即可查看大圖）
再瞭解一下程式師在開發時是如何審視整套方案並再次評估技術成本的(已與多名BAT程式師確認過)
由於預估很難做到深入評估，所以在後期開發時會暴露出更多與實現架構和業務邏輯相關的問題。設計師可以通過該圖對自己的設計稿進行技術成本預估，但最終評估需要結合實際實現架構和業務邏輯進行實際分析。
該圖標注的“設計師無法察覺”是專業技能上的壁壘，即使設計師懂點代碼最多只知道這個介面怎麼搭建起來，但演算法和實現架構等方面仍是接觸不到的，所以設計師可以不用指望懂點html css就能和程式師平起平坐“聊技術”，在一個自己毫無接觸過的領域和人家過招簡直就是找死關鍵是不知道怎麼死。
上面那句話估計是大多設計師希望懂點代碼的原因，即使接觸不了技術壁壘，設計師仍有其他途徑瞭解技術成本高的背後原因以及找到能落地的最佳方案。
多瞭解開發上的專業術語和自己開發團隊的獨有術語。將代碼理解成一個拼圖。每塊拼圖都用一個術語或者專業名詞代替，瞭解該拼圖怎麼使用(input)以及用途是什麼(output)，每塊拼圖的output可能決定著下一塊拼圖的input。站在更高的層面看待問題。程式師和架構師的區別是程式師是寫代碼的，架構師是負責整體實現框架和拼圖設計以及將每塊拼圖順序整理好，再讓程式師去實現每塊拼圖。即使設計師不懂寫代碼，也可以站在架構師小弟的層面去學習看待整個產品架構。如果有類拼圖突然更改了使用方法，而這類拼圖又被沿用到各個領域，這時候你應該能大概判斷出這個實現成本有點大。有意識去判斷資料間的聯繫，學會瞭解每個資料間的聯繫。例如耳朵鼻子嘴巴都屬於一個集合“臉”，無名指食指屬於一個集合“手”，而“無名指動嘴就動”屬於不同集合間資料的聯動，本來無名指動跟嘴動就毫無關係，神醫辛辛苦苦把關係建立起來，然後你微微一笑告訴神醫其實我想無名指動則耳朵動，結果是神醫微微一笑看著你倒在血泊裡。學會判斷產生高併發的問題。高併發的難度最主要是很多用戶同一時間訪問伺服器抓取資料庫資訊，甚至需要在伺服器上對資料進行處理。可以理解為“無名指動自己趴下”的無理需求變為更為無理的“無名指動瞬間整個學校學生都趴下”，工作量和難度上升幾個指數級別。設計師需要判斷自己的設計稿是否存在資料即時動態變化並且大量使用者即時拉取該資料的情況，與程式師溝通以及做好相關處理。多用Google學會搜索。演算法難度大不大這個要根據具體功能具體哪個程式師實現來判斷，設計師無法評估。如果真的解決不了演算法問題，你可以在網上找到相應的演算法或解決方案提供給程式師讓他們重新評估實現難度。#這個非常難做到#該圖標注的“業務邏輯（設計師甚少考慮）”更多是指功能和流程，以及它們所影響的覆蓋面；再深入一點即是剛剛所述拼圖的順序以及改動拼圖所造成的影響。這需要設計師對產品整體功能和流程有全域的認識和把控。
以上方法更多關注整體開發成本，這有一定的學習成本和難度；接下來我介紹一下關於介面開發成本評估並可迅速上手的方法。
為了更好解釋開發成本，我將開發成本進一步拆分為技術成本，時間成本和心理成本。技術成本已在上文所述，介面實現除動效外開發成本不會很高；時間成本需要在實際專案中根據工作量與程式師的能力和人數進行評估；心理成本是指該程式師願不願意做#很無奈但可以其他手段解決的一項成本#。設計師可以根據以下流程來預估開發成本。
*校驗成本屬於時間成本的一部分；數字僅表示量化成本間的差距，為個人觀點僅供參考，最終成本需要按照實際情況而定。
最後再給一些設計稿標注的建議，有利於後期開發完成後的UI Review(視覺還原)。
複雜的設計稿最好能標注圖層層級，有利於開發理解你的設計稿層級關係（貌似沒見過有設計師這樣做）可以簡單瞭解一下iOS，Android的佈局方式如LinearLayout(線性佈局)、AbsoluteLayout(絕對佈局)、TableLayout(表格佈局)、RelativeLayout(相對佈局)等等，不同佈局可以有更為合理的標注方法。瞭解Margin(容器外間距),Padding(容器內間距)是什麼。所有的間距都是由這兩個屬性決定，而不只PSD裡兩個圖層間的距離，設計師需要知道這一點。可以考慮在3px或4px倍數的基礎上設計。盡可能減少多樣化的間距，例如有些7px有些9px，在程式師的眼裡7px跟9px沒什麼區別，所以在寫代碼時不會嚴格按照你的標注進行開發，然後就有勞設計師的圖元眼了。動效實現上盡可能自己先拆好分動作和時間後再交給開發，參數調節等可以讓開發實現完再統一修改。設計和開發一樣都需要有理有據。這些經驗和技巧能幫助我在設計階段能更好地考慮開發成本，減少了後期因為開發成本原因重新改稿的幾率；更重要的是它能更好地輔助我實現想法，也可以在限制條件下做到更好的設計，或者低成本實現最佳方案。
以上就是我身為設計師和程式師的一些經驗，希望對大家有幫助。
作者：薛志榮（微信公眾號：薛志榮），百度交互設計師，二年級生
本文由 @薛志榮 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自 unsplash