輯導語：作為產品設計師，除了處理日常的設計業務外，和其他業務人員進行對接、共同推動產品項目落地，也是必須完成的事情至于。那么在產品設計過程中，設計師要如何避免和開發或者其他人員之間的沖突，以推動產品的快速落地？不如來看看作者的經驗總結吧！

前段時間在進行面試的時候，問到很多候選人開發溝通上的問題上，大多人都回答的模糊不清，決定根據自己的過往經驗講一下在工作如何溝通協調項目。

本文分別以對接前準備、對接中避免摩擦、對接后追蹤三個時間段講解流程中應該注意什么。

一、對接開發的重要性

作為產品設計師，無論在什么公司什么崗位，都免不了與研發團隊進行溝通，如果不進行溝通就無法交付我們的設計稿，即便很成熟的團隊也會出現在溝通上的問題，在產品研發的過程中溝通是必要的流程，為了創造一致的用戶體驗，設計師需要與開發人員在視覺上、交互上達到一致的想法。

但是講起來簡單，說起來難，在整個過程設計師和開發都是站在不同的角度去看待問題的，我們思考的如何達到美觀的界面、流暢的交互等問題，而開發關心的是做這件事我需要花費多長時間，實現難度如何等等。

首先目標就不在同一個維度，那么必然會造成我們在對接的時候出現掰扯的問題，最后耽誤的都是雙方的時間，更嚴重點頁面最后的體驗也沒有達到一致。

任何團隊都會出現設計師與開發脫節的問題很常見，遇見什么問題解決什么問題，畢竟人與人的性格、溝通方式等都是不同的。

我們只需要在不同的流程里去做不同的事情就可以避免這些問題了，對于任何設計師基本都會適用，往下看～

二、對接前的準備

1. 產品信息文檔確認

在接到一個需求的時候產品經理會通知上下游進行需求的評審，這時候一般會是產品經理、設計師、開發三個組進行需求的評估，具體的需求評審在本章就不細講，我們此次主要講設計師與開發相關的信息同步。

在評審過程中產品經理會把需求背景、需求目標等相關信息同步給相關的人員，作為設計師這時候就要關注需求目標，這個目標不僅是產品經理的目標，也是整個項目的目標，所以與每個人都相關，需求目標清晰后期推動開發的時候才會有依據。

評審會議結束后，產品經理會同步期望上線時間，如果是常規需求，會當時就評估出設計時間、開發時時間，我們設計師這時候就要關注這些時間，因為我們通過上線時間就可以估算開發節奏，給我們后期的修改以及臨時添加的一些動效制作時間會留出充裕的時間。

設計評審流程細節本章不進行細節講解，本章重點講與開發對接。

近期我在公司做了一個商業化的直播項目需求，由于產品方沒有過多的產研經驗（后面才知道），在項目前期雖然進行了評審，但是評審的參與人員沒有拉上我，等到需求給到我的時候，我順便問了一下才知道已經評審完了，這對于我來講是沒辦法進行設計輸出的。

第一我不知道評審過程中開發的排期時間，以及測試時間，如果研發開始開發的時間與設計稿交付時間有沖突那么就是影響上線節奏。

第二涉及的交互操作產品經理是不清楚的，有沒有哪些地方需要加復雜的交互產品也是同樣不清楚，那么開發就會默認這是常規的交互，如果過程中添加那將會影響開發進度。

第三流程上不符合要求，期間如果有關鍵性信息沒有達到共識，那將會釀成很嚴重的后果。

面對這種已經發生的事情，如果重新拉個會評審一次會耽誤大家的時間，很多人是不愿意的，但是呢我也不能單聽產品一方面的溝通，因為很多細節他是不清楚的（產品經驗較少），所以當時我的處理方法呢是我先通過產品給出的上線時間，然后與前端同學單獨確認一下，這樣至少保證上線時間是同步的，至于其他的細節我當時是利用設計評審的方式同步給開發交互邏輯、動效方式等。

此次這個需求呢本身不大是在舊版的基礎上優化功能，理論上不需要走設計評審流程，但是因為當時沒有通知參加評審導致很多信息不同步，而我需要傳達給開發的東西也不能在后期在告訴他們，所以我利用設計評審流程把一些交互信息同步給開發。

2. 設計圖準備

在設計稿完成后，如果是小需求一般是直接交付給研發，如果是大需求一般會進行設計評審，主要評審維度是設計稿是否與產品文檔同步，設計目標是否符合產品目標等等，其次如果有復雜交互效果、設計細節、組件復用情況也需要與研發對齊。

若是直接交付研發，我們需要提前把設計稿內涉及的切圖、圖層間距、動效使用區域等關鍵信息提前準備好，避免在開發過程中臨時進行補充，影響開發節奏。

在設計稿內的切圖，我們要提前與研發溝通，切圖的范圍和形式，最后把設計稿傳入公司統一使用的協作網站，如藍湖、即時設計等平臺，大公司會有自己的協作平臺。

3. 確定設計規范組件

講個自己的踩坑案例，還是商業化的那個需求，由于為了商業化賦能，產品的需求文檔并沒有按照規范組件進行設計，但是由于產品文檔標注的不清楚，在設計過程中不斷與產品進行溝通，最后結果當然也是無法復用組件。

當時我就把組件規范修改了，重點是研發不知道，我當時想的是研發通過產品文檔應該會了解到，事實確實我大意了，后面就導致組件方面我與研發進行了相愛相殺，通過自己的以身作則我勸大家不要忽略任何一個細節！

設計規范組件在設計前就需要進行確認，項目是否有存留的規范組件，如果有，需要在設計前以及設計中去確認哪些模塊是否可以調用，開發是否已經將組件寫入代碼中，如果不了解這些情況貿然的設計，那在對接過程中會出現修改設計稿的風險。

如果是創新項目并且沒有相關的設計規范和組件，我們則需要在設計前就把規范組件的時間給算到需求內，一個產品的規范組件，決定著后續產品是否嚴謹、項目研發效率等等，因為規范組件不止是設計師的事情，還是團隊研發比較關注的事情，研發們在代碼里同樣需要進行規范的組件復用。

4. 輸出設計文檔

當在做一些在舊版的產品頁面上優化的需求時，還需要輸出對應設計文檔，給前端和測試看，設計文檔需要寫清楚設計稿優化的點，例如圖標的細節優化、文字的字號優化、色彩優化、界面交互等等細節。

如果涉及到一些頁面的交互，我們在提供設計稿的同時需要把具象的交互文件單獨交給開發，不要奢望前端大佬們能腦補出頁面之間的交互，我們不及時提供的話，后期修改研發可能會直接拒絕，并且口吐芬芳～（最簡單的找到競品頁面演示給研發看）。

我的方法▼▼▼

前端在看我們設計稿時如果不是結構上的修改，他們不會去關注這些細節的點，而給測試看的目的是，有些公司測試會幫我們進行走查，如果不出設計文檔測試沒辦法進行對比（測試提bug比設計師提bug更具有一些權威性）。

這里看一下我工作中輸出的設計文檔，我會把需求的背景、目標在設計文檔上強調一下，再添加上設計目標，設計目標為了需求目標去賦能，這樣在文檔開始就與研發達成共識，讓研發是帶著共同完成目標的態度去看設計文檔，便于我們后續推動，其次放上頁面之間的說明。

5. 交付開發

最后總結一下，我們要交付給開發什么東西，首先是基本的設計稿，包括切圖、間距、動效文件，其次是設計文檔，包括需求背景、需求目標、設計目標、設計修改點說明。

三、對接中避免摩擦

1. 不要頻繁修改

在交付設計稿后（基本設計圖、設計文檔），我們就要避免頻繁修改，頻繁的修改會導致設計稿來回更新，對開發造成一種困惑，最后在測試的時候，開發同學容易寫亂。

另一方面工作過的設計師都應該經歷過，我們在開發的過程中修改設計稿，大部分的開發都會帶點情緒，甚至不給我們改，這其實是因為大多開發的代碼寫的是比較規范統一的，如果中途進行修改可能會影響開發同學的代碼規范，就像我們在完成一個設計稿的時候，產品經理突然改變需求，我們也是擔心做好的設計稿因為修改而被打亂。

如果實在需要修改，一定要說明原因，而不是突然一個想法覺得這里設計不合適就進行修改（產品需求修改除外），我們要換位思考，具有同理心去工作，并且讓開發同學感受到我們是在幫助他們減少工作量，這樣在后續的一些需求中，我們的對接會很順暢。

2. 重要信息及時通知

上面說的是站在設計師的角度去修改，還有一種情況是研發在開發過程中，作為設計師的我們突然收到產品經理的修改建議，這時候我們需要及時的同步給開發，或者給開發同事達成共識信息。

因為很多時候，產品經理讓我們修改的時候往往不會通知開發，因為對于產品經理而言就是一個小的修改，例如改個位置、改個顏色等等，但不管是對我們還是對于開發其實都是比較重要的，不及時同步就會出現不好的結果，如果在測試階段沒有發現問題，上線后就會造成設計師背鍋的情況。

我曾經在做一個頁面改版的時候，就遇到類似的問題，當時產品找到我說改一個地方的交互，并且我也覺得那個交互方式應該改，當時的我以為產品經理會同時告訴開發修改的地方，但是直到項目上線后開發都沒修改那個地方的交互。

本來這個修改點是個小事情，誰知剛好那一個版本被用戶吐槽那個頁面的交互，結果可想而知領導拉個會議開始復盤，為什么沒有改，索性大家沒有互相甩鍋的情況，產品經理說沒有同步到開發，而我也是幫產品兜了一下說更新設計稿沒有告訴開發，這個事情原本是個很小的事情，只需要我順口同步給開發，就能夠避免的，就因為我沒有及時同步，造成用戶的反饋，影響了產品的體驗。

所以各位設計師工作中如果遇到類似的事情一定要及時同步！

3. 統一需求目標

開始講到過，在需求評審的時候要與開發對齊目標，為什么需要對齊目標，因為一個項目如果目標不對齊，那么每個人都會站在自己的角度去做這個需求，設計師思考的是通過設計的手段，去幫助產品完成目標，如果設計稿上的復雜效果較多的時候，開發則會考慮你為什么這么做，這么做開發成本非常高等等。

這也是說為什么我們開始就講要輸出設計文檔，如果這一切都不存在的話就會導致開發是帶著疑問寫我們的頁面，如果過程中在修改需求什么的，那我們跟開發又要相愛相殺了。

我的設計方式是通常是在產品評審階段就與開發明確講清楚，我大概要做什么樣的效果，什么的交互形式，預計什么時候會交初步方案，中途也可能會有修改的點等等，提前讓開發有個心理預期，避免在開發過程中產生抵抗情緒。

我的經驗▼▼▼

4. 輸出交互動畫

如果在前期沒有時間進行動效設計并沒有關系，研發在開發過程中可以在把動效方面給空出來后續寫，這里講的交互動畫分為兩種，一種是展示的動畫，一種是ui中的動效。

a）展示動畫

目的是為了告知開發頁面運動的軌跡，在1-4中講到我個人用的方法，大家如果是剛對接研發的話，建議還是輸出完整的交互動畫，這里推薦一些工具AE、Principle、Pixso、Figma等。

• AE：大家就比較熟悉了，經典的動效繪制軟件，什么樣的效果都能實現，但是使用成本比較高（不建議）
• Principle：國外的一款交互軟件，制作頁面交互很方面，可以直接導入figma和sketch，由于是國外軟件需要使用英文界面，但是國內也有漢化版，我這里給大家準備好了鏈接（建議使用）
• https://www.macz.com/mac/166.html?id=NzY5NTA5Jl8mMjcuMTg3LjI5LjE0MA%3D%3D
• Pixso：國產最新的設計軟件與figma類似，做交互的方式是使用多個頁面添加熱區進行使用，具體體驗如何還不清楚（可以用用）
• Figma：設計軟件目前的天花板，流暢的體驗，支持頁面動畫設計，但是需要安裝插件才可以（建議使用）

b）動效文件

這個比較重要！我們一定要與研發同事溝通好，產品內使用什么樣格式的動效文件，統一后能提升后續的開發效率，動效格式使用亂套的話，后續我們做更新迭代時做替換會很麻煩，開發也同樣如此，這里推薦幾種動效格式文件，分別是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. 跟進開發進度

作為設計師，我們需要實時了解開發的進度，這樣能夠保證我們在過程中掌握自己的設計節奏，什么時間交給開發動效文件，如果進行修改也可以不影響上線時間（當然不建議這樣做），那么具體需要怎么跟進呢，大概分為以下幾個維度。

a）時間進度跟進

設計師可以時不時的問一嘴，是否能按照正常的計劃時間節點提測（正常需求提交后，開發會給出開發排期，盡量按照時間排期走，否則項目進度會變得很不可控）。

如果開發反饋時間會有延期風險，那設計師第一時間就要了解原因，以及預計延期多久，然后自身評估以下對設計上是否有影響。

b）需求變更跟進

一般開發過程中，或多或少都會出現一些需求調整/變更的點，那么其中就會涉及設計上的改動，改動小的話產品經理有時候會直接告訴我們，并不會告訴開發，這時候如果身為設計師的我們要及時通知開發，并說明原因（避免爭論）。

并且，需求變更后，需要和開發評估新的項目上線時間點，站在我們或者產品角度理解有時候我們認為的修改，對于開發來講是耗費時間較長的，需要我們注意是否會影響上線時間。

c）交互動效實現跟進

在2-4中講到我們要輸出交互動畫，雖然我們輸出的動畫很直觀，以及動效文件也完整，但是避免不了認知上的偏差，有時候開發會按照技術難度以及自身理解去完整交互效果，我們中途要隨時跟進了解，避免開發在錯誤的路上越走越遠。

d）測試跟進

及時了解該需求是否已經提測、哪些還未提測，若到了提測時間的功能未進入測試，可以詢問產品或開發什么原因，這樣對項目或設計師都是負責的。

另外一點是我們設計師需要在提測階段介入UI走查，因為各個公司或者項目測試時間有長有短，所以我們要及時把UI走查工作介入進去，給開發預留出修改時間，有的小公司不重視UI走查流程，這里我們就可以自驅進行走查，主動找測試同學了解提測時間，及時走查，保證頁面還原度。

2. 設計走查

走查是UI工作中最為重要的工作，它決定著產品上線后能否完美的展現給用戶，下面我大致把走查的流程以及范圍給大家梳理下。

a）創建走查文檔

在UI走查階段，我們首先需要建立走查文檔便于開發瀏覽解決，走查文檔主要包含日期、版本、項目名稱、模塊、端口、問題描述、修改狀態、圖片標注，這樣一方面能夠讓問題更加詳細，體現設計師的專業度，一般我是使用在線表格去建立走查文檔，當然這個看每個公司所使用的協作平臺。

b）開通手機權限

一般在走查移動端產品時，安裝測試包需要開通賬號權限，這里可以找公司的開發或者測試同事給開通，避免影響走查效率。

c）走查范圍

分為基礎走查、細節走查、適配走查。

基礎走查包含字體、顏色、圖標、間距、對齊方式等具體可根據產品形態進行延伸，其中間距走查比較費時間，需要我們通過測試機截圖后，按照倍數縮放到源文件內進行測量，測試機分辨率需要保證與設計稿一致，否則測量不準確，如設計圖是375*812，以蘋果為例測試機則需要使用 iPhone X，這里給大家參考鏈接。

https://developer.apple.com/design/human-interface-guidelines/foundations/layout

細節走查包含字體截字、按壓狀態、組件內容、交互狀態。

適配走查包含關鍵信息是否超出屏幕、是否出現擠壓、是否出現重疊、識別度是否清晰。

3. 避免添加復雜交互

在走查階段如果我們發現部分的交互效果不太理想，并未達到預期，我們可以與開發進行溝通是否可以修改，或者添加新的交互效果，因為在這個階段我們重新設計或者定義一個新的交互動效的話，會增加非常大的開發工作量，可能也會與開發產生爭吵，我們在這個時期盡量避免這個問題，如果實在沒有解決辦法的時候再去添加新的交互。

我在工作中，如果遇到這種事情，會分兩點考慮這個事情。

第一評估下當下這個交互效果是否會影響用戶體驗，如果影響用戶體驗我會要求開發必須100%還原，當然我會講述清楚為什么改，避免讓開發產生情緒抵抗。

第二是如果不影響用戶體驗，但是還原度沒有達到預期，我同樣會先找開發進行溝通，例如按照交互稿還原會有什么困難，是時間上的困難還是技術上的困難，時間上如果困難我會溝通好下一期必須還原到位，技術上困難我一般會修改交互形式，盡量保證上線后給用戶展現的是完美的狀態。

4. 數據追蹤

作為設計師在需求上線后并不代表需求就結束了，我們還需要追蹤數據情況是好是壞，為什么我們設計師要去追蹤這個數據呢，追蹤數據是為了讓我們在工作中提升自己的設計價值，隨著現在互聯網發展逐漸飽和，那么企業對于各個崗位的要求也跟互聯網初期不一樣，以前我們只需要畫畫圖交付就可以了，但是現在的企業更看重的是綜合能力。

說簡單點就是做UI的人很多，優秀的UI一樣很多，那么我們就得被迫提升核心競爭力否則就是被淘汰。

而追蹤數據其實就是增加我們得核心競爭力，同時也是能夠體現自己設計能力的一項內容，設計最終是為商業而服務的，但我們不能嘴上說說，而是要拿出實際的行動，這個行動就是數據，我們的設計如何為數據賦能的，如何幫業務達到目標等等，數據如何分析是個很龐大的體系這里只講下我們身為設計師為什么需要追蹤數據。

簡單講下工作中數據解析的案例。

下面是我做的一個直播商業化改版需求，改版背景呢是直播業務由原先的為c端用戶賦能改為，為b端企業賦能，通過與企業合作而產生價值，那么基于這個直播形態肯定是需要變化的，需求目標由原先的【用戶收益】改為【企業收益】，新的目標具體為提升企業品牌曝光點擊、互動、預約人數、提升直播在企業客戶測的感知收益。

案例▼▼▼

基于這個目標，其實不難發現，目標已經從用戶側改為大客戶，更多的是為企業去賦能，頁面的結構肯定需要進行變化的，左邊的圖呢是改版之前的，右邊的是改版之后的，那么我當時的思路呢其實就是基于數據方面去進行優化。

整體：產品策略添加了二級浮窗用來承載更多內容。

直播介紹：首先舊版策略是直播介紹對于用戶而言并不重要，用戶只需要通過看到直播標題就能夠了解大致直播內容，更多是以引導形式存在，所以信息外漏較少，而新的策略是講企業介紹默認展示在二級浮窗內，用戶可選擇關閉，提升企業感知。

投遞簡歷：舊版策略是需要側重用戶投遞率，因此在預約界面就展示入口，而新的策略是需要給企業強化觀看人數、預約人數從而提升客戶價值，基于這一點，我當時是通過數據后臺看了下預約頁面的點擊數據，發現點擊率最最高的是【投遞簡歷】入口，而【預約直播】入口點擊率相對較低，因此把投遞簡歷入口調賬到浮窗tab區域，降低層級，讓預約直播成為視覺焦點，而上線后數據也是符合預期。

企業關注：將企業名稱與關注結合并且放大，提升關注量，強化企業品牌感知和數據感知，關注與預約直播兩者無論數據高低，都是符合企業目標，從而便于業務人員與企業進行合作溝通。

從我這個案例中我們能清楚看到，基本上任何需求都是可以通過數據的維度，進行優化，并且通過量化指標提升設計價值，無論對公司還是個人都有很大收益，并且我們追蹤數據也便于后續我們與開發對接時，可以通過數據維度去促進我們設計上的修改、完善等工作，這也是為什么說我們需要對每個需求都要進行數據追蹤。

五、總結

無論是對接前、對接中、對接后，在哪個階段都需要我們認真對待，熟知這些細節后，才能更好的與開發合作，進行項目推進，優秀的設計師不僅是專業和技術上的成熟，還需要有協作上下游的能力，在很多團隊中設計師跟開發都會面臨不一樣的挑戰最終可能會因為某些問題發生沖突，我們需要減少這樣的沖突。

作者：愛吃貓的魚；公眾號：防脫發藥水

本文由 @愛吃貓的魚 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

輯導語：用戶在使用一款產品時，都希望能有良好的使用體驗。出色的動效，可以使頁面之間聯系更加緊密，整體體驗更加流暢，減少用戶的負面情緒；同時，也可以增加產品的趣味性與品牌特色，讓用戶產生興趣并提高品牌認知度。接下來，本文作者就帶我們去了解動效設計。

現如，今動效設計在產品中的使用已經十分普遍。

這也導致動效設計由早期的「魅力型因素」逐漸成為「必要型因素」，越來越多的公司和團隊已經意識到動效在產品用戶體驗中的重要性，動效也逐漸成為UI設計師的基本能力之一。

一、動效是什么

動效設計，顧名思義即動態效果的設計，用戶界面上所有運動的效果，也可以視其為界面設計與動態設計的結合。

而在Material design 設計規范中，將動效設計這一章命名為「Animation」，意思是動畫，活潑的意思。好的動效設計可以幫助引導、取悅用戶，減少等待焦慮，是拉近用戶與產品之間距離的有效手段。

二、動效分類

動效的分類并沒有明確的界限，根據其作用大致可以分為3類：

1. 功能型動效

此類動效一般用于產品設計，通過動態圖形向用戶傳遞信息，其中加載/刷新和進度條應該是我們平時接觸最多也是最早的動效了，此類動效最開始只是為了告知用戶產品的頁面狀態。

隨著社會上產品數量的快速增長以及競爭日益激烈，產品的有趣和差異化顯得愈發重要，于是便看到越來越多的產品將自己的品牌因素融入動效當中，設計也越來越生動有趣。

除了加載、刷新和進度外，功能型動效還被廣泛的運用在產品的其他各種狀態當中，如信息報錯、二維碼掃描等。雖然具體表現不同，但都是通過動態形式幫助用戶理解和使用產品。

2. 交互型動效

顧名思義，該類動效的核心是“交互”，其主要的作用是幫助用戶理解界面的層級邏輯關系，讓產品的使用更加符合現實生活中的認知習慣，從而降低使用成本，提升產品體驗。

要注意的是此類動效不能脫離用戶的認知模型，只是單純的炫酷對于整個產品來說是有害的。

其實交互型動效是用戶在產品使用中接觸最多的一種動效，因為產品的使用是通過不同產品元素串聯而完成的，而負責元素串聯的就是交互型動效。

一般可分為「單頁面交互動效」和「多頁面交互動效」。

「單頁面交互動效」：就是在當前頁面發生的交互動畫，比如tab切換、左滑刪除、二級菜單展開、返回頂部等等。

「多頁面交互動效」：就是不同頁面之間的交互動畫，其實就是頁面的跳轉，根據不同的場景會使用到不同的跳轉樣式，好的跳轉動畫能夠幫助用戶理解前后頁面的邏輯關系。

3. 展示型動效

此類動效的最大作用就是盡可能的為用戶制造視覺上的愉悅，營造活動氛圍，讓用戶覺得有趣生動，使用的場景也十分廣泛，常見的如「品牌展示」、「運營活動」、「H5營銷」等。

1）品牌展示

將有趣的動態圖形與品牌相結合，讓原本生硬的產品形象變得有趣生動，拉近用戶與產品之間的距離。

2）運營活動

動效設計同樣也可以使用在運營設計中，作為業務數據轉化的重要入口，動效可以極大的吸引用戶的注意力，從而提升業務數據。

H5營銷

從2014年開始，H5因其豐富的表現形式便開始逐漸走紅，每年都會有很多火遍全網的H5活動，如「網易云音樂聽歌報告」、「支付寶集五福」、「支付寶年度賬單」、「穿越故宮來看你」等等。

網易云音樂聽歌報告

支付寶五福

支付寶年度賬單

穿越故宮來看你

三、如何設計動效

1. 結合產品去設計

不同的產品有屬于自己的產品調性，例如：

金融產品強調的是可靠理性，而手游類產品的重點則是炫酷有趣，二者的動效設計自然也需要貼合各自的屬性，思路設計要符合提升的產品體驗，要經過細致思考不能盲目跟風。

2. 了解動畫的運動節奏

因為自然界中運動都不是線性的勻速運動，而是按照物理規律，呈現出的曲線的變速運動，這也是物體運動的基本常識和規律。

人們對于一個運動形式產生的情感反饋，大部分也來自于生活中看到的類似的運動形式。所以我們要符合物理規律，這樣才能準確的專遞我們動效設計的情感。當然可以適當根據需要夸張、精簡。

3. 多看多思考

我們還需要多看一些優秀的動效設計作為積累，同時也需要對優秀的動效設計進行深入思考，思考別人為什么這么設計，以及如何完成動畫設計的。

要與自己對類似事物的想法進行對比，找差距，補不足，這是經驗技巧積累的過程。同時要學會怎么去拆解別人復雜的動效設計，從中總結經驗，最后通過合理的編排設計出自己的動效設計作品。

4. 關注流行

就是要保持對于設計行業，或者說是APP動效設計領域的關注。了解當下新的設計手法，設計趨勢以及設計工具，不要做一個落伍者。

四、動效文件格式類型

常見的動效文件格式有GIF、APNG/WEBP、序列幀/精靈圖、Lottle、SVGA。

1. GIF

GIF 圖格式應該是設計師接觸過的最多的動態格式了， 因其體積小而成像相對清晰，其在各個平臺的兼容性非常好，使得它的傳播性非常強。

當然gif格式也存在很明顯的缺陷：

1. 對電腦的內存和性能占用非常大（根據 GIF 的時間尺寸的等情況會有不同的程度的影響），作為設計師常有的一個經驗是在網頁上多開幾個 GIF 之后電腦風扇就開始飚起來了。
2. 它是一個有損的文件格式，不論是色彩還是畫面質感都會有一定程度的壓縮。
3. 對透明通道的支持非常有限，輸出結果會非常差，時常會有鋸齒或白邊的情況。以上是我們在輸出 GIF 格式的之前需要提前思考是否可以接受以上的問題。

2. APNG/WEBP

這些格式是基于現有的 JPEG、PNG、GIF 格式的所衍生出來的。

APNG 格式在目前主流的所有瀏覽器上都可以完美支持，在移動的設備上通過一些代碼框架也可以完美支持，它相比 GIF 支持的色彩范圍更廣，更清晰，并且占用更低的內存，支持透明通道，有非常多的優勢。

WEBP格式目前也基本兼容所有的主流瀏覽器，相同的效果，webp 格式要比 png 格式小出來大概一半的大小，同時它也兼容所有的安卓設備，像一些 ios 設備需要通過一定的方式才可以支持。

不過，相比來說各方面的表現都是非常優秀的。

3. 序列幀/精靈圖

1）序列幀

序列幀就是將動動效的所有畫面拆分開來，形成一系列靜態的png圖片，然后通過前端代碼來控制每張png圖片出現的間隔時間，而且實現連貫的動畫效果。

序列幀是一個無損且低內存的格式，但是它只能在客戶端環境中使用，不建議在 Web 環境中使用。

原因是序列幀一般都是隨著 App 程序包一起下載下來的，但是 Web 中每次進入一個新的網頁都需要重新下載。

舉個例子如果一個 60 幀的動畫就得重復向服務器請求 60 次，在這種高頻次的請求下很容易因為一個小的問題導致整個動畫無法正常播放，為了避免這種錯誤我們一般會這個 60 張圖合并為一個，并且通過代碼在指定時間內顯示某一個區塊，所以這里我們引出另一種格式——精靈圖/雪碧圖。

2）精靈圖（又叫雪碧圖）

當我們把所有序列合并在一張圖片上往往還是不夠的，我們還需要提供給開發具體哪個時間顯示哪一部分的具體參數。

我們可以直接通過 AE 插件 CSS Sprite Exporter(By Bigxixi) 直接快速的輸出開發所需的代碼和精靈圖：

Lottie：

Lottie 可以說是近幾年在動畫輸出方面不得不提的一個格式，它由 Airbnb 推出，并且迅速在國內外各種大小廠快速推廣開來，目前已經是一個非常普遍常用的格式。它在 AE 中的插件叫 Bodymovin，它的原理是把各種矢量元素以及位圖圖層以及他們的效果關鍵節點打包行成一個 json 格式的文行。

開發人員拿到 Bodymovin 輸出的 json 格式是無法直接使用的，它需要在代碼中加入 Airbnb 提供的 Lottie 第三方庫來讀取播放，相當于 lottie 文件在我們各個端口設備上的播放器的作用。

ps：

1. 由于lottie不支持ae表達式，可以用插件（Easy Bake）將表達式轉為關鍵幀，這樣問題就解決了；
2. ae軟件因為漢化的原因，會導致Bodymovin插件對其中的某些屬性不支持，比如ae中如果存在顏色漸變，導出來的json文件所有的漸變會變為黑白漸變。

解決的辦法有兩個：一個是使用英文版ae軟件；第二個是將屬性「漸變填充1」重命名改為「Gradient Fill1」（后面的數字需與漢化版的保持一致）。

SVGA：

針對 Lottie 對緩動曲線解析差帶來的性能問題和穩定性問題，我們會有第二種備選方案是 SVGA，不管是導出之后的內存占用，還是在各個端的表現穩定性都會好很多。

但是它的內存占用會比 Lottie 稍高，并且支持的特性也會比 Lottie 少一些。

SVGA 與 Lottie 最本質的區別在于代碼對動畫過程記錄的方式， Lottie基本上是按照我們在 ae 當中的關鍵幀及緩動的結合形式去記錄動畫；而 SVGA 則是通過記錄我們每一個圖層每一個時間上的動畫狀態，從而省去對緩動值的計算。

跟序列幀的邏輯非常相似，但是因為它的素材可以復用，所以會比序列幀占用更低的內存。

基于實現方式，它會比 Lottie 穩定很多，相應的，它所支持的特性也要比 Lottie 少很多。

四、動效制作軟件

動效制作的軟件其實非常多，這里只介紹一些自己接觸過的主流動效軟件：

1. AE

AE是時間軸動效軟件，不支持交互操作，但幾乎可以制作任何你想要的動畫效果，但操作相對復雜時間成本較高。

2. Principle

Principle是可交互的動效軟件，主要用于交互動效Dome制作，可以制作出較為復雜效果的交互動效，操作難度相對較低。

3. Origami

Origami是一款以代碼思維進行動效制作的軟件，學習門檻較高，但可以實現與開發的無縫對接。

4. C4D

C4D主要針對三維動畫效果的制作，學習門檻較高。

作者：WOWdesign，研究設計價值最大化，涉及用戶體驗、品牌體驗、空間體驗。

本文由 @agoodesign 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議

<script src="/dist/js/titanic.min.js"></script>
<script src="/bodymovin/4.5.9/bodymovin.min.js"></script>

<script>
 var titanic=new Titanic();
</script>

<div class='titanic titanic-chat'></div>

<head>
 <!--Inserting the scripts once for the whole page-->
 <script src="/dist/js/titanic.min.js"></script>
 <script src="/libs/bodymovin/4.5.9/bodymovin.min.js"></script>
</head>
<body>
 <!--Inserting an icon-->
 <div class='titanic titanic-checkbox'></div>
 <!--Initializing-->
 <script>
 var titanic=new Titanic({
 hover: true, // auto animated on hover (default true)
 click: true // auto animated on click/tap (default false)
 });
 </script>
 <!--Clicking turns this icon on-->
 <button onclick="titanic.on(getElementById('checkbox').value)">On</button>
</body>