前端工程師如何與設計師合作？

01-06

大學畢業一年不到，期間算上實習也近一年半，沒有正式地與設計師合作過。近來公司來了一個平面的設計師，第一次嘗試網頁設計，雙方都沒有相互合作的經驗。網頁選擇了響應式的設計，對設計師而言比較新穎，不能一開始很好理解。也因為個人的一些想法會與設計師不一致，想問幾個問題：

如果非專業的網頁設計，如何可以儘快地讓雙方更有效的合作？

作為一個前端工程師，在實現設計師的設計稿時，如果有自己的一些想法怎麼辦？是直接什麼也不說，直接照著設計稿做；還是提出一些建議交流？

如果是設計師全權負責設計的話，那前端工程師在github、codrops，Dibbble上看到先進優秀的效果，是不是就沒有用武之地了？

先就個人認識方面的經驗，回答一下你的問題，僅供參考：

1. 如果非專業的網頁設計，如何可以儘快地讓雙方更有效的合作？

要有一個共同的目標的前提下溝通，如果目標不一致，或沒有目標，那就沒辦法溝通。

比如我們有一個宣傳活動，這個活動的最終目的就是吸引新用戶註冊，那我們交流溝通時，完全以這個為目標，與這個偏離太遠的直接砍掉，否則加進來。

另外要有第三者中立方存在的情況下溝通，比如技術負責人，項目經理等。要不然責任劃分不明確，場面容易失控，當主題偏離太遠的時候迅速拉回來，意思就是討論是說的在多，最終得有個人拍板，有個清醒的旁觀者。

2. 作為一個前端工程師，在實現設計師的設計稿時，如果有自己的一些想法怎麼辦？是直接什麼也不說，直接照著設計稿做；還是提出一些建議交流？

有想法可以跟設計來交流，可以提自己的想法，但也有做好被拒絕的準備。不要強推觀點，想法。另外就我個人的經驗，先做好前端本職的事情，注意弄清需求，文檔，功能是否容易實現，更謹慎的評估時間，一般的經驗就是工作不飽和，自己份內的事情沒做好就想這想那的。

3. 如果是設計師全權負責設計的話，那前端工程師在github、codrops，Dibbble上看到先進優秀的效果，是不是就沒有用武之地了？

技術永遠是在找尋發現價值，只是一個工具，不能本末倒置。

然後是分享一點我們積累的知識，僅供參考：

來自於群內周五晚上的一次頭腦風暴式的思維碰撞交流活動。

文章版權屬於群內發過言的任何一位同學，我只是做了簡單的梳理或整理。

一般設計師給前端的只有psd，沒有其它多餘的東西，連基礎的文檔都懶得給。前端期望中的設計能給予的除了psd之外，還有設計上游崗位傳遞下來的東西。比如：產品原型，需求文檔，交互文檔等等。

一般在真正的代碼開發進行之前，前端期望中設計給的東西有：

1. 1份jpg文件: 裡邊有各個psd的動作分解圖，包括頁面邏輯，或交互分解。設計師放成這樣的目的在於在做設計時方便的拷貝，但對開發人員來說，如果分級過於隱藏就會漏掉某個部分的開發。

2. 1份psd文件: 一份好的psd文件是分層清晰，設計規範的文件。

3. 1份需求文檔: 需求文檔是對當前開發功能的基礎介紹或邏輯詳細描述。

4. 1份原型文檔: 原型設計文檔一般是由產品經理對最初功能設想的一份粗稿，這份稿只是對布局或交互做簡單的設計，需要經過設計進行藝術的加工之後，才成為一個可以呈現給用戶的完整界面。

當然這些所有的結果，需要經過層層開會審核，徵得各個項目組leader的同意之後通過郵件的方式發送給各個成員，最粗笨的辦法就是放在區域網的共享地址可以去拿psd文件。

恩，然後所有的中間需求變更、界面變更都要抄送相關人員，免得中間再次溝通，浪費時間。

一般的psd或許是這樣的：

其實期望的是這樣的：

因為前端要還原頁面的時候頻繁的去隱藏不同的圖層來觀察效果或切割圖片，設計師是組合不同的圖層到一塊，而前端恰恰是一個相反的過程。

所以一個好的圖層結構會為下游崗位節省很多的時間。那這時候有個問題，做為前端，你為下游崗位提供了多少便利之處呢？

還有公司更詳細流程是這樣的：

1、需求提出，產品跟產品leader溝通需求

2、產品leader跟開發、測試、ui/ue要人，要排期

3、要來的人大家一起開發，挑戰產品經理，跟批鬥似的，產品拿著需求文檔講ppt

4、需求回歸

5、繼續批鬥（4、5一直重複）

6、需求ok了，開始ui/ue設計

7、評審ui/ue

8、ui/ue回歸

9、開發

10、提測

11、回歸

12、上線

13、有問題回滾。

另外公司的設計是這樣的：通常PSD要把交互效果的圖層都做好，出JPG的時候，

都會把默認狀態，交互狀態，管理員狀態各自出一個，然後彈窗布局出一個，都做得很精細。

這樣導致的結果是想犯錯都沒有機會。

有的公司設計部有自己的規範，首先他們出的圖都是很合乎規範的，

間距、色值、布局、字體不會很多，因為整個產品多個頁面風格要統一一致，

所以越花哨是越給自己找麻煩，他們也不會有特別多種不同規格混揉在一起。

比如是這樣的：

還有的是跟產品開需求會或項目立會的時候，會先就具體需求的功能點先做可行性方案的討論，

如果開發成本過高的話，通常都會說服需求方用一些替代方案。

又或者是一些高級的功能模塊，我們會把項目拆解，分成幾期，首先先出核心功能模塊，上線之後再做一些高級需求的模塊，實現產品的迭代開發。

關於標註規範，推薦：

Super Marker

小鬍子哥的切圖神器

另外一個觀點是從產品的高度來看，設計、前端、後端應該是一個整體，最終應該結果導向，

產出的產品不好，作為開發團隊其實都有責任。

還有的情況是，每個項目都會有匯總目錄，原型是由需求直接提供的，PSD和JPG在設計的匯總目錄里，我們的製作稿又是一個匯總目錄，所有環節的童鞋都可以非常直觀方便的查看這些文件。

然後跟設計交流的時候的坑有以下幾種情況：

1. 有些界面出於時間或員工本身經驗素質的問題就是不願意出psd圖，然後口頭上通知前端，這樣來就可以那樣改就可以了，這就是一個坑。

按我們的經驗對這種情況做出的建議是：

所有的東西都必須出效果圖，並且所有團隊成員達成一致，有可執行性。

所有的字體，間距，顏色，必須約定統一併且完全標識清楚。

杜絕直接這麼說那麼乾的做法。

要不然最後做出的產品，

產品說的是一套，測試測的一套，開發的一套，老闆看到的又是一套，

返工的可能性很大。

我感覺比起這個返工的可能呢，前面多化點把設計稿做好是無可厚非的，

而且從整個項目開發周期來看，是節省開發周期的。

2. 有些頁面設計師沒有考慮到，比如：

有些頁面在沒有數據的時候設計師沒考慮到，或者經驗不豐富就沒做。

這時候必須要求設計師，給出首頁或列表頁、內容詳細頁、用戶中心等等沒有數據時的效果圖，

以示團隊所有成員知曉，並達到一致。要不然等上線之後，測試數據刪除之後真實數據還沒有上來之前，

老闆心情好要看一下的時候，頁面就整體失控。

還有一種情況就是前端自己整的數據沒有的提示，

從交互形式，文案上都沒有規範，導致最後一步測試的時候在返回來重新修改，浪費時間。

3. 數據過多的情況：

另外一種常見的問題是數據過多或者文字內容過長撐開容器，

這兩種問題再實際做的時候常常會被漏掉，

然後等到測試的時候才發現問題提過來。

還有兩種情況會遇到：

A. 有些前端在看到設計稿的時候，難免看的不舒服，這時候就從非專業的角度開始提建議，但提的時候又不流行技巧，容易發生衝突。

這時候給出的建議是：

提意見是這樣的，除非你干過設計或者了解設計的創作過程，否則從設計的角度最好不要提不同的意見。

可以從交互或功能或體驗上給建設性的意見，

另外講的時候是需要技巧的，可以先正面肯定一下他的勞動成果或努力的結果，

然後說，我這兒看到幾點問題，跟你交流一下，然後布啦布啦，

而不是直接上去就說，我感覺這兒怎麼怎麼的，很主觀的，說這樣根本沒有一個評判的標準或依據。

最後一定要說，根據你的行業經驗或自我設計標準，你肯定不會允許這樣的現象出現吧，然後你看要不要在重新考慮一下。我就是想到了給你提一下。

強調這個非正式的提法，給自己或對方都留有餘地，都有可以退讓的空間，皆大歡喜。

B. 要是效果圖是客戶提供的怎麼破？在溝通是有什麼經驗？

設計的質量如果本身就有問題，比方說就沒考慮添加數據以後的情況，

或者是其它頁面在流程上風格上不統一怎麼怎麼的，

客戶又不是很懂，初期非要你按照他的想法來。

這時候就需要站在一個更高的高度來有技巧的處理這個問題。

比如說，你這個頁面等上線後，在用戶看來2個頁面看到的按鈕不一樣，

感覺很外行，從而導致的結果就是下次不在訪問，這樣用戶就會丟失。

你看有沒有必要重新考慮一下。

最後設計和開發，去年克軍在廣州的webrebuild 分享了他那個「還原活的設計」的主題，我覺得挺受用的。

跟大家分享一下。

還原活的設計地址：

還原"活"的設計 · kejun

我們的qq群是：492107297 ，禁止閑聊，非喜勿進~！

你去了解一下各種GUI設計和WEB頁面設計的工具發展史，就知道該怎麼合作了。

謝邀，每個團隊的合作方法不盡相同，我接觸過的比較好的合作方式，我就直白口水話方便易懂，僅供參考：

如果你是前端，你可以給設計師提以下一些要求：

1.如果想要95%以上還原設計稿，你必須提供給設計師設計時的注意事項，當然如果設計師有前端功底，他的設計會考慮到更多的協作性，通俗點說：比如設計的PSD稿件的圖層切圖的形狀不要太另類，不同的解析度，元素布局上你能不能敲代碼實現，容不容易做出來，不要太自我主義不考慮前端，到時候做出來的東西又返回頭改死人，甚至前端出來後一塌糊塗，兩敗俱傷

2.你看過的或者項目交互上想要的效果，讓設計師分析這種效果拆分後該設計些什麼東西？設計量有多少？能不能用圖形的方式直觀的設計出來？等等

3.自己用鉛筆在紙上畫的草圖，設計中的部分重要細節和你自己的想法要親自提醒設計師

4.項目碰頭的時間段，如何碰頭，使用遠程工具？使用QQ？還是直接離開辦公椅面對面？還是茶水間？是1天碰頭一次？還是設計完某部分碰頭一次？發現問題就可以及時修改，避免事倍功半

5.讓設計師準備好詳細的設計說明文檔，文檔可以是直接套用html模板，可以是word，可以是圖片或者思維導圖，總之要讓前端設計師一目了然知道為什麼這麼設計，這樣設計讓前端怎麼用，怎麼配合

6.如果設計師有前端功底，你還需要讓他提供一些他設計時考慮到的插件或者代碼（比如設計banner時他想要視差，3D，還是滑動等效果，要用到什麼插件，用了什麼框架等），這樣能提高前端的質量和效率

同時，你需要讓設計師給你提供：

1.完整的，規範的PSD分層文件，最好是要切圖的部分就是一個圖層或者文件夾，使用photoshop的快速切圖插件，單獨導出圖片，快速準確，不建議使用PS默認的切圖工具

2.詳細的，規範的設計說明文檔，標註文檔

3.對於有前端基礎的設計師，需要提供他設計時考慮到的前端效果插件或代碼，是否使用前端框架等

4.適合你們的溝通協作方式

5.如果是比較有經驗的設計師，能給你提供一個demo（可以是視頻，或者gif，甚至是用紙和筆畫出的交互效果），能大大提高前端的質量和效率

最後的最後，前端攻城師和設計師互相提供這些需求和資源的同時：

不要忘記了產品經理或者老闆或者你們部門的項目初衷，也要做好和上層的對接。

在過程中試錯，在試錯中體驗，在體驗中修改優化，在修改優化中培育協作能力和感情，在協作和感情中喝杯咖啡聊聊天泡泡妹子！

---------------------------------------------------------------------------------------------------------------

不要怕溝通起來，或者隨時跟著進度溝通協作麻煩，其實互相交心，多溝通，大家都能開心的做好前端和設計，可以大幅度減少返修，減少加班，同時還有空一起去喝杯咖啡緩緩神！

你悶著頭做前端不去學習或者多了解一下他的設計和他的想法，或者他悶著頭做完設計從來不關心代碼是啥東西，做完就丟給你，只會兩敗俱傷，傷感情！

有效的合作一定要有人起協調和領導作用。前端和設計師合作最靠譜的辦法就是設計師懂點前端，或者前端懂設計（或者上面還有產品經理或設計總監一類的人做領導），起碼有一個人要有全局觀。

你這設計師連網頁設計都不懂，走流程化的方法（一個先設計，一個再實現）效率低下。這種情況應該走去流程化，以溝通為導向。2人在一個桌子上，一起設計，前端有想法直接跟設計師講，設計師有不合理的地方直接否掉，讓溝通更高效。

另外要明確每個人的優勢在哪裡。題主的場景里，字體，布局，色彩這些可以讓這個設計師做。響應式設計題主做。

下次有想法早點說咯，設計稿都定了，你這讓設計師這碗飯很難吃呀…

鹵煮說的設計師概念比較寬泛。我說說我自己的見解吧，簡單聊聊～好的咩

1、前端和ui設計師的合作。

ui設計師對用戶界面的體驗負責，更多的偏向於視覺層面的用戶體驗（和視覺設計師的一部分工作重合），說白了就是讓用戶看著這款產品很爽，賞心悅目。

因此ui designer一般會對所負責的產品線制定相應的視覺規範，並對所設計的網頁設計稿做像素級別標註。

因此前端在這一部分要有對應的css開發功底和規範來讓你切圖製作出的靜態頁面100%還原ui設計師的想法，這也就是為啥很久之前一些大公司會專門有重構崗的原因。

2、前端和ux設計師的合作。

ux設計師主要指交互設計師或是用戶體驗設計師，基本就是把prd還原為產品原型，輸出產品邏輯這麼一個過度角色。這一部分角色有時候是產品經理直接自己做了，但大多是還是需要ue交互設計師來協助。界面的操作細節，用戶體驗和整個產品跑下來的邏輯都在這一環節體現。

產品的交互和邏輯體現在了多方面。

1、人機界面交互：js對dom的操作，js開發完成界面上的用戶行為操作，jser可以使得這一部分的界面功能操作起來更流暢，視覺和觸覺效果更好，提升用戶體驗。

2、整個產品的邏輯順暢：ux設計出來的整個產品流程，其實本質就是頁面與頁面之間鏈接或者介面的跳轉，好的產品邏輯可以引導用戶完成產品設計者想要用戶達到的一個結果同時還能給用戶帶來良好的使用體驗。

這一部分需要前端與後端的通力配合，介面的數據結構和邏輯設計、介面的性能，頁面展示速度和性能都會影響產品邏輯的體驗，因此，前段要做好的事情還真不少。

和設計妹子談戀愛

還有更多的前端開發和設計師是同一個人，免了撕逼的時間和精力

互虐關係，為了還原設計圖，作為一個挑剔的，強迫症，完美主義設計師已經被我司安卓，ios，網頁前端恨死……我不止一次氣的心塞......我們私交很好，只是在工作上.......不說了，我要繼續虐安卓了......

如果非專業的網頁設計，如何可以儘快地讓雙方更有效的合作？

如果你說的是網頁設計師是『非專業的』，可能首先就有一定成分的主觀色彩。我覺得既然是一個團隊一起做產品，特別是小型團隊，相互的信任以及溝通是成功最關鍵的要素。作為一個合格的前端工程師，應該充分相信設計師對產品的理解和設計，相信設計師的專業素養。一般來說網頁設計或者移動端設計都有一些通用的準則。試著站在客戶的角度考慮，很多設計都應該是自然和符合邏輯的。只要這些準則和邏輯沒有大的問題，作為工程師不應該強行要求設計師改變他的設計。

不過如果你說的是網頁設計的要求或類型是『非專業的』，那大家都隨便點，互相把設計和實現的難點交流一下就沒什麼問題了 :-/

作為一個前端工程師，在實現設計師的設計稿時，如果有自己的一些想法怎麼辦？是直接什麼也不說，直接照著設計稿做；還是提出一些建議交流？

如果沒有自己的想法就糟糕了——既然是小型團隊，設計師大概可以隨叫隨到吧，去把你的想法跟他交流一下，看他有什麼建議。你作為非專業設計，有時候其實有『旁觀者清』的眼光，也許能看到設計不足的地方，設計師會很感謝你跟他交流的。不過一定要謙虛，避免給人盛氣凌人的錯覺。

如果是設計師全權負責設計的話，那前端工程師在github、codrops，Dribbble上看到先進優秀的效果，是不是就沒有用武之地了？

一個成熟的團隊需要成員之間充分的信任——信任產品設計，信任進度管理，信任工程師技術，信任市場和銷售團隊，信任團隊招募的每一個人都很出色。也許你看到一些不錯的設計，也許你覺得這些設計用在你們團隊的產品里很合適，但是很可惜你不是設計師。對於一款產品的設計，不同的人有不同的眼光，沒有絕對正確的解決方案。但是作為設計師，他分內的工作就是更加了解產品，客戶以及設計準則，有比你更高的可能性設計出更為優秀的產品。作為前端工程師的你，要做的就是提供技術角度的考量（比如指出某種設計細節可能在技術上難以實現，或者與現有框架難以兼容、重用等），幫助設計師打造出更優秀的設計，然後將它按期高質量的實現出來。

呃....兩件事情我一個人幹了,前端更厲害一些

不看github、codrops，Dibbble的設計師根本稱不上是設計師

一個人做咯

PM的價值體現就是整個開發流程的把握。

前期立項時的碰頭會，要分析需求，然後形成需求文檔，架構師根據需求文檔出結構文檔並原型。

PM審完這部分之後要有修改意見或定版，定版之後PM分發原型以及需求文檔結構文檔給設計師和前端。

前端就可以開始構造頁面主體結構了，這期間設計師開始配色、調效果、合成頁面PSD，當PM審完設計師的設計圖後分發給前端開始生成頁面。

我現在在從事ui，不過正在學習前端準備轉崗前端，根據我做設計的經驗來看，如果前端有一些比較好的想法我們是可以一起討論的。如果是非專業的網頁設計你可以建議他按照設計的一些規範來做，或者你發現哪裡不規範了也可以向他提出來（這種一般是接觸工作不久，可能有很多細節還不是很清楚……）。關於看到的一些好的效果之類，同意樓上的說法，不能本末倒置~我們的任務是儘可能還原設計稿，而特殊效果之類可以在設計的時候和設計師討論，是否可以應用到設計中，否則拿到設計稿的時候基本已經是終極版了……如果這時候要添加什麼特效，像一整個網站這樣的工程，修改的話工作量還挺大的，會一定程度的影響效率