我覺得應該各司其職吧。前端就是負責實現設計的頁面。可是老被前端質疑。說我的頁面做得不合理。


估計是因為你不懂技術

同樣身為設計師,我待過的每個團隊的程序員都很願意跟我合作。我接收到最多的來自程序員的評價也是:「她不會給我們做不出來的設計稿」。

IT行業的設計師很難成為理想主義者,因為我們需要在很多限制內盡量做出最好的設計來幫助用戶解決問題。而項目上最大的限制往往有三個:人不夠,錢不夠,技術上實現起來太困難。

見過很多設計師,出的圖乍一看很漂亮,再多看兩眼立馬會發現很難實現。很多不懂技術的設計師經常在圖上多畫幾個線,多加幾個效果,可能程序員就要多花很多個小時去編程來實現效果圖。這些細節多了,不單單是要花前期編程實現的時間,更會增添以後長期維護起來的精力。

而IT行業的好的設計師應該是一個優秀的平衡者,如何用設計真正解決客戶的問題,並且讓程序員少寫一些「無用」的代碼。

並不是說不能在設計圖上追求完美,追求更好的用戶體驗精益求精估計是每個設計師的本能。但我是想說,在效果圖上加上的每一個小點都應該慎重。每次畫圖我都會不斷思考這些問題,我這裡需要加多一個點,那這個點有沒有用,是有真實的用途,還是僅僅只是為了符合我自己的審美,它能給客戶帶來多大的好處,可不可以刪掉,刪掉有多大影響,加上這個點之後編程會不會很難實現,實現起來需要花多長時間,會給今後長期維護帶來多少的工作量,等等。對我來說可能只是在設計圖上一個靈光乍現而加上的點,可能就需要程序員多花很多時間來實現,可能會讓公司/客戶最終多花一些不必要的錢,所以我要對我做的設計負責,對我參與的項目負責。

我做設計的過程中很喜歡跟程序員配對(pairing),問問他們的意見,聽聽他們的想法,調整設計難度,解釋設計背後的想法。而這也是一個很重要的溝通過程,設計與創意不單單需要讓客戶理解它的重要性,也要讓創意的真正實現者去了解這個設計的原因。很多時候在不斷溝通的過程中,程序員瞭解到了這樣做設計背後真正的目的,瞭解到了這個設計能帶來的好處,也會願意花加倍的時間來實現這些可能有些複雜的創意,因為他們理解到「這個時間他們花的值得」。

我也經常會在畫設計圖的時候,順便把相關的code在網上搜出來看看,看看難不難實現,評估一下是否有其他的設計方式可以替代。最後把設計圖和相關的code一併轉交給程序員。大家都省時間,最終項目也能更高效的完成。

設計師和程序員應該是相輔相成,相互理解的好夥伴/好戰友的關係,畢竟我們的目標是一致的,都想項目/產品最終做好。

「各司其職」在當今成熟的IT團隊裏來看真的是不太現實,好的前端必然懂用戶體驗設計,而優秀的設計師也應該懂技術,才能在最短的時間裡讓優秀的設計真正投入應用得以實現。


作為一個前端,在考慮問題時和設計肯定有角度上的差異的。

美感: 這方面,不是所有的前端都有發言權。儘管很多前端同學美感很好,但是設計師畢竟是喫這口飯的。

功能性: 這一點,作為前端是很想吐槽的。很多設計師為了佈局和顏色的好看,對於功能的合理性思考不足的現象非常普遍。比如說用戶在實際場景中會不會使用這個功能,這個按鈕會不會不好點擊,使用體驗會不會跳脫,數據交互上會不會因為太複雜而造成難以優化的卡頓。很多設計師甚至對佈局的可伸縮性都不考慮,這方面前端技術的同學在評估的時候肯定要說的。不然做出來之後這個鍋算誰的?

可實現性:想說飛機稿真是見的多了。隨著能力和經驗的增長,雖然有一些飛機稿都想方設法的搞出來了,但是實現的成本是相當高的。產品的同學要求這個迭代兩週上線,設計師為了一個動效搞的研發同學要增加好幾個工作日來做。這種設計,前端同學能不說麼?

理想的情況是,設計同學能稍微對技術多瞭解一點,這樣對自己的設計也能有所幫助。技術同學也要多從設計師的角度上考慮。任務是個人的,成功是團隊的。最重要的不是設計要怎麼樣,也不是技術要怎麼樣,甚至不是說用戶要怎麼樣。最重要的是如何找到產品價值和商業的平衡點。Everything is about trade-off


很正常,高級前端(以及高級測試)的核心技能之一就是精通用戶體驗。所以,前端挑戰你的設計再正常不過了。有話好好說,共同打磨出好產品就是了。


我是個前端程序員。

工作上遇到的設計人員給出的設計稿,通常有這三個問題:

1.有些是隻給個設計稿的png圖片(對界面要求不高)。

2.有些給的設計稿PSD文件結構混亂,使用pxcook等代碼生成工具艱難。

3.設計稿沒能完全符合需求,可能有遺漏。

4.設計要求的交互動效模糊

如果前端說的是這幾個問題,那麼就需要設計修正自己的問題了。否則如果是前端實現設計困難,就需要前端找找自己的原因了。

另外如果矛盾很大,找一下上級,這個時候需要團隊進行溝通


應該鼓勵技術提意見,團隊的意義就是不同職能的同事為同個目標協作達成。不同職能的人所涉及的領域不同,互相協作能避免工作上出現未考慮到的盲點。

技術質疑前期的需求和設計,能有效避免在限期內出現不可行性或高成本方案。

有一點需要注意,設計輸出階段,技術提的建議分為需求層和感知層。需求層會導致設計方案返工,需要提醒技術這類問題應在需求評審時儘早暴露。感知層問題需要設計評估建議是否合理決定是否接受。

不要認為技術只是實現層的執行者不能提意見,這是偏見。團隊所有成員都為需求方案的穩定和可行性負責,對事不對人。


推薦閱讀:
相關文章