當靠譜設計遇見不靠譜技術

8 評論 3034 瀏覽 16 收藏 8 分鐘

在小公司,尤其做移動應用的初創小公司,資金、資源有限,請不起技術大牛,也組建不了堅實的研發團隊,整個應用的開發往往交給一到兩個人。

而這些人的Web研發能力尚可,App研發參與過,經驗不多,如果項目時間允許,也能應付過來。

1

但是項目時間有限,研發實力有限,人手有限,這三個有限加在一起,再完美的設計最后呈現出來的界面美觀值、操作流暢值、整體體驗值都會大打折扣。

2

是的,很多在小公司供職的設計師都會有這種苦不堪言的經歷,我也是。

3

在沒接手A項目之前,與兩個初創人第一次見面聊的很興奮,通過兩小時聊天式的頭腦風暴,找到了這款應用的突破口。四個人一致認為照著這個思路重新設計,不管是從應用的視覺、操作、傳遞的價值觀、整體體驗,將是一場完美顛覆。

4

通過一個多月的原型與UI輸出,幾番修改敲定,最終呈現的高保真界面讓參與項目的所有人都感到十分滿意。

5

然而,當技術正式切入的時候,發現事情沒有想象中那么簡單。原本我和nana以為技術按照高保真界面開發就行了,界面中采用的布局和交互并沒有刻意標新立異,都是比較常見的,研發起來應該不費事。

結果,看到研發出來的頁面,我和nana差點哭了…..

……

好吧,該是認清事實的時候了。

我們做了一些補救措施,比如,UI界面上的行距、色值都逐一詳細地標注出來,讓技術一目了然,能UI和切圖做的盡量不讓技術做,減少技術負荷。

像這樣:

5

然后技術根據這些值一遍遍的調整,貌似有點效果,后來的驗收界面確實比之前好很多,越來越接近高保真了。

但是,由于UI和切圖都是一個人,把40多張界面一一標注,真苦了nana同學。

設計與研發銜接的不對等,絕對不是一個非典型事件。特別是C端產品,強烈要求界面美觀友好,操作簡單流暢,體驗美輪美奐。這對設計師是一個挑戰,但對技術更是一個挑戰。

7

設計師憑借自身經驗,再適當借鑒優秀的設計,設計出一套大家都滿意的方案不是太難的事情。而技術容易被自身經驗束縛,做慣了Web端開發,遇到新銳的移動端有點手足無措。

再加上新技術的持續學習,比如2014年興起的HTML5。據說HTML5.1將在2016年底發布,做技術的是否能積極應對新技術對互聯網產品的侵潤。

還有個很客觀的問題:人手不夠。

互聯網公司加班最多的莫過于研發,研發人手應該遠多于任何一個職位(銷售地推除外)。

小公司為了節約成本,研發就一到兩個人,甚至就一個人。項目時間緊,通常2個月就要發布一個完全不一樣的新版本。時間和精力的雙重壓力讓程序員來不及多思考多研究,出來的東西自然不會達標。

8

所以,靠譜設計難免會遇見不靠譜技術,咋辦呢?撕逼?毛用!撕完還是得繼續合作。再說,人也是辛辛苦苦趕出來的,說不定還熬夜了呢,要相互體諒。

其實這就跟小夫妻相處是一個道理,找到問題所在,磨合磨合再磨合…

當設計師接到一個項目,激情滿滿的擼袖子準備大干一場的時候,記得先跟項目里的技術先溝通溝通。

不是說根據技術呈現能力來進行設計。咱設計的產品是以用戶為中心,不是以技術為中心,更不是為完成項目為中心。

10

跟技術溝通的時候,聽聽他的項目經驗,看看他自認為最滿意的作品是什么樣子,從而能對他的能力水平有個大致了解。

如果技術人手充分,都有成熟的App開發經驗,項目時間也充足,那就使出渾身解數地大膽設計吧,把最完美的一面展現出來。

如果技術人手不夠,只參與過一兩個App開發,有的甚至沒有接觸過,項目時間又催得緊,這就需要設計師多做一些工作,甚至要做一些犧牲。

原型設計階段就邀請技術介入,遇到較特別的布局和交互,最好分A/B稿。A稿是設計師的實力和初心,B稿是考慮到技術呈現退而求其次,又不是很糟糕的設計。

11-2

如果自己的設計與市面上的App有相似之處,可以拿來給技術做參考。

當然,也許有的技術會否定大部分的設計,認為不好實現,或者沒時間細細研究。設計師也不能一味的委曲求全,全面衡量方案的難度,必要的時候了解一些技術相關的知識,該爭取的還是得爭取。

 

本文由 @老美(微信公眾號 laomay325) 原創發布于人人都是產品經理?,未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 標注都沒做就給開發了然后說開發不靠譜。。。這里發文章不審核的么

    來自廣東 回復
  2. ╮(╯▽╰)╭
    產品跟技術的矛盾。
    讓我們做產品的也很難做啊。

    來自上海 回復
  3. 當靠譜的設計遇到不靠譜的技術,設計獅:你妹的這么簡單都做不出來?那個XX產品不就這么做出來了?
    當靠譜的技術遇到不靠譜的設計,程序猿:TMD做設計都不腦子想想的?就這時間這資源這架構要做這么復雜的交互?敢不敢現實點?
    好吧說點認真的,作者明顯項目經驗還不多啊,居然出的UI稿都沒做好標注就給開發了?
    然后就像最前面兩句話,雙方都會覺得自己才是靠譜的,另一方是不靠譜的。這樣矛盾會越來越深(同樣常見于程序猿和產品汪、設計獅與產品汪)。所以首先得有個靠譜的項目經理把關技術難度和開發計劃,有個靠譜的產品來明確優先級,關鍵是明確出每個版本的可執行方案,而不是某一方認為的最佳方案。當然閹割過的方案總是讓人不愉快,解決方法不外乎兩種:加資源或者加時間。

    來自浙江 回復
    1. 謝謝,說的很中肯

      來自陜西 回復
  4. 不寫標注的設計,好意思說自己是靠譜的設計師。
    好意思說后面辛苦的把40多個頁面標注了,才好點。
    寫標注是本職本職,設計師工作不到位變成了程序不靠譜。

    請不要拿這種文章來逗我玩了

    來自福建 回復
    1. UI工作并不是我經手,所以單方面理解上有偏差。不過不標注的做法也多,看雙方水平和配合的默契程度了,首次合作的話標注確實是基本工作。

      來自陜西 回復
  5. ?? ??

    來自重慶 回復
  6. 影響進度的,或許不只是圖片占哪多少像素和人手問題

    來自四川 回復