針對不同設計階段，如何選擇合適的動效工具？

動效是互聯網產品設計中繞不開的一個話題，無論PC端還是移動端，產品要想提供細膩順滑的體驗，很大程度上需要依靠動效將不同界面、同一界面中的不同狀態銜接起來，讓用戶直觀地感知操作結果的可控性。

雖然在細分了交互和視覺崗位的情況下，通常會讓視覺設計師承擔動效製作的工作。但個人一直認為，動效一定是交互設計需要考慮的範疇，即使有人承擔了這部分的具體執行，也要保證自己在動效方面具有足夠的專業性。

近些年，在「萬能的」AE之外，InVision、Flinto、Principle、Marvel、Protopie、Kite等大量專門為UX行業打造的輕量級原型工具的出現，也讓動效工具和原型設計工具之間的界線變得模糊。

一些優秀的原型設計工具，可以很好地同時覆蓋可交互原型設計和動效設計這兩個重要的應用場景。其中，我個人習慣使用的兩款工具主要是Principle和Flinto，配合萬能的AE，個人認為可以覆蓋絕大多數的應用場景。

在交互設計（分為產品流程設計和具體界面設計）、視覺交付等項目不同階段，面對不同場景，能針對性地選用合適的工具，是提高方案表達效果和個人設計效率的重要一環。本文將根據項目中的不同設計階段，介紹這3款工具的特點、分別適合哪個設計階段，以及實際應用過程中的一些個人經驗。

這篇文章不是教程也不是測評，因此不會涉及技法教學，也不會探討是否有更好的工具選擇。

雖然新工具層出不窮，但個人覺得同質化越發嚴重，核心features重疊性非常大，孰優孰劣只是熟練度和個人偏好問題。並且，每個工具都有不低的學習成本，精通自己喜歡的幾個工具就好。

畢竟，工具只是用來解決問題的，掌握工具的數量和設計能力完全是兩回事。

階段1：產品級交互設計階段

輸出物：可交互的流程原型

推薦工具：Flinto

嚴格來說，流程原型不屬於狹義的動效，只是產品界面和功能點的簡單串聯，但工具層面還是有共性的，所以也放在這篇文章里一起講講。

這裡的「產品級」並不一定是指整個應用。

根據業務規模、迭代範圍的細分粒度不同，一個鏈路模塊，甚至一個營銷活動玩法，都可能作為一個相對獨立的產品線，進行版本迭代或者從零到一的設計。

對流程具有一定複雜度的產品而言，在提案、評審這些需要快速碰撞思路的階段，傳統用流程箭頭標註的交互稿其實並不實用。

即使經過了很好的流程分解，對設計師而言改動返工量依然巨大，對老闆而言又沒時間仔細閱讀你精心撰寫的交互說明。

這時，迅速通過輕量級的動效工具產出可交互原型，可以幫助設計師在提案、評審過程中，讓團隊成員和老闆更好地對方案的實際效果有一個更直觀的體驗。

在這個階段，對製作旨在串聯流程的可交互原型而言，個人心目中最適合的工具當屬Flinto。

先簡單講一下Flinto和Principle的共性和差異。

兩款工具同為UX行業專屬的原型/動效設計軟體，比AE更輕量級、更聚焦在行業高頻功能上，同時都能快速輸出MOV、GIF，以及在移動端上進行實際的交互體驗。

兩款工具有很多共通之處，底層思路都是定義元素的屬性變化。但實現邏輯上卻有比較大的不同：

• Flinto：每個Artboard是一個界面，在元素上定義可以疊加的事件，在事件內定義不同State的切換。
• Principle：每個Artboard只是一個界面的一個具體State，直接在畫板上定義不同State的切換中元素的變化。

實際使用時，拋開更本質的差異不談，最直觀的差別就是：同樣1張界面的設計稿，在Flinto里對應1個Artboard，而在Principle里會對應N個Artboard（且會直接把切換邏輯用箭頭的形式標在不同Artboard頭頂）。

這點上的不同，決定了Flinto優勢在於產品級複雜流程的表達，而Principle更擅長單個界面（或很短的流程）的交互細節表達，處理多界面流程時會讓工作區域變得亂七八糟，甚至隔幾個小時再看的時候連自己都看不懂了。

對流程串聯而言，Flinto是我用過的工具中最快的（有更快的歡迎推薦給我）。

以基於地鐵查詢工具的心情分享平台「一站」的主流程串聯為例（鑒於工作中的案例不便討論，專門為設計交流做的一個概念方案，背景見鏈接）：

https://www.zhihu.com/video/925869375356043264

流程原型對應的Flinto源文件如下：

在Sketch中設計稿準備妥當的情況下，下面這個原型只需要20多分鐘就能做好——這還是在實現了層級分離和滾動效果的情況下。如果只是快速輸出靜態頁面的串聯，時間可以再縮減一半以上。

在製作流程Demo時，只需要表達基本的頁面結構與跳轉關係即可。轉場無需表達得很準確，以不引起誤解為原則即可，時間有限的情況下，最簡單的處理方式就是統一用漸隱漸現。

各種與頁面滾動位置有關的動效也暫時不用表達。同樣，也完全沒有必要讓每個元素都可點擊（當然核心交互還是要做的），更沒必要在這個階段考慮非常完整的用例。

明明在交互稿上可以用交互說明一兩句話就可以說清楚的事情，完全沒必要費盡周折做在流程原型上，萬一做好後邏輯又改了呢？

提到這裡，忽然想起前兩年交流Axure製作高保真原型時，有的朋友執著於在原型中用中繼器把各種變數邏輯表達得非常準確。個人覺得，除非改版就是針對這些細節所做的，否則必要性不是很大。

交互稿和可交互原型是一對相輔相成的存在，很難用一方完全替代另一方。就像買家電的時候，原型相當於在商場觀看宣傳短片，直觀感受流程邏輯和大體布局；交互稿和交互說明相當於說明書，細化各種用例狀態。

階段2：界面級交互設計階段

輸出物：動效錄屏/GIF

推薦工具：Principle

在產品流程和信息結構確定後，具體界面的交互設計階段，就輪到對各個動效逐一進行細化。

應用中常見的動效可以大致分為交互動效和播放動效兩個大類別：

- 交互動效：與用戶交互行為相關的界面間的轉場、界面內的組件反饋與層次暗示等動效都屬於交互動效。

- 播放動效：純自行播放、與操作元素無關的動效，如啟動、入場、Loading、空態界面，多數是為了吸引用戶注意力、情感化設計和創意需要。

關於動效的分類，這裡不再展開，展開深究的話完全是另一個很大的話題了。

純播放類的動效可以不在這個階段細化，在視覺設計階段再直接產出並交付。而交互動效的設計則是這個階段必不可少的工作。

對不涉及位置聯動的交互動效而言，在Flinto和Principle中的製作成本相差無幾。例如下面這個純粹由點擊觸發的事件：

但對於涉及位置聯動的動效，Principle就比Flinto的表現優秀很多了。Principle中，時間軸和位置聯動的設置比Flinto自由度更高，可以快速進行精細的設計和調整。例如下面這個站點列表界面的上滑動效：

上滑中，隨著Y軸位置的變化，存在一系列的子動作：A.頂欄信息縮略；B.二級Tab吸頂；C.回頂按鈕呼起；D.右側快捷檢索器的高亮切換。

同時，回頂按鈕、快捷檢索器又有相應的點擊動作：E.點擊回頂按鈕，返回頁面頂部；F.點擊檢索器字母，頁面錨定至相應位置。

因此一共合計6個動作需要在動效中表達，並且同時包含了點擊事件和滾動聯動，這時候用Principle做起來就非常方便。不過這個例子並不是特別複雜，Flinto中大概同樣也能找到辦法實現，只是做起來會比Principle麻煩不少。

動效中，緩動曲線與時間的精調是一個比較考驗經驗的活——運動的元素是材質是剛性還是彈性、怎樣的緩入緩出更自然、是否需要慣性和「助跑」、多個元素之間是否需要時間差……等等，都可以參考迪士尼動畫12原則仔細尋找最優解。

但在交互設計階段，其實沒有必要太過細緻地考慮。緩動曲線暫時採用EaseOut（先快後慢）通常沒有太大問題，可以在視覺設計階段再精細調整；時間設置上符合大原則即可，單個屬性的變化一般在0.5s內，單個交互行為觸發反饋動效的總時長盡量控制在0.8s內。

另外，在製作動效時有時我們經常會顧慮「會不會動太快了」，這是因為我們在孤立地盯著單個動效看，對時間的感知並不能代表用戶實際操作時的真實情況。

在真實用戶的使用過程中，觸發某個交互行為時，動效只是其體驗路徑中一個極其短暫的中間態，動效時長稍微偏長一點都會導致體驗有拖泥帶水的感覺。

這裡再思考一個問題，流程原型中適不適合同時呈現完整的交互動效？

我的個人想法是，流程很短或者涉及到的交互動效很簡單時，可以考慮將交互動效直接體現在流程Demo上，讓流程Demo的呈現效果更接近最終的設計意圖。

其中，交互動效複雜而流程簡單（比如只涉及兩三個界面的跳轉）時可以統一在Principle內完成；反之，流程複雜而交互動效簡單時可以統一在Flinto內完成。

但從我的個人習慣來說，依然並不建議這麼在流程Demo中過分追求準確地體現每一處交互動效，因為一旦修改，改動量實在是太大了。

不同問題分別獨立解決，這是我一貫的原則，大可不必純粹為了讓流程Demo效果更好一點就多花成倍的時間成本。

所以，實際項目中，我通常都是用原型串起產品流程，然後將需要描述的交互動效拆分成一個個單獨的交互動效進行錄屏（或輸出GIF），放在一份Keynote里逐一展示並說明，作為交互文檔的附件在評審中展示或者交付開發，便於開發初步理解設計意圖。

下圖就是一份動效說明文檔大致的格式示例，主要包括動效錄屏和交互說明兩部分：

階段3：視覺設計階段

輸出物：動效標註或其他形式的交付文件

推薦工具：Principle/AE

大多數的常規動效其實在Principle中都可以實現，因此在視覺設計階段，一般繼續在交互設計階段製作好的動效基礎上進行精細化的微調就可以了。

如果一個發現一個交互動效Principle做不到，只能用AE實現，那首先要做的不是打開AE開始干，而是重新審視一下自己的構思，是不是太複雜了？用戶是不是真的需要這樣的動效？

當然，涉及路徑的動畫是Principle的軟肋，確實需要AE出馬，這種情況另當別論。

而播放類動效通常肩負著創意和情感化的需要，多數情況下確實需要用AE來製作。製作完成後，可以產出PNG序列，或者通過Lottie產出json文件直接交付開發。

當然，這個並非本文的討論重點，下面主要還是介紹交互動效的標註和交付。

世上最恨動效的人恐怕就是開發老哥了。

設計師「跪」開發時，最常聽到的三句話大概就是：「能不能砍」、「能不能出個降級方案」、「那優先順序最低吧」。

一方面，別說直接承擔工作量的開發了，有的產品有時都視動效為「無法直接創造業務價值」的東西，認為把動效寫這麼好，還不如這個版本多排一個新功能進來，或者至少認為應該把動效的優先順序放在所有功能性研發之後。

另一方面，動效的標註確實不那麼容易。對配合默契的開發來說，把Principle源文件發給他，他自己就會查找到所有需要的信息。但在這種理想情況之外，就需要手動寫標註了。

有的設計師習慣只提供GIF或者錄屏給開發，讓開發自行揣摩各種細節，先實現出一個看起來差不多的，然後再坐在開發身邊blabla地讓開發「這調快點」、「那調慢點」，導致開發老哥對調動效產生了先入為主的抵觸情緒。

所以，給開發提供準確的動效標註，對合作而言很重要，即使交互動效的標註不像界面標註一樣有直觀的表達方式。

任何標註都沒有一成不變的形式，目的都是為了把核心信息表達清楚，交互動效的核心要素通常很簡單——屬性變化、時間軸和貝賽爾曲線，涉及位置聯動的要特殊註明。

標註形式上其實沒有什麼條條框框，只要把上面提到的核心要素表達清晰，並附幾個典型狀態（通常首末態就可以，有必要的情況下也可以放中間態）的設計稿便於開發確認就可以了。

下面用一個小例子介紹一下個人習慣的標註方式。

我們再看一次這個從專題Tab點擊進入專題詳情頁的動效：

先看一下它在Principle中的實現方式：

其時間軸如下圖所示（如上文所述，合作默契的開發完全可以直接打開源文件，了解他希望知道的任何信息，這是最理想的狀況）：

這裡為了舉例清晰，不對所有屬性變化逐一闡述，只單獨把專題的頭圖（底圖，而不是外面的圓角卡片）拎出來。在標註中，只要逐一列出運動對象（最好加上前綴，保證元素在項目中命名的唯一性，與開發老哥的命名一一對應對後續維護大有好處）、變化的屬性（這裡只涉及X/Y坐標與寬高變化）、貝塞爾曲線，並在時間軸上標出始末錨點和相應的值即可。

小結

• Flinto：能極速串起複雜流程的神器，但精細度較高的交互動效製作難度較大（雖然也能找到一些很hack的黑招），可以輸出可交互Demo。
• Principle：可方便地實現複雜、精細的時間軸、聯動設置，但不適合製作整個產品的流程，同樣可以輸出可交互Demo。
• AE：「高大全」的萬能工具，在路徑型動效、包含複雜創意的播放型動效上具有不可替代性，與Lottie的協同讓設計交付和開發實現都變得輕鬆愉快。但並非行業工具，處理簡單動效上「殺雞用牛刀」效率不高，無法同時作為可交互Demo使用。

講了這麼多，最後強調一點：動效不是炫技。

許多花哨的動效初看驚艷，落地到實際應用中只會讓用戶覺得拖沓、耽誤時間。

尤其對效率型產品、高頻產品、高頻操作而言，設計儘可能簡單輕快的動效，可以讓設計輕鬆、開發輕鬆，用戶也輕鬆：）