凯发国际

  • <tr id='Ew09CB'><strong id='Ew09CB'></strong><small id='Ew09CB'></small><button id='Ew09CB'></button><li id='Ew09CB'><noscript id='Ew09CB'><big id='Ew09CB'></big><dt id='Ew09CB'></dt></noscript></li></tr><ol id='Ew09CB'><option id='Ew09CB'><table id='Ew09CB'><blockquote id='Ew09CB'><tbody id='Ew09CB'></tbody></blockquote></table></option></ol><u id='Ew09CB'></u><kbd id='Ew09CB'><kbd id='Ew09CB'></kbd></kbd>

    <code id='Ew09CB'><strong id='Ew09CB'></strong></code>

    <fieldset id='Ew09CB'></fieldset>
          <span id='Ew09CB'></span>

              <ins id='Ew09CB'></ins>
              <acronym id='Ew09CB'><em id='Ew09CB'></em><td id='Ew09CB'><div id='Ew09CB'></div></td></acronym><address id='Ew09CB'><big id='Ew09CB'><big id='Ew09CB'></big><legend id='Ew09CB'></legend></big></address>

              <i id='Ew09CB'><div id='Ew09CB'><ins id='Ew09CB'></ins></div></i>
              <i id='Ew09CB'></i>
            1. <dl id='Ew09CB'></dl>
              1. <blockquote id='Ew09CB'><q id='Ew09CB'><noscript id='Ew09CB'></noscript><dt id='Ew09CB'></dt></q></blockquote><noframes id='Ew09CB'><i id='Ew09CB'></i>

                 返回亚游 設為亚游              資▓源已找到,加載中...... 請稍等!          網站地圖google地圖百度地圖同行旅遊RSS |

                  資訊>|新聞|人物訪談|新手教程|網絡營銷|互聯網絡|站長故事|網站設計|網絡應用|

                  分類>|百度推廣|谷歌推廣|騰訊推廣|必應推廣|雅虎|搜狗|搜索|炒作|軟文|博客|綜合|

                  目錄>|推廣故事|域名空間|故事|編程|合作|休閑|人才|招聘|論壇|博客|站長|休閑|

                >> | 設為亚游 | 加入收藏 |

                設計師如何做能夠完成開發成本預估
                設計師如何做能夠完成開發成本預估
                   點擊數:198  更新時間:2017/11/24 18:51:19
                  身為█一名具有開發背景的設計師,我來講講程序員是怎麽思考你的設計稿的;再介紹一個比較簡單的開發成本評估方法,有助於你自行評估自己的設計稿,這樣你的設計稿落地可能性會高一些。
                  所謂術業有專攻,設計師不懂開發很正常,但設計稿能否落地最終還是得看程序員能否實現出來。這時候問題來了,有些設計師的創意很天馬行空,但拿到程序員面前程序員說不可能實現時,簡直心如死灰,內心萬馬奔騰:這都做不了,**。此刻程序員心理:連這個常識都不知道,我都不想說話了。
                  為什麽大家都覺得對牛彈琴?設計師大多數是藝術生出身和右腦思維者,比較擅長空間想象、藝術等方面的學習和工作;程序員基本是理科生出身和左腦思維者,比較擅長邏輯推理等方面的學習和工作,所以可以認為兩者的思維方式不太一樣。
                  估計大多數設計師聽到“這個開發成本很大”“這個根本無法實現”時都會堅信不疑,即使懷疑也不知道怎麽去證明成本不是很大或者可以實現出來,然後跑去找降級方案,甚至最終方案和最佳方案有很大差距。
                  首先要非常非常客觀的說一件事,程序員最喜歡說的一句話“只要你給了方案我都能給你實現出來”這句話是基本沒錯的,因為只要有充足的時間去想和實現,沒有解決不了方案。那為什麽又用“這個開發成本很大”“這個根本無法實現”而拒絕你的方案呢?最終還是時間問題,但決定時間最終還是由方案難度以及程序員的能力如智商,經驗和編程能力和人力所決定,抽象概括為一個反比例函數Y=Z/X(Z為常量)。
                  由於時間▓有限,程序員不想把時間浪費在一些對自己沒有產生價值的工作上如調視覺細節,我先簡單介紹一下程序員想做和不想做的事情:
                  說一點動效實現。動效實現一直是國內大部分程序員的短板,首先大部分計算機專業沒有專門教前端或者客戶端開發的課程,更不用說動效實現教學;加上網上缺乏相關資源以及動效實現強依賴設計(自己單幹不了),所以程序員學習動效開發相當困難。好的動效需要慢慢調整出來十分消耗時間,所以大部分程序員不喜歡把時間浪費在動效實現上。#逼著一個人幹短板的事情估計誰也不願意,設計師應該要理解#
                  在項目流程上,設計屬於開發的上遊,所以設計師有義務對自己的設計稿把關後才交付給開發。身為一名具有開發背景的設計師,我來講講程序員是怎麽思考你的設計稿的,再介紹一個比較簡單的開發成本評估方法有助於你自行評估自己的設計稿,這樣你的設計稿落地可能性會高一些。
                  先對比一下設計師和程序員如何看待整個產品:
                  從圖上可知道設計師關註的流程在程序員眼裏等於整個產品的業務邏輯和全局架構的實現,思考點遠比流程要復雜很多;設計師也一直忽略(準確點是無法關註)性能的問題。
                  再了解一下程序▓員拿到你的設計稿如何第一時間快速評估技術成本的:
                  (在新標簽頁中打開,即可查看大圖)
                  再了解一下程序員在開發時是如何審視整套方案並再次評估技術成本的(已與多名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沒什麽區別,所以在寫代碼時不會嚴格按照你的標註進行開發,然後就有勞設計師的像素眼了。
                  動效實現上盡可能自己先拆好分動作和時間後再交給開發,參數調節等可以讓開發實現完再統一修改。
                  設計和開發一樣都需要有理有據。這些經驗和技巧能幫助我在設█計階段能更好地考慮開發成█本,減少了後期因為開發成本原因重新改稿的幾率;更重要的是它能更好地輔助我實現想法,也可以在限制條件▓下做到更好的設計,或者低成本實現最佳方案。

              2. 上一篇文章:

              3. 下一篇文章: 沒有了
              4. 【字體:
                  網友評論:(只顯示最新10條。評論內容只代表網友觀點,與本站立場無關!)
                相 關 文 章
                沒有相關文章
                最 新 推 薦

                Copyright © 2005 - 2011 亚游集团 chczz.com All rights reserved. 聯系郵箱:chczzcom#163.com
                中國信息產業部備案編號:渝ICP備09029879號-2
                本站全部資源來自於互聯網,只供學習,不得用於商業,如有侵犯版權請聯系告知,來信請務必附上版權申明及相關證據,我們將第一時間刪除.