網站的美術設計和前端工程師如何溝通？

12-26

像這樣溝通：

（左一為設計師，右一為前端工程師，別問我為什麼右邊看起來比較帥）

好啦。

由於題主沒什麼更詳細的情境描述，我只能從前端的角度，按自己理解來寫一下了。

我的經驗是，溝通不是問題( 哪個工程師不想和設計妹子多勾搭勾搭啊 )，規範才是。

理想情況下，只要設計出了圖，需求和設計評審過了，基本上就沒什麼需要特別溝通的地方了。前端工程師規劃網頁結構、切圖、下蹄寫代碼就好。

實際工作中遇到的需要溝通的地方有可能是：

設計太高大上，產品急於上線，前端罷工
設計太高大上，兼容性實現上問題很大，前端罷工
設計太高大上，跟現實技術差距太大，前端罷工
設計太丑，前端怕跳槽的時候成為黑歷史，前端罷工
設計沒問題，但每次設計可復用的元素太少，不成規範和體系，前端被如此搞了數次後罷工

前三個問題只能是設計讓步，也別在心裡罵「媽蛋公司給你發工資結果你丫這也不會那也不會」。相信我，只要有時間，只要有興趣，前端們不會不想去實現高大上的效果的。但在可用性和可看性之間，一個合格的前端工程師必須向前一個靠攏。

第四個問題可能需要倆人打一架然後設計師被開除，不在溝通範圍內。

(xiu~)

最後一個問題其實才是重中之重啊朋友們。合格的前端工程師們是一群長著11星座的鳥操著處女座的心的傢伙，能復用的就復用，能語義的就語義，復用和語義產生矛盾的時候他們能拿鍵盤砸自己( 真?Emo )，設計團隊不同的人或者相同的人每次設計差不多的頁面的時候標題大小都不一樣， margin 都不一樣，padding 都不一樣，背景顏色都不一樣，button 有時候是空心的有時候是實心的... 如此重複三十遍，直到前端崩塌。這個時候大家就該坐在一起吃吃花生米什麼的，制定下規範了（抱歉現在才說到主題）。

不管是設計師來驅動還是前端工程師來驅動，早一天規範出來，大家才能早一天都安心，效率才能得到保證。

在下所在的公司前段時間剛開始經歷了這個過程。由前端提出需要規範的需求，可親可愛的設計師們進行具體視覺風格的制定，主要有：

基準屏幕 ( 比如 iPhone 5 )
margin
padding
字型大小
按鈕集
色彩集
邊框
表單樣式
彈出層樣式
導航欄等通用組件

等...

經過這麼一搞，前端的代碼實現了復用，設計師養成了規範設計的良好習慣，公司產品也會實現視覺風格的偉大統一，想想都樂得不行了呢。還需要溝通什麼呢，完全不需要了～

。。。等等

這下怎麼勾搭設計妹子！
寫完了。
自此設計師們和前端工程師們的關係就像這樣了：

(挽

那我就說一下設計師的眼裡是怎麼溝通的吧。
今年畢業，和同學們也搭檔了好幾年了，每當一個項目開始的時候是這樣的。

設計：

「哇哦，你看我的這套創意*￥%*……」

前端：

「嗯……嗯……可以吧……好的」

進行了一大半之後……

前端：

「你看這效果，叼不叼」

設計：

「尼瑪這是坑爹啊……」

or
「這個像素不對，字型大小少了點，字體不統一，色差也有問題，圓潤度不夠，陰影呢？漸變呢？為什麼沒法自適應所有屏幕？手機打開好多錯位……%￥#*……」

頂樓說的很在理，設計和前端的溝通問題往往就是設計和技術的矛盾。所以優秀的設計師一般都是需要會做（至少懂一些）前端的，要麼就是純粹做閃屏的原畫設計師了吧？
設計規範確實很重要，比如這樣的災難：

腦補一下，圖層分成這樣給前端，簡直就想shi……

反過來看是這樣的

設計稿

實現效果：

說吧，你想怎麼死？

嗯，總之呢。
我的看法是首先雙方都有對對方的工作有一定的了解，方便實現共同的目標。
然後是雙方水平要差距不大，牛逼和坑逼一起還是坑逼
最後是搞好關係，是妹子就把了，是漢子就丟肥皂。因為同處於一個小組或者說搭檔去做網站，爭論是必然的，有一個很好的合作氛圍和彼此信任的心態才能突破創新。

第一次在知乎插圖片回答問題，諒解:)

以上

先吐個槽，不要用美術設計嘛），說成是交互設計、視覺設計多高大上　。。。
再謝個邀。。。不過邀請我我壓力很大，作為設計和前端兼任的人表示，完全是腦內溝通嘛。。。
憑著為數不多的沒同時做設計和前端的經驗，主要是下面的內容。
______________分割線______________下面是正經的_______________
我看了上面的回答，有些我想說的說過了，於是我決定主要說溝通時間的問題。不要做設計的時候不理前端嘛。。。我覺得設計師憑著合作經驗，大體可以判斷，哪些設計內容對於前端來說完全沒有問題，哪些設計內容可能會造成工期延長，頁面響應速度降低，瀏覽器兼容出問題等情況，遇到有這種情況的時候，如果沒有100%的把握，不要自己去判斷，不妨去找前端的同學商量一下，討論一下，可能5mins的時間都花不了，就會探索出一個完美的解決方案。這樣就會避免設計完了太高大上，前端罷工的問題。
我一直不贊成把產品開發流程中的環節割裂開來，順序工作，靠交付物互相聯繫的方式。比如產品做了PRD，這樣D那樣D，然後交互做了頁面交互，低保真原型，交給視覺做成PSD，扔給前端做成HTML，CSS，JS，再扔給後端。過程中只有交付東西的時候才進行討論。平時的團隊討論很多時候是大問題，細節問題常常討論不到。而交付東西的時候才討論，你的工作已經做完了，萬一出現了問題，不改前端要罷工，改了自己代價付不起。
我認為這樣的工作模式是一切團隊不和諧的根源，包括設計和前端不和諧，前端後端不和諧。產品開發不是流水線，即使用瀑布模型開發也不是流水線。
用戶體驗是一個綜合的東西，不僅關乎設計，也關乎代碼的質量，甚至什麼時候發布都是用戶體驗的一部分。所謂設計就是平衡，你的設計會給用戶帶來多少好處，而這樣的設計可能在前端實現一下會給用戶帶來怎麼樣的壞處，需要衡量，所以只從設計的角度是絕對無法把握用戶體驗的。因此需要大家共同參與，設計不只是設計師的事，因為你不是一個人在戰鬥。
而其實所謂的共同參與，就是平時多說幾句話的事。遇到細節問題，沒正式實施之前就可以討論一下，不僅可以避免誤會，說不定還能碰撞出火花。

我們做設計和做前端的是同一個人。前端這崗位太矯情了。當然除非是JS大牛。對付普通的web頁面，太輕鬆了。

前端正在伏案工作，電腦右上角突然浮現提示有一封新郵件，好奇的打開細看，赫然一段文字顯示：這是最終的psd，設計和產品都確定了，剩下就交給你了，下面那個psd靜靜躺在那裡，然後他站起身朝設計師的方向望去，怎能想到，設計師也在神色堅定的看著他，那眼神彷彿再說，加油！這次肯定不會在改設計，然後他突然想起他們協同制定設計和前端規範那晚，立刻感覺身體充滿能量，他毅然而又有力的又充滿信心的打開了那個psd， st和chrome……

作為一名 UI 設計師和 Web 開發者。
驗證質疑 @張小核桃的答案。

1 負責對象
設計師和前端的負責對象都是面對於產品經理，而非設計師或前端。
既然，設計師的設計稿在產品經理已經通過的情況下，為什麼前端需要罷工？這責任就是在前端身上。

然而，前端和設計根本就沒有溝通的必要（當然，這是基於有負責人的產品經理的情況下，產品經理能力不OK還是打醬油過日子要麼跳槽，別指望有未來了）。

2 工作流程
產品設計階段是，原型》效果圖》代碼編寫》Debug
前端的工作內容是發生在效果圖之後，也就是設計圖是已經通過的。

3 責任工時問題
一個 IT 項目，往往都是當時估算時間的 4 倍或更多。
這是事實的真相。
在我獨立開發的項目下，曾經最快的項目是「媽媽再打我一次（Mama，Hit me again!）」，在 2 天內實現了 Web 程序的上線（連續36小時的代碼編寫和調式），之後花了一週時間來重建 UI 和改善 Web 體驗（繪製 Logo，使用 Ajax 改善載入效果，CSS3 代碼改善體驗）。

然而，在我合作項目下，往往宣言一週的，基本都需要一個月來通過設計稿。

前期設計師和產品設計師（產品經理）溝通時間成本
設計版本遞送消耗時間
意見不統一

在前端方面，一個優秀的前端一般會在被折騰 2 ~ 3 次後，會自行產生一套合適告高速開發的前端框架。

插曲：
我在為 Curiosity 工作時候，由於各個項目（品牌差異）之間既存在相同的功能需求，又有差異的 UI 設計，後來我為其設計了一套直接在 HTML 頁面可調用 Javascript 函數的介面。並且把曾經共用 2 次或 2 次以上的 Function 全部合併到共用庫中，在開發下一個新的項目時候，已有功能就不需要專門為新的 HTML 來編寫了，只需要調用即可。

4 吐槽
說真的，這根本就不需要溝通。
這一切的問題，來自於那個「弱智」的產品經理！
在優秀的產品經理的眼前，這根本就是弱爆了的問題。

往往會發生這個問題，是由於團隊存在一個不懂技術不懂設計不懂產品的自稱為產品經理的人，這樣的產品經理我見得多了。

在設計產品的過程中，最莫過於需要功能抽象了。
如何學習抽象？去看看 OS 的發展歷史。不能理解 Windows 的註冊表為何產生和 Linux 為何使用以文件為中心的設計方法，都不是好的產品經理。

在系統中，一切只有文件。
最後，還是沒什麼好溝通的，做朋友一起吐槽產品經理就可以了。

前端工程師，注意，是工程師，工程師怎麼能和設計師交流，完全兩個星球的人。

只寫html,css,jquery 根本算不上"工程師"，頂多算前端設計師，前端設計師和視覺設計師是可以交流的。

據說在日本，寫html，css，那就是頁面設計師的活，因為實在太簡單

接觸分層次，步步攀高

上策：把實現部分給處女座前端才是還原100%的不二法寶。

中策：大家在工作外還有一些簡單的交流，這樣工作時能夠為對方更多的考慮。

簡單的說一下。
好的前端對一個看到一個頁面，會在腦中將這個頁面理解為 Dom樹，這個 Dom樹在腦中抽象成一個可視化的 3D結構。
不過看多了頁面，就不用老這麼玩了，都成習慣了。
前端簡單分為：頁面邏輯的合理性［＊產品］，Dom結構的設計，交互邏輯。
——這是一個前端怎麼想事情。

再說一說設計師。我所在的公司有兩個設計師，一個設計師是十分老成並且靠譜的，但是屬於友情幫忙，他的設計圖不需要我來關心任何細節，只需要在產品方面雙方確定所有的頁面邏輯。

另外一個設計師是剛剛參加工作，有非常好的情感，但是屬於剛剛接觸 Web設計，所以會出現諸如：排版／顏色／頁面結構化，這些方面的問題。他的設計稿的細節我將會重新的修訂（多花時間而已）。我們的Js庫在之前就已經建立好，所以我有精力去校準他設計上的失誤，我也會經常提醒他。
——上面是我們的設計師的工作情況。

來說一說怎麼交流。即使題主在問題中問：［設計師］和［前端工程師］怎麼交流，但事實上也無非是人和人之間應該怎麼交流才好。我們並非異類。
想好怎麼描述一個問題，想好完整的話術邏輯，嘗試雙方給出解決方案，心平氣和，不要著急。只要雙方的情商和智商都在正常水平，是可以交流的。如果你可以確定和你面對的不是一個正常人了，你可以放棄交流。

Jone Ive在討論蘋果的設計師和工程師如何交流的時候說：我們坐下來一起，去嘗試給出一個成熟的解決方案。工程師和設計師之間，並是水火不容的。

說到底，無非一個做人問題。

——————————————————
看了上面的答案，想補充一點。
千萬不要覺得誰凌駕於誰之上，大家都不是小孩子，沒什麼的。

毫無疑問的回答是：「好好溝通」（能給32個贊的好答案有木有！）。
我覺得有分情況的。
設計先進入公司，並工作了一段時間。沒有意外的話設計會比較強勢一點，然後你需要一起吃吃飯，聊聊人生，談談理想，走向和諧美好的生活。
前端先進入公司，並工作了一段時間。那相對來說你會掌握一定的主動權。
就目前接觸的來看，作為公司的同事，設計還是能夠良好溝通的，作為設計面對前端，還是會存在一定的衝突。排名第一的回答已經很好的說明了衝突產生（換成需要協商）的情況。大家掂量著來吧，怎麼說也是朝夕相處的小夥伴呢！！！
其實所有的一切歸根到底我覺得是兩點：
1. 一切為了產品好，@張小核桃所說的可用性和可看性的兩者的權衡方案。
2. 你好我好大家好，設計從設計中獲得成就感，前端從頁面功能實現中獲得成就感。而不是兩者都覺得自己委屈了，然後又很蛋疼的繼續工作。

想了一下，設計和前端都是我自己。。完全不需要溝通2333

我本來是網站平面設計，然後因為被前端罵多了，決定自己學習寫前端代碼，學習過程很痛苦。
現在樣式寫多了，發現美感差了，很多樣子不錯的設計，都因為前端難實現，時間又不夠而放棄了。
所以公司資源允許的話，最好還是設計和前端分開，如果不是將會設計能力和代碼能力都原地踏步。

剛工作一年的前端，我和我們公司設計真是不能交流，一交流工作基本是吵架。
她照原型（我們公司原型一般會參照某些網站，直接截圖，做出來的原型效果很好）做的UI基本和原型一毛一樣，甚至原型看起來更好看，而且還有些直接截圖原型。每次需要修改一點東西就直接和我說，UI上也不改的，有的時候我忘記改了，她還反過來罵我。更加讓人忍受不了的是，每次做的地方不合理，我和她說明一下，她會反過來說:我只管設計，至於怎麼實現是你們的事，你們必須按照我設計來。我能怎麼辦呢，我也很絕望啊。說實話我都想辭職了

簡單我先找個類似的案例或者畫個簡圖直接拿去問程序：這個你們搞的定不麻煩不直接說不行我就換反正設計這邊就我一個你們程序十幾號人我打不過

俺們木有交互設計。唯一的目標就是你看，這玩意能入庫。

UP主竟然還有美工.我司都是美術前端一塊整

沒事吃個飯，扯扯蛋。就知道怎麼溝通了