編輯導語：如今產品中的動效設計非常重要，可以為用戶提供了良好的動態沉浸式體驗；動效的重要性在于將交互、視覺過渡處理的更加細膩，而且能夠承載更多的信息；本文作者分享了關于動效設計怎么完美的對接開發，我們一起來看一下。

本文分享和研發對接動效的方式，讓研發拿到我們的文檔能夠快速上手。

先來個大綱：

• 需求來源
• 低效率的溝通方式
• 動效文檔如何制作

這篇文章起源于工作中一次與開發對接動效時遇到的諸多問題，一定也有許多人跟我一樣遇到這些問題，所以想把自己一些經驗分享給大家。

正所謂，工作中少走一點彎路就相當于進步了。

事件背景：

之前做了一個旅游網站的項目， 設計完后，前端已經開始實現了，老板說想要網站“動”起來，加一些動效讓旅游網站更好看更吸引人。

嗯，boss的意見？

好的，收到，沒問題！

當然，老板的出發點是沒問題的，這個旅游網站主要也是讓用戶瀏覽觀賞用，那么動效設計在產品策略上也算是錦上添花甚至是不可或缺的。

說干就干，早上接到這個需求后，前端和我商量說打算怎么做，我想了想，之前我并沒有這么系統地和前端交接過動效，正好趁此機會梳理出一份動效文檔，日后也可以復用。

當前在之前也有過類似需要動效設計的場景，但動效量沒有這么大，加上手上需求比較多，一直沒有系統梳理過動效文檔，所以踩的坑也是一籮筐的。

所以下面的內容不僅僅會說動效文檔的制作，也會把我在工作中遇到的坑給大家一一分享，幫助大家排雷。

一、需求來源

一般動效這樣的需求可能來源于：

• 老板/上級
• 甲方
• 自己

「為啥會有自己呢？當你覺得界面平平無奇想搞點事情的時候，需求就產生了，當你做到一半覺得過于復雜懶的搞的時候，需求就鴿了，自己的需求自己必須做主！」

當收到老板和上級的動效需求時，第一反應當然是OK??！

但咱也不應該全盤接收，顯得自己沒頭沒腦不是么，咱們也得衡量產品的業務邏輯和方向，評估目前手上工作量的優先級后才能做出決定是需要馬上給出方案還是可以押后再議甚至需要考慮到是否有必要增加動效。

畢竟，一個產品必須得先滿足可用性和易用性。

第二個動效需求的來源是甲方。

甲方很多時候總是想要多一點，再多一點……

這時候跟上面一樣，同樣需要評估必要性和實現難度的問題。

其實甲方的終極目標是想解決問題，而不是一股腦堆砌功能，有時候雖說甲方會堅持己見，但是不代表我們不能發表自己的看法或提出更優質的方案，至于選擇哪個方案，是否選擇我們的方案，那是甲方的決定。

但是我們保持沉默和提出選擇方案是不一樣的，后者會顯得我們更專業，不是么。

第三個動效需求是自我。

作為設計師，我們的目標不就是解決問題嗎？

當解決一個問題后，會讓人覺得特別有滿足感，因為這是一種證明自己價值的方式。

那么在一些時候，為了產品使用更加順暢，轉場更加自然舒適，我們會在某些地方添加一些動效，這時候需要說服的可能是一整個產品團隊，包括了產品經理、開發還有你的老板，畢竟，這都是需要工作量的……

二、低效率的溝通方式

前面提到，在開始制作一份動效文檔之前我和開發也溝通過其它瑣碎的動效實現問題，遇到了很多坑。

下面就這些“坑”展開來講，旨在幫助大家在工作中與開發更好地溝通。

沒有動效文檔的時候設計師是如何跟開發描述自己的動效設計的？

補充：下面說的動效指的是讓開發寫的動效，而不是我們提供的GIF或其它動效文件

第一種：設計師口述后讓開發實現

嗯……我想這是很多設計師在比較忙或者沒有制作動效文檔習慣的時候的方法，除非開發領悟能力驚人，否則實現出來的效果是不太可能和你描述得一模一樣的，有時候甚至是南轅北轍。

這時候就會產生一個問題：

你覺得實現得和你的預期不符，然后讓開發修改。

開發又覺得自己做得明明和你描述得差不多，為什么要改？

結果就是，要么開發不改，你們吵一架，問題也沒解決，要么是你指著開發改，開發心里也不爽，你也不爽，后續的工作可能不太好推進。

第二種：設計師將做好的GIF圖發給開發，讓開發照著做

這種方法相對上面的方法稍微好點，可是還是會有問題，開發照著動效做一般只能實現出大概的樣子。

但是心細如設計師，連細微的變化也能發現……很多時候不就是這些細節決定了一個產品的優劣嗎？

這時候又會出現上面的場景，你又來到了開發面前……最后不歡而散。

上面的場景我想很多設計師應該或多或少都遇到過，之所以有這樣的問題一方面是溝通不到位。

另一方面也是最重要的是，你沒有給開發一個具體的參數值，上面不管是口述還是GIF圖都只是感官上的感受。

你沒有告訴他在20毫秒的時候大小是80%，在100毫秒的時候透明度是50%。

開發沒有這些參數，自然只能自己憑感覺來寫參數，出來的效果當然會和你的預期不一致。

所以……這還真不怪開發同學。

那么如何把這些參數告訴開發？

三、如何制作動效文檔

制作動效文檔的根本目的有二：

• 一是幫助開發實現動效效果。
• 二是在開發實現出來的效果和你預期不一致的時候，可以拿著這份文檔去和開發溝通，白紙黑字，這可比憑感覺的動效來得真實可靠。

1. 制作動效需要什么工具？

Excel

只需要一個表格工具即可，我推薦在線表格工具；可以多人同時查看，在線更新。

也有一些設計師用sketch做動效文檔，我個人覺得sketch做表格的東西效率不高，而且涉及到插入圖片，sketch遠沒有Excel來得方便；動效文檔歸根結底是給開發看的，如何讓他們更快地理解內容比美觀性更重要；不過還是看個人習慣，只要你順手。

工具只是工具，重要的是你想要表達的內容。

當然，制作動效的軟件也是不可或缺的，只是這樣的軟件太多了，看個人的習慣，我一般用sketch做高保真設計，用principle做動效demo。

2. 動效文檔需要哪些參數

跟我念：

和開發溝通！

和開發溝通！

和開發溝通！

和開發溝通！

記住這句話，一定要勤溝通，既然實現效果的是開發同學，那么不問開發，問誰呢？

先問清楚開發需要什么樣的參數，再制作不遲，不然做出來的動效文檔開發拿著也是白瞎不是么……

下面就拿我一個工作中的動效文檔舉例，幫助大家更好地理解動效文檔。

補充一句：

如果想讓動效文檔更好地幫助開發同學實現效果，那么不如稍微費點心思跟開發請教一下他們是如何實現效果的，知其然后，你會對動效文檔有更深的理解的。

記住，要和開發哥哥保持良好的關系，你們是隊友，不是敵人。請教是一種令人尊敬的行為，不會降低你的專業度。

「這里我又要插一句，我的確遇到過非常愛惜自己羽毛的人，容不得別人對他的東西做半點質疑，甚至友好的建議也不行，他會用嚴肅且帶有一絲憤怒的語氣解釋原因后加一個結束語“就這樣好吧”。漸漸其他同事不愿意向他提出優化意見和建議了……

我想說的是，有人愿意教你東西或者給你提意見和建議真的是一件非常幸運的事情，因為這些事情都是需要花精力甚至得罪人的；所以我們真的應該感謝給我們提建議和意見的人，感謝教我們知識的人，哪怕是一個非常簡單的知識。

希望你我都能成為虛心聽取別人意見的人，共勉?！?/p>

好了回到正文，先上個動效文檔圖，有個直觀的印象：

還可以插入圖片，非常方便。

下面對這份動效文檔的內容進行拆解：

備注：

動效文檔的備注，主要是一些提醒開發同學注意的地方和輔助信息。

表頭：

1）頁面

（上圖由于只有首頁有動效，所以沒有這個版塊）

是哪個頁面需要動效設計，比如首頁、詳情頁等等。

2）模塊

是哪個模塊需要動效設計，比如banner、商品列表等等。

3）圖示

把具體的模塊截圖放到表格中，幫助開發快速定位，文字哪有圖片直觀呢？

4）觸發條件

意思是當前動效發生需要的條件，例如下面的動效，出現刪除的觸發條件是拖拽。

5）對象

一個模塊的動效可能有多個對象發生了改變，那么就需要把當前模塊所有發生改變的對象都列出來。

比如下面的banner模塊有三個對象需要添加動效：

6）接下來是具體的參數

這些參數是我跟開發溝通后他們需要的參數值，切記一定要先問問開發。

• 透明度：寫變化，開發的透明度是0-1，0代表0%，1代表100%
• X軸位移：對象在X軸上的位移
• Y軸位移：對象在Y軸的位移
• 總時長：當前對象完成所有變化需要的時間

注意看下面的時間軸，是不是跟做動效設計時的時間軸很像，其實原理差不多；這里是告訴開發當前對象的改變從哪里開始，到哪里結束，單位用的是ms，因為開發那邊使用的是這樣的單位。

以上，就是本次分享的內容。

今日經驗：謙虛使人進步，感謝那個給你提意見的人，下期再見。

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

題圖來自Unsplash，基于CC0協議