資訊專欄INFORMATION COLUMN
摘要：前端期望中的設計能給予的除了之外，還有設計上游崗位傳遞下來的東西。份文件一份好的文件是分層清晰，設計規范的文件。有些頁面設計師沒有考慮到。地址如下原文鏈接我們前端是怎么跟設計師溝通的豪情博客園
1.交付
一般設計師給前端的只有psd，沒有其它多余的東西，連基本的文檔都懶得給。前端期望中的設計能給予的除了psd之外， 還有設計上游崗位傳遞下來的東西。 比如： 產品原型， 需求文檔， 交互文檔等等。
一般在真正的代碼開發進行之前，前端期望中設計給的東西有：
1份jpg文件
里邊有各個psd的動作分解圖，包括頁面邏輯，或交互分解。設計師方程這樣的目的在于在做設計時方便的拷貝，但對開發人員來說，如果分級過于隱藏就會漏掉某個部分的開發。
1份psd文件
一份好的psd文件是分層清晰， 設計規范的文件。
1份需求文檔
需求文檔是對當前開發功能的基礎介紹或邏輯詳細描述。
1份原型文檔
原型設計文檔一般是由產品經理對最初功能設想的一份粗稿， 這份稿只是對布局或交互做簡單的設計， 需要經過設計進行藝術的加工之后， 才成為一個可以呈現給用戶的完整界面。
當然這些所有的結果， 需要經過層層開會審核， 征得各個項目 組leader的同意之后通過郵件的方式發送給各個成員， 最粗笨的辦法就是放在局域網的共享地址可以去拿psd文件。然后，所有的中間需求變更、 界面變更都要抄送相關人員， 免得中間再次溝通， 浪費時間。
2.psd文件一般的psd或許是這樣的：
前端人員期待的確實這樣的：
因為前端要還原頁面的時候頻繁的去隱藏不同的圖層來觀察效果或切割圖片，設計師是組合不同的圖層到一塊，而前端恰恰是一個相反的過程。所以一個好的圖層結構會為下游崗位節省很多的時間。那么，問題來了，作為前端，你為下游崗位提供了多少便利之處呢？
3.流程有的公司是這樣的：
需求提出，產品跟產品leader溝通需求
產品leader跟開發、測試、ui/ue要人，要排期
要來的人大家一起開發，挑戰PM，跟批斗似的，PM拿著需求文檔講PPT
需求回歸
繼續批斗（4、5一直重復）
需求ok了，開始ui/ue設計
評審ui/ue
ui/ue回歸
開發
提測
回歸
上線
有問題回滾
而有的公司的設計卻是這樣：通常PSD要把交互效果的圖層都做好，出jpg的時候都會把默認狀態，交互狀態，管理員狀態各處一個，然后彈窗布局出一個，都做得很精細。這樣導致的結果是想犯錯都沒有機會。
還有的公司設計部有自己的規范，首先他們出的圖都是很合乎規范的，間距、色值、布局、字體不會很多，因為 整個產品多個頁面風格要統一一致，越花俏越給自己找麻煩，他們也不會有特別多種不同規格混揉在一起。
還有的是跟產品開需求會或項目立會的時候，會先就具體需求的功能點先做可行性方案的討論，如果開發成本過高的話，通常都會說服需求方用一些替代方案。又或者是一些高級的功能模塊，我們會把項目拆解，分成幾期，首先先出核心功能模塊，上線之后再做一些高級需求的模塊，實現產品的迭代開發。
另外一個觀點是從產品的高度來看，設計、前端、后端應該是一個整體，最終應該結果導向，產出的產品不好，作為開發團隊其實都有責任。
還有的情況是，每個項目都會有匯總目錄，原型是由需求直接提供的，psd和jpg在設計的匯總目錄里，我們的制作稿又是一個匯總目錄，所有環節的童鞋都可以非常直觀方便的查看這些文件。
4.吐槽跟設計師交流的時候的坑有以下幾種情況：
有些界面出于時間或員工本身經驗素質的問題就是不愿意出psd圖，然后口頭上通知前端，這樣來就可以那樣該就可以了，這就是一個坑。
所有的東西都必須出效果圖， 并且所有團隊成員達成一致， 有可執行性。
所有的字體， 間距， 顏色， 必須約定統一并且完全標識清楚。
杜絕直接這么說那么干的做法。要不然最后做出的產品，產品說的是一套， 測試測的一套， 開發的一套， 老板看到的又是一套，返工的可能性很大。
比起這個返工的可能，前面多化點把設計稿做好是無可厚非的，而且從整個項目 開發周期來看， 是節省開發周期的。
有些頁面設計師沒有考慮到。
有些頁面在沒有數據的時候設計師沒考慮到，或者經驗不豐富就沒做。這時候必須要求設計師， 給出首頁或列表頁、 內容詳細頁、 用戶中心等等沒有數據時的效果圖，以示團隊所有成員知曉， 并達到一致。 要不然等上線之后， 測試數據刪除之后真實數據還沒有上來之前，老板心情好要看一下的時候， 頁面就整體失控。還有一種情況就是前端自己整的數據沒有的提示，從交互形式， 文案上都沒有規范， 導致最后一步測試的時候在返回來重新修改， 浪費時間。
數據過多的情況。
另外一種常見的問題是數據過多或者文字內容過長撐開容器，這兩種問題再實際做的時候常常會被漏掉，然后等到測試的時候才發現問題提過來。
有些前端在看到設計稿的時候， 難免看的不舒服， 這時候就從非專業的角度開始提建議， 但提的時候又不流行技巧， 容易發生沖突。
建議：除非你干過設計或者了解設計的創作過程， 否則從設計的角度最好不要提不同的意見。
可以從交互或功能或體驗上給建設性的意見，另外講的時候是需要技巧的， 可以先正面肯定一下他的勞動成果或努力的結果，然后說， 我這兒看到幾點問題， 跟你交流一下， 然后布啦布啦，而不是直接上去就說， 我感覺這兒怎么怎么的， 很主觀的， 說這樣根本沒有一個評判的標準或依據。最后一定要說， 根據你的行業經驗或自我設計標準， 你肯定不會允許這樣的現象出現吧， 然后你看要不要在重新考慮一下。 我就是想到了給你提一下。強調這個非正式的提法， 給自 己或對方都留有余地， 都有可以退讓的空間， 皆大歡喜。
要是效果圖是客戶提供的怎么破？在溝通有什么經驗？
建議：設計的質量如果本身就有問題， 比方說就沒考慮添加數據以后的情況，或者是其它頁面在流程上風格上不統一怎么怎么的，客戶又不是很懂， 初期非要你按照他的想法來。這時候就需要站在一個更高的高度來有技巧的處理這個問題。比如說， 你這個頁面等上線后， 在用戶看來2個頁面看到的按鈕不一樣，感覺很外行， 從而導致的結果就是下次不在訪問， 這樣用戶就會丟失。你看有沒有必要重新考慮一下。
6.閱讀2013年，克軍在廣州的 webrebuild 分享了他那個 還原活的設計 的主題，非常受用。地址如下：http://kejun.github.io/share2013_11/
原文鏈接：我們前端是怎么跟設計師溝通的 - 豪情 - 博客園
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/111017.html
摘要：二標簽超鏈接型標簽超鏈接型標簽是一種被動型鏈接。四標簽與標簽非常相似，不同的是，它不是文本型的鏈接，而是區域型的鏈接。是整個規則中唯一支持非矩形熱區的標簽。 筆記說明 重學前端是程劭非（winter）【前手機淘寶前端負責人】在極客時間開的一個專欄，每天10分鐘，重構你的前端知識體系，筆者主要整理學習過程的一些要點筆記以及感悟，完整的可以加入winter的專欄學習【原文有winter的語...
摘要：二標簽超鏈接型標簽超鏈接型標簽是一種被動型鏈接。四標簽與標簽非常相似，不同的是，它不是文本型的鏈接，而是區域型的鏈接。是整個規則中唯一支持非矩形熱區的標簽。 筆記說明 重學前端是程劭非（winter）【前手機淘寶前端負責人】在極客時間開的一個專欄，每天10分鐘，重構你的前端知識體系，筆者主要整理學習過程的一些要點筆記以及感悟，完整的可以加入winter的專欄學習【原文有winter的語...
摘要：二標簽超鏈接型標簽超鏈接型標簽是一種被動型鏈接。四標簽與標簽非常相似，不同的是，它不是文本型的鏈接，而是區域型的鏈接。是整個規則中唯一支持非矩形熱區的標簽。 筆記說明 重學前端是程劭非（winter）【前手機淘寶前端負責人】在極客時間開的一個專欄，每天10分鐘，重構你的前端知識體系，筆者主要整理學習過程的一些要點筆記以及感悟，完整的可以加入winter的專欄學習【原文有winter的語...
摘要：瀏覽器最基本的排版方案是正常流排版。元素非常特別，瀏覽器對的處理是先排入正常流，再移動到排版寬度的最左最右主軸的最前和最后。瀏覽器支持的每一種排版方式，都是按照對應的標準來實現的。 筆記說明 重學前端是程劭非（winter）【前手機淘寶前端負責人】在極客時間開的一個專欄，每天10分鐘，重構你的前端知識體系，筆者主要整理學習過程的一些要點筆記以及感悟，完整的可以加入winter的專欄學習...
閱讀 1026·2021-11-23 09:51
閱讀 2344·2021-10-08 10:22
閱讀 2544·2021-09-29 09:35
閱讀 854·2021-09-22 15:20
閱讀 2859·2019-08-30 15:53
閱讀 2413·2019-08-30 13:55
閱讀 1097·2019-08-29 17:27
閱讀 2869·2019-08-29 17:26
