前端工程師如何和設計師溝通

摘要: 文章背景，來自於羣內週五晚上的一次頭腦風暴式的思惟碰撞交流活動。

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

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

通常在真正的代碼開發進行以前，前端指望中設計給的東西有：

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

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

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

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

固然這些全部的結果，須要通過層層開會審覈，徵得各個項目組leader的贊成以後經過郵件的方式發送給各個成員，最粗笨的辦法就是放在局域網的共享地址能夠去拿psd文件。

恩，而後全部的中間需求變動、界面變動都要抄送相關人員，省得中間再次溝通，浪費時間。

通常的psd或許是這樣的：

其實指望的是這樣的：

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

因此一個好的圖層結構會爲下游崗位節省不少的時間。那這時候有個問題，作爲前端，你爲下游崗位提供了多少便利之處呢？

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

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

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

三、要來的人你們一塊兒開發，挑戰產品經理，跟批鬥似的，產品拿着需求文檔講ppt

四、需求迴歸

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

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

七、評審ui/ue

八、ui/ue迴歸

九、開發

十、提測

十一、迴歸

十二、上線

1三、有問題回滾。

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

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

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

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

間距、色值、佈局、字體不會不少，由於整個產品多個頁面風格要統一一致，

因此越花哨是越給本身找麻煩，他們也不會有特別多種不一樣規格混揉在一塊兒。

好比是這樣的：

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

若是開發成本太高的話，一般都會說服需求方用一些替代方案。

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

關於標註規範，推薦：

http://barretlee.github.io/SuperMarker/index_cn.html

小鬍子哥的切圖神器

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

產出的產品很差，做爲開發團隊其實都有責任。

還有的狀況是，每一個項目都會有彙總目錄，原型是由需求直接提供的，PSD和JPG在設計的彙總目錄裏，咱們的製做稿又是一個彙總目錄，全部環節的童鞋均可以很是直觀方便的查看這些文件。

而後跟設計交流的時候的坑有如下幾種狀況：

1. 有些界面出於時間或員工自己經驗素質的問題就是不肯意出psd圖，而後口頭上通知前端，這樣來就能夠那樣改就能夠了，這就是一個坑。

按咱們的經驗對這種狀況作出的建議是：

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

全部的字體，間距，顏色，必須約定統一而且徹底標識清楚。

杜絕直接這麼說那麼幹的作法。

要否則最後作出的產品，

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

返工的可能性很大。

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

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

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

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

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

以示團隊全部成員知曉，並達到一致。要否則等上線以後，測試數據刪除以後真實數據尚未上來以前，

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

還有一種狀況就是前端本身整的數據沒有的提示，

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

3. 數據過多的狀況：

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

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

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

還有兩種狀況會遇到：

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

這時候給出的建議是：

提意見是這樣的，除非你幹過設計或者瞭解設計的創做過程，不然從設計的角度最好不要提不一樣的意見。

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

另外講的時候是須要技巧的，能夠先正面確定一下他的勞動成果或努力的結果，

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

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

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

強調這個非正式的提法，給本身或對方都留有餘地，都有能夠退讓的空間，皆大歡喜。

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

設計的質量若是自己就有問題，比方說就沒考慮添加數據之後的狀況，

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

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

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

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

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

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

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

跟你們分享一下。

還原活的設計地址：

http://kejun.github.io/share2013_11/

轉載自：http://www.cnblogs.com/jikey/p/4102881.html