CSS學習筆記(十四) 咱們前端是怎麼跟設計師溝通的

1.交付

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

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

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

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

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

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

固然這些全部的結果， 須要通過層層開會審覈， 徵得各個項目 組leader的贊成以後經過郵件的方式發送給各個成員， 最粗笨的辦法就是放在局域網的共享地址能夠去拿psd文件。而後，全部的中間需求變動、 界面變動都要抄送相關人員， 省得中間再次溝通， 浪費時間。

2.psd文件

通常的psd或許是這樣的：

前端人員期待的確實這樣的：

由於前端要還原頁面的時候頻繁的去隱藏不一樣的圖層來觀察效果或切割圖片，設計師是組合不一樣的圖層到一塊，而前端偏偏是一個相反的過程。因此一個好的圖層結構會爲下游崗位節省不少的時間。那麼，問題來了，做爲前端，你爲下游崗位提供了多少便利之處呢？

3.流程

有的公司是這樣的：

1. 需求提出，產品跟產品leader溝通需求
2. 產品leader跟開發、測試、ui/ue要人，要排期
3. 要來的人你們一塊兒開發，挑戰PM，跟批鬥似的，PM拿着需求文檔講PPT
4. 需求迴歸
5. 繼續批鬥（四、5一直重複）
6. 需求ok了，開始ui/ue設計
7. 評審ui/ue
8. ui/ue迴歸
9. 開發
10. 提測
11. 迴歸
12. 上線
13. 有問題回滾

而有的公司的設計倒是這樣：一般PSD要把交互效果的圖層都作好，出jpg的時候都會把默認狀態，交互狀態，管理員狀態各處一個，而後彈窗佈局出一個，都作得很精細。這樣致使的結果是想犯錯都沒有機會。

還有的公司設計部有本身的規範，首先他們出的圖都是很合乎規範的，間距、色值、佈局、字體不會不少，由於 整個產品多個頁面風格要統一一致，越花俏越給本身找麻煩，他們也不會有特別多種不一樣規格混揉在一塊兒。

還有的是跟產品開需求會或項目立會的時候，會先就具體需求的功能點先作可行性方案的討論，若是開發成本太高的話，一般都會說服需求方用一些替代方案。又或者是一些高級的功能模塊，咱們會把項目拆解，分紅幾期，首先先出核心功能模塊，上線以後再作一些高級需求的模塊，實現產品的迭代開發。

另一個觀點是從產品的高度來看，設計、前端、後端應該是一個總體，最終應該結果導向，產出的產品很差，做爲開發團隊其實都有責任。

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

4.吐槽

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

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

1. 全部的東西都必須出效果圖， 而且全部團隊成員達成一致， 有可執行性。
2. 全部的字體， 間距， 顏色， 必須約定統一而且徹底標識清楚。
3. 杜絕直接這麼說那麼幹的作法。要否則最後作出的產品，產品說的是一套， 測試測的一套， 開發的一套， 老闆看到的又是一套，返工的可能性很大。
4. 比起這個返工的可能，前面多化點把設計稿作好是無可厚非的，並且從整個項目 開發週期來看， 是節省開發週期的。

• 有些頁面設計師沒有考慮到。
  有些頁面在沒有數據的時候設計師沒考慮到，或者經驗不豐富就沒作。這時候必需要求設計師， 給出首頁或列表頁、 內容詳細頁、 用戶中心等等沒有數據時的效果圖，以示團隊全部成員知曉， 並達到一致。 要否則等上線以後， 測試數據刪除以後真實數據尚未上來以前，老闆心情好要看一下的時候， 頁面就總體失控。還有一種狀況就是前端本身整的數據沒有的提示，從交互形式， 文案上都沒有規範， 致使最後一步測試的時候在返回來從新修改， 浪費時間。

• 數據過多的狀況。
  另一種常見的問題是數據過多或者文字內容過長撐開容器，這兩種問題再實際作的時候經常會被漏掉，而後等到測試的時候才發現問題提過來。

5.溝通

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

  建議：除非你幹過設計或者瞭解設計的創做過程， 不然從設計的角度最好不要提不一樣的意見。
  能夠從交互或功能或體驗上給建設性的意見，另外講的時候是須要技巧的， 能夠先正面確定一下他的勞動成果或努力的結果，而後說， 我這兒看到幾點問題， 跟你交流一下， 而後布啦布啦，而不是直接上去就說， 我感受這兒怎麼怎麼的， 很主觀的， 說這樣根本沒有一個評判的標準或依據。最後必定要說， 根據你的行業經驗或自我設計標準， 你確定不會容許這樣的現象出現吧， 而後你看要不要在從新考慮一下。 我就是想到了給你提一下。強調這個非正式的提法， 給自 己或對方都留有餘地， 都有能夠退讓的空間， 皆大歡喜。

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

  建議：設計的質量若是自己就有問題， 比方說就沒考慮添加數據之後的狀況，或者是其它頁面在流程上風格上不統一怎麼怎麼的，客戶又不是很懂， 初期非要你按照他的想法來。這時候就須要站在一個更高的高度來有技巧的處理這個問題。好比說， 你這個頁面等上線後， 在用戶看來2個頁面看到的按鈕不同，感受很外行， 從而致使的結果就是下次不在訪問， 這樣用戶就會丟失。你看有沒有必要從新考慮一下。

6.閱讀

• 2013年，克軍在廣州的 webrebuild 分享了他那個 還原活的設計 的主題，很是受用。地址以下：http://kejun.github.io/share2013_11/

---

原文連接：咱們前端是怎麼跟設計師溝通的 - 豪情 - 博客園