對接開發的重要性
作為產品設計師，無論在什么公司什么崗位，都免不了與研發團隊進行溝通，如果不進行溝通就無法交付我們的設計稿，即便很成熟的團隊也會出現在溝通上的問題，在產品研發的過程中溝通是必要的流程，為了創造一致的用戶體驗，設計師需要與開發人員在視覺上、交互上達到一致的想法，但是講起來簡單，說起來難，在整個過程設計師和開發都是站在不同的角度去看待問題的，我們思考的如何達到美觀的界面、流暢的交互等問題，而開發關心的是做這件事我需要花費多長時間，實現難度如何等等，首先目標就不在同一個維度，那么必然會造成我們在對接的時候出現掰扯的問題，最后耽誤的都是雙方的時間，更嚴重點頁面最后的體驗也沒有達到一致。
任何團隊都會出現設計師與開發脫節的問題很常見，遇見什么問題解決什么問題，畢竟人與人的性格、溝通方式等都是不同的。
我們只需要在不同的流程里去做不同的事情就可以避免這些問題了，對于任何設計師基本都會適用，往下看～
1. 產品信息文檔確認
在接到一個需求的時候產品經理會通知上下游進行需求的評審，這時候一般會是產品經理、設計師、開發三個組進行需求的評估，具體的需求評審在本章就不細講，我們此次主要講設計師與開發相關的信息同步。
在評審過程中產品經理會把需求背景、需求目標等相關信息同步給相關的人員，作為設計師這時候就要關注需求目標，這個目標不僅是產品經理的目標，也是整個項目的目標，所以與每個人都相關，需求目標清晰后期推動開發的時候才會有依據。
評審會議結束后，產品經理會同步期望上線時間，如果是常規需求，會當時就評估出設計時間、開發時時間，我們設計師這時候就要關注這些時間，因為我們通過上線時間就可以估算開發節奏，給我們后期的修改以及臨時添加的一些動效制作時間會留出充裕的時間。
設計評審流程細節本章不進行細節講解，本章重點講與開發對接。
近期我在公司做了一個商業化的直播項目需求，由于產品方沒有過多的產研經驗（后面才知道），在項目前期雖然進行了評審，但是評審的參與人員沒有拉上我，等到需求給到我的時候，我順便問了一下才知道已經評審完了，這對于我來講是沒辦法進行設計輸出的。
第一我不知道評審過程中開發的排期時間，以及測試時間，如果研發開始開發的時間與設計稿交付時間有沖突那么就是影響上線節奏。
第二涉及的交互操作產品經理是不清楚的，有沒有哪些地方需要加復雜的交互產品也是同樣不清楚，那么開發就會默認這是常規的交互，如果過程中添加那將會影響開發進度。
第三流程上不符合要求，期間如果有關鍵性信息沒有達到共識，那將會釀成很嚴重的后果。
面對這種已經發生的事情，如果重新拉個會評審一次會耽誤大家的時間，很多人是不愿意的，但是呢我也不能單聽產品一方面的溝通，因為很多細節他是不清楚的（產品經驗較少），所以當時我的處理方法呢是我先通過產品給出的上線時間，然后與前端同學單獨確認一下，這樣至少保證上線時間是同步的，至于其他的細節我當時是利用設計評審的方式同步給開發交互邏輯、動效方式等。
此次這個需求呢本身不大是在舊版的基礎上優化功能，理論上不需要走設計評審流程，但是因為當時沒有通知參加評審導致很多信息不同步，而我需要傳達給開發的東西也不能在后期在告訴他們，所以我利用設計評審流程把一些交互信息同步給開發。
2. 設計圖準備
在設計稿完成后，如果是小需求一般是直接交付給研發，如果是大需求一般會進行設計評審，主要評審維度是設計稿是否與產品文檔同步，設計目標是否符合產品目標等等，其次如果有復雜交互效果、設計細節、組件復用情況也需要與研發對齊。
若是直接交付研發，我們需要提前把設計稿內涉及的切圖、圖層間距、動效使用區域等關鍵信息提前準備好，避免在開發過程中臨時進行補充，影響開發節奏。
在設計稿內的切圖，我們要提前與研發溝通，切圖的范圍和形式，最后把設計稿傳入公司統一使用的協作網站，如藍湖、即時設計等平臺，大公司會有自己的協作平臺。
3. 確定設計規范組件
講個自己的踩坑案例，還是商業化的那個需求，由于為了商業化賦能，產品的需求文檔并沒有按照規范組件進行設計，但是由于產品文檔標注的不清楚，在設計過程中不斷與產品進行溝通，最后結果當然也是無法復用組件，當時我就把組件規范修改了，重點是研發不知道，我當時想的是研發通過產品文檔應該會了解到，事實確實我大意了，后面就導致組件方面我與研發進行了相愛相殺，通過自己的以身作則我勸大家不要忽略任何一個細節！
設計規范組件在設計前就需要進行確認，項目是否有存留的規范組件，如果有，需要在設計前以及設計中去確認哪些模塊是否可以調用，開發是否已經將組件寫入代碼中，如果不了解這些情況貿然的設計，那在對接過程中會出現修改設計稿的風險。
如果是創新項目并且沒有相關的設計規范和組件，我們則需要在設計前就把規范組件的時間給算到需求內，一個產品的規范組件，決定著后續產品是否嚴謹、項目研發效率等等，因為規范組件不止是設計師的事情，還是團隊研發比較關注的事情，研發們在代碼里同樣需要進行規范的組件復用。
4. 輸出設計文檔
當在做一些在舊版的產品頁面上優化的需求時，還需要輸出對應設計文檔，給前端和測試看，設計文檔需要寫清楚設計稿優化的點，例如圖標的細節優化、文字的字號優化、色彩優化、界面交互等等細節。
如果涉及到一些頁面的交互，我們在提供設計稿的同時需要把具象的交互文件單獨交給開發，不要奢望前端大佬們能腦補出頁面之間的交互，我們不及時提供的話，后期修改研發可能會直接拒絕，并且口吐芬芳～（最簡單的找到競品頁面演示給研發看）。
我的方法
前端在看我們設計稿時如果不是結構上的修改，他們不會去關注這些細節的點，而給測試看的目的是，有些公司測試會幫我們進行走查，如果不出設計文檔測試沒辦法進行對比（測試提 bug 比設計師提 bug 更具有一些權威性）。
這里看一下我工作中輸出的設計文檔，我會把需求的背景、目標在設計文檔上強調一下，再添加上設計目標，設計目標為了需求目標去賦能，這樣在文檔開始就與研發達成共識，讓研發是帶著共同完成目標的態度去看設計文檔，便于我們后續推動，其次放上頁面之間的說明。
5. 交付開發
最后總結一下，我們要交付給開發什么東西，首先是基本的設計稿，包括切圖、間距、動效文件，其次是設計文檔，包括需求背景、需求目標、設計目標、設計修改點說明。
1. 不要頻繁修改
在交付設計稿后（基本設計圖、設計文檔），我們就要避免頻繁修改，頻繁的修改會導致設計稿來回更新，對開發造成一種困惑，最后在測試的時候，開發同學容易寫亂，另一方面工作過的設計師都應該經歷過，我們在開發的過程中修改設計稿，大部分的開發都會帶點情緒，甚至不給我們改，這其實是因為大多開發的代碼寫的是比較規范統一的，如果中途進行修改可能會影響開發同學的代碼規范，就像我們在完成一個設計稿的時候，產品經理突然改變需求，我們也是擔心做好的設計稿因為修改而被打亂。
如果實在需要修改，一定要說明原因，而不是突然一個想法覺得這里設計不合適就進行修改（產品需求修改除外），我們要換位思考，具有同理心去工作，并且讓開發同學感受到我們是在幫助他們減少工作量，這樣在后續的一些需求中，我們的對接會很順暢。
2. 重要信息及時通知
上面說的是站在設計師的角度去修改，還有一種情況是研發在開發過程中，作為設計師的我們突然收到產品經理的修改建議，這時候我們需要及時的同步給開發，或者給開發同事達成共識信息，因為很多時候，產品經理讓我們修改的時候往往不會通知開發，因為對于產品經理而言就是一個小的修改，例如改個位置、改個顏色等等，但不管是對我們還是對于開發其實都是比較重要的，不及時同步就會出現不好的結果，如果在測試階段沒有發現問題，上線后就會造成設計師背鍋的情況。
我曾經在做一個頁面改版的時候，就遇到類似的問題，當時產品找到我說改一個地方的交互，并且我也覺得那個交互方式應該改，當時的我以為產品經理會同時告訴開發修改的地方，但是直到項目上線后開發都沒修改那個地方的交互，本來這個修改點是個小事情，誰知剛好那一個版本被用戶吐槽那個頁面的交互，結果可想而知領導拉個會議開始復盤，為什么沒有改，索性大家沒有互相甩鍋的情況，產品經理說沒有同步到開發，而我也是幫產品兜了一下說更新設計稿沒有告訴開發，這個事情原本是個很小的事情，只需要我順口同步給開發，就能夠避免的，就因為我沒有及時同步，造成用戶的反饋，影響了產品的體驗。
所以各位設計師工作中如果遇到類似的事情一定要及時同步！
3. 統一需求目標
開始講到過，在需求評審的時候要與開發對齊目標，為什么需要對齊目標，因為一個項目如果目標不對齊，那么每個人都會站在自己的角度去做這個需求，設計師思考的是通過設計的手段，去幫助產品完成目標，如果設計稿上的復雜效果較多的時候，開發則會考慮你為什么這么做，這么做開發成本非常高等等，這也是說為什么我們開始就講要輸出設計文檔，如果這一切都不存在的話就會導致開發是帶著疑問寫我們的頁面，如果過程中在修改需求什么的，那我們跟開發又要相愛相殺了。
我的設計方式是通常是在產品評審階段就與開發明確講清楚，我大概要做什么樣的效果，什么的交互形式，預計什么時候會交初步方案，中途也可能會有修改的點等等，提前讓開發有個心理預期，避免在開發過程中產生抵抗情緒。
我的經驗
4. 輸出交互動畫
如果在前期沒有時間進行動效設計并沒有關系，研發在開發過程中可以在把動效方面給空出來后續寫，這里講的交互動畫分為兩種，一種是展示的動畫，一種是 ui 中的動效。
展示動畫
目的是為了告知開發頁面運動的軌跡，在 1-4 中講到我個人用的方法，大家如果是剛對接研發的話，建議還是輸出完整的交互動畫，這里推薦一些工具 AE、Principle、Pixso、Figma 等。
AE：大家就比較熟悉了，經典的動效繪制軟件，什么樣的效果都能實現，但是使用成本比較高（不建議）
Principle：國外的一款交互軟件，制作頁面交互很方面，可以直接導入 figma 和 sketch，由于是國外軟件需要使用英文界面，但是國內也有漢化版。
Pixso：國產最新的設計軟件與 figma 類似，做交互的方式是使用多個頁面添加熱區進行使用，具體體驗如何還不清楚（可以用用）
Figma：設計軟件目前的天花板，流暢的體驗，支持頁面動畫設計，但是需要安裝插件才可以（建議使用）
動效文件
這個比較重要！我們一定要與研發同事溝通好，產品內使用什么樣格式的動效文件，統一后能提升后續的開發效率，動效格式使用亂套的話，后續我們做更新迭代時做替換會很麻煩，開發也同樣如此，這里推薦幾種動效格式文件，分別是 GIF、json、pag、svga 這 4 種。
GIF：傳統的動效文件格式，優點是學習成本低，第一個缺點是內存大，圖片容易失真模糊，他的原理就是把每一幀的圖片融合在一起，最后形成動畫，圖片越多，內存越大，第二個缺點是占用產品資源，當內存過高時，在加載時會出現卡頓。
Json：該文件格式是通過 Lottie 實現的，是 Airbnb 開發的一款能夠為原生應用添加動畫效果的開源工具，它的優點就是內存小、無需加載、動畫不會失真，缺點呢就是支持得動畫方式沒有 gif 那么全面，以及使用成本也比較高。
具體使用步驟是需要我們裝 ae 插件 bodymovin，通過插件導出 json，常遇見的問題就是在導出漸變動畫時，漸變效果會消失，這是因為我們 ae 安裝得都是中文版，而該插件更多的適配是英文版，不過沒關系這里可以把漸變效果的名字改為 gradient fill1 就可以了，如果多個漸變的話我們更改后面序列號就可以，比如 gradient fill1、gradient fill2、gradient fill3…，這里把漢化插件鏈接也給大家找到了。
網站鏈接：https://zdo.fun/?p=557
我的經驗
Pag：pag 是騰訊研發的一種技術文件，最初主要用于游戲動畫和直播動畫，用來解決復雜的動畫效果，目前在 ui 頁面中運用也比較多，優點是占比內存比 json 文件更小，支持的動畫方式也更豐富，運行時可編輯，缺點是適配原生有些問題，壓縮位圖時會出現不顯示，這個軟件目前還在完善階段，我曾經也使用過，后來因為適配問題就放棄了，感興趣的大家可以通過下面鏈接下載。
網站鏈接：https://pag.io/docs/install.html
svga：該文件格式的強大之處在于可以完整的將位圖轉換成二進制代碼，并且內存占比較于 json 更小，播放資源占用更低，并且技術上相對穩定（建議使用）
網站鏈接：https://svga.io/designer.html
我們看下 svg 實現的效果
最后，我們一定要統一產品內使用的動效文件格式，這樣既方便我們，也方便開發，讓開發看到我們設計師的嚴謹性，便于后續合作。
1. 跟進開發進度
作為設計師，我們需要實時了解開發的進度，這樣能夠保證我們在過程中掌握自己的設計節奏，什么時間交給開發動效文件，如果進行修改也可以不影響上線時間（當然不建議這樣做），那么具體需要怎么跟進呢，大概分為以下幾個維度。
時間進度跟進：
設計師可以時不時的問一嘴，是否能按照正常的計劃時間節點提測（正常需求提交后，開發會給出開發排期，盡量按照時間排期走，否則項目進度會變得很不可控）。
如果開發反饋時間會有延期風險，那設計師第一時間就要了解原因，以及預計延期多久，然后自身評估以下對設計上是否有影響。
需求變更跟進：
一般開發過程中，或多或少都會出現一些需求調整/變更的點，那么其中就會涉及設計上的改動，改動小的話產品經理有時候會直接告訴我們，并不會告訴開發，這時候如果身為設計師的我們要及時通知開發，并說明原因（避免爭論）。
并且，需求變更后，需要和開發評估新的項目上線時間點，站在我們或者產品角度理解有時候我們認為的修改，對于開發來講是耗費時間較長的，需要我們注意是否會影響上線時間。
交互動效實現跟進：
在 2-4 中講到我們要輸出交互動畫，雖然我們輸出的動畫很直觀，以及動效文件也完整，但是避免不了認知上的偏差，有時候開發會按照技術難度以及自身理解去完整交互效果，我們中途要隨時跟進了解，避免開發在錯誤的路上越走越遠。
測試跟進：
及時了解該需求是否已經提測、哪些還未提測，若到了提測時間的功能未進入測試，可以詢問產品或開發什么原因，這樣對項目或設計師都是負責的。
另外一點是我們設計師需要在提測階段介入 UI 走查，因為各個公司或者項目測試時間有長有短，所以我們要及時把 UI 走查工作介入進去，給開發預留出修改時間，有的小公司不重視 UI 走查流程，這里我們就可以自驅進行走查，主動找測試同學了解提測時間，及時走查，保證頁面還原度。
2. 設計走查
走查是 UI 工作中最為重要的工作，它決定著產品上線后能否完美的展現給用戶，下面我大致把走查的流程以及范圍給大家梳理下。
創建走查文檔
在 UI 走查階段，我們首先需要建立走查文檔便于開發瀏覽解決，走查文檔主要包含日期、版本、項目名稱、模塊、端口、問題描述、修改狀態、圖片標注，這樣一方面能夠讓問題更加詳細，體現設計師的專業度，一般我是使用在線表格去建立走查文檔，當然這個看每個公司所使用的協作平臺。
開通手機權限
一般在走查移動端產品時，安裝測試包需要開通賬號權限，這里可以找公司的開發或者測試同事給開通，避免影響走查效率。
走查范圍
分為基礎走查、細節走查、適配走查
基礎走查包含字體、顏色、圖標、間距、對齊方式等具體可根據產品形態進行延伸，其中間距走查比較費時間，需要我們通過測試機截圖后，按照倍數縮放到源文件內進行測量，測試機分辨率需要保證與設計稿一致，否則測量不準確，例如設計圖是 375*812，以 ios 為例測試機則需要使用與 375*812 分辨率相同的尺寸測試。
細節走查包含字體截字、按壓狀態、組件內容、交互狀態
適配走查包含關鍵信息是否超出屏幕、是否出現擠壓、是否出現重疊、識別度是否清晰
3. 避免添加復雜交互
在走查階段如果我們發現部分的交互效果不太理想，并未達到預期，我們可以與開發進行溝通是否可以修改，或者添加新的交互效果，因為在這個階段我們重新設計或者定義一個新的交互動效的話，會增加非常大的開發工作量，可能也會與開發產生爭吵，我們在這個時期盡量避免這個問題，如果實在沒有解決辦法的時候再去添加新的交互。
我在工作中，如果遇到這種事情，會分兩點考慮這個事情。
第一評估下當下這個交互效果是否會影響用戶體驗，如果影響用戶體驗我會要求開發必須 100%還原，當然我會講述清楚為什么改，避免讓開發產生情緒抵抗。
第二是如果不影響用戶體驗，但是還原度沒有達到預期，我同樣會先找開發進行溝通，例如按照交互稿還原會有什么困難，是時間上的困難還是技術上的困難，時間上如果困難我會溝通好下一期必須還原到位，技術上困難我一般會修改交互形式，盡量保證上線后給用戶展現的是完美的狀態。
4. 數據追蹤
作為設計師在需求上線后并不代表需求就結束了，我們還需要追蹤數據情況是好是壞，為什么我們設計師要去追蹤這個數據呢，追蹤數據是為了讓我們在工作中提升自己的設計價值，隨著現在互聯網發展逐漸飽和，那么企業對于各個崗位的要求也跟互聯網初期不一樣，以前我們只需要畫畫圖交付就可以了，但是現在的企業更看重的是綜合能力，說簡單點就是做 UI 的人很多，優秀的 UI 一樣很多，那么我們就得被迫提升核心競爭力否則就是被淘汰。
而追蹤數據其實就是增加我們得核心競爭力，同時也是能夠體現自己設計能力的一項內容，設計最終是為商業而服務的，但我們不能嘴上說說，而是要拿出實際的行動，這個行動就是數據，我們的設計如何為數據賦能的，如何幫業務達到目標等等，數據如何分析是個很龐大的體系這里只講下我們身為設計師為什么需要追蹤數據。
簡單講下工作中數據解析的案例。
下面是我做的一個直播商業化改版需求，改版背景呢是直播業務由原先的為 c 端用戶賦能改為，為 b 端企業賦能，通過與企業合作而產生價值，那么基于這個直播形態肯定是需要變化的，需求目標由原先的「用戶收益」改為「企業收益」，新的目標具體為提升企業品牌曝光點擊、互動、預約人數、提升直播在企業客戶測的感知收益。
案例
基于這個目標，其實不難發現，目標已經從用戶側改為大客戶，更多的是為企業去賦能，頁面的結構肯定需要進行變化的，左邊的圖呢是改版之前的，右邊的是改版之后的，那么我當時的思路呢其實就是基于數據方面去進行優化。
整體：產品策略添加了二級浮窗用來承載更多內容。
直播介紹：首先舊版策略是直播介紹對于用戶而言并不重要，用戶只需要通過看到直播標題就能夠了解大致直播內容，更多是以引導形式存在，所以信息外漏較少，而新的策略是講企業介紹默認展示在二級浮窗內，用戶可選擇關閉，提升企業感知。
投遞簡歷：舊版策略是需要側重用戶投遞率，因此在預約界面就展示入口，而新的策略是需要給企業強化觀看人數、預約人數從而提升客戶價值，基于這一點，我當時是通過數據后臺看了下預約頁面的點擊數據，發現點擊率最最高的是「投遞簡歷」入口，而「預約直播」入口點擊率相對較低，因此把投遞簡歷入口調賬到浮窗 tab 區域，降低層級，讓預約直播成為視覺焦點，而上線后數據也是符合預期。
企業關注：將企業名稱與關注結合并且放大，提升關注量，強化企業品牌感知和數據感知，關注與預約直播兩者無論數據高低，都是符合企業目標，從而便于業務人員與企業進行合作溝通。
從我這個案例中我們能清楚看到，基本上任何需求都是可以通過數據的維度，進行優化，并且通過量化指標提升設計價值，無論對公司還是個人都有很大收益，并且我們追蹤數據也便于后續我們與開發對接時，可以通過數據維度去促進我們設計上的修改、完善等工作，這也是為什么說我們需要對每個需求都要進行數據追蹤。
無論是對接前、對接中、對接后，在哪個階段都需要我們認真對待，熟知這些細節后，才能更好的與開發合作，進行項目推進，優秀的設計師不僅是專業和技術上的成熟，還需要有協作上下游的能力，在很多團隊中設計師跟開發都會面臨不一樣的挑戰最終可能會因為某些問題發生沖突，我們需要減少這樣的沖突。
作者：愛吃貓的魚
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司
