非常干貨系列之UI設計師也可以做開發(fā)成本的預估

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 多了解開發(fā)上的專業(yè)術語和自己開發(fā)團隊的獨有術語

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

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

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

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

4. 有意識去判斷數(shù)據(jù)間的聯(lián)系，學會了解每個數(shù)據(jù)間的聯(lián)系

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

5. 學會判斷產生高并發(fā)的問題

高并發(fā)的難度最主要是很多用戶同一時間訪問服務器抓取數(shù)據(jù)庫信息，甚至需要在服務器上對數(shù)據(jù)進行處理?？梢岳斫鉃?ldquo;無名指動自己趴下”的無理需求變?yōu)楦鼮闊o理的“無名指動瞬間整個學校學生都趴下”，工作量和難度上升幾個指數(shù)級別。設計師需要判斷自己的設計稿是否存在數(shù)據(jù)實時動態(tài)變化并且大量用戶實時拉取該數(shù)據(jù)的情況，與程序員溝通以及做好相關處理。

6. 多用Google學會搜索

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

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

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

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

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

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

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

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

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

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

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

5. 動效實現(xiàn)上盡可能自己先拆好分動作和時間后再交給開發(fā)，參數(shù)調節(jié)等可以讓開發(fā)實現(xiàn)完再統(tǒng)一修改。

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