如何在UI設計中正確地使用UI動效呢？又該怎樣通過動效來傳遞意圖資訊呢？這篇文章將給你答案。
在而今UI設計師滿地都是的情況下，
那麼怎樣在UI設計中正確地使用UI動效呢？
在過去幾年的時間裡， 高保真原型工具的爆炸式發展， 給了設計師們一個創造詳細交互動效的機會， 設計師們花了很多時間去學習這些工具， 然而很多設計師在原型工具的技術細節上迷失了方向。
設計師們必須後退一步， 問一下動效的目的是什麼？通過動效來傳遞意圖資訊， 動效用來作為更好的向使用者傳遞資訊的工具， 設計者應該避免使用那些妨礙用戶操作體驗的浮誇動效。
設計師可以利用動效來解決設計問題，
認知成本是完成一項任務所需的腦力勞動。
維琪百科說：“沉重的認知負荷會對任務完成產生負面影響。 ”
當用戶在網站上時， 他們會收到大量的資訊。 因此， 他們有選擇性的注意力。 “隧道視野”意思是他們直接專注於他們正在進行的螢幕區域， 因此， 使用者不會看到螢幕上的所有內容。
作為設計人員， 創建易於使用的介面非常重要， 這釋放了用戶完成任務的精神努力。
設計師如何用動畫來達到這個目的？
動效， 當使用好時， 通過有效的用戶溝通回饋能減少用戶的困惑。
二、吸引用戶的注意力NNgroup說：“使用動效的一個有效方法是吸引用戶的注意力， 吸引用戶注意力的好處是——引導使用者關注螢幕上的介面和元素之間的層次和關係。
動效不需要直接在使用者的視野中進行。 NNgroup的文章解釋說：
由於我們的生物學認識到週邊的潛在危險， 週邊視圖中的移動可以更快地吸引用戶的注意力。 然而， 用戶已經學會不去注意那些傳統意義上的側邊欄和標題列的橫幅或彈出框， 因此設計師必須確保UI和動畫不遵循這些模式。 設計師可以通過最大限度地減少單次發生的運動量， 以及位於使用者認為相關資訊所在位置的動畫元素， 來避免視覺盲點。
三、視覺化層次結構設置頁面元素載入到螢幕上的順序可以傳遞頁面的視覺層次結構， 使用微妙的動畫將向使用者顯示頁面配置以及關注哪些內容， 從而減少認知負擔。
另外， 通過對不同元素使用相同的動畫， 使用者很容易理解元素被分組並且可以執行類似的動作， 因為人類的頭腦總是在尋找創造性的模式。
四、做出更好的決定微交互（單個物件的轉換）和宏觀交互（物件之間的轉換）中的動效可以通過系統為使用者提供上下文之間的聯繫， 動效還可以教會用戶新的交互手勢。 動效完成後， 使用者可以快速瞭解資訊如何組合在一起， 從而做出更好的決策。
動效還有可以發現性， 狀態之間的轉換可以傳達單個物件的功能。 例如：功能表圖示可以轉換為關閉圖示以向使用者顯示同一按鈕可以完成兩個操作。
動效可幫助用戶構建更好的空間資訊心智地圖， 在小螢幕的時代， 這是至關重要的，用戶可以很容易地迷失在移動端小螢幕的迷宮中。但是，動效可以讓使用者通過返回螢幕間的步驟，來學習如何使用應用程式。
例如：使用者通過右滑動進入到一個頁面中，他們會發現如果想要回到主頁面，他們可以向左滑動。為了確保視覺的可發現性，應結合動效。
五、新手入門動畫可以幫助創建新用戶的上手入門，通過在正確的時間向用戶展示正確的東西，設計師能夠有一個高效的資訊傳遞，漸進地資訊傳遞使系統更容易被使用者學習和使用。在向使用者介紹應用程式的工作方式的同時，可以在新內容中加入輕鬆的動畫，這有利於用戶記住重要的事情。
六、製造驚喜動畫是給用戶帶來驚喜和增強使用者體驗的絕佳方式。但是，在嘗試用動畫取悅用戶之前，設計師應該先滿足用戶的基本期望，並首先嘗試消除體驗不好的基本因素。否則，不會有令人愉快的動畫效果。
動畫的頻率、持續時間和速度也會影響使用者對系統的感知，這是設計師在創建動畫時應考慮的。
理想的添加動效令用戶愉悅的地方是使用者真正需要動效的地方，而且你的動效也不應妨礙用戶的行為。
頻率設計師應該考慮使用者多久會看到一次動效。動效第一次看起來很新穎，可以讓用戶感到驚喜。但是，此後多次出現可能會變得煩人。在用戶測試和回饋中，可以經常收集到類似的回饋。
八、持續時間設計師應該意識到用戶在放棄任務之前願意等待動畫或其他操作的時間。
NN組的研究發現：任何100毫秒（1秒=1000毫秒）的內容對使用者來說是瞬間的。 理解動效需要一些時間，時間範圍從150ms到350ms。
根據Val Head的說法：一般的動效持續時間指標應該在200ms-500ms之間運行。 因為這是一個指導方針，所以我們的目標是讓動效看起來很自然。 用戶認同看起來很熟悉的東西，所以最終取決於設計師的最佳判斷。 當涉及動效運行多長時間時，速度太快，使用者可能會錯過它，速度太慢，使用者可能會認為系統太慢。
九、速度整體動效的速度會影響到使用者的感知； 較慢的動效會導致使用者感覺整個系統也很慢。 然而，動效可以用來隱藏載入延遲，並提高用戶的參與感。
載入動效可以讓使用者佔用視覺回饋，因此使用者可以感受到更短的等待時間，動效中的週期數量也可以提高感知速度。 Facebook有一個骨架內容載入動畫，這是傳統載入的優雅解決方案。
Viget的一項研究發現：相比較一般的動效而言，人們會等待更長的品牌載入動效。
十、可用性設計師應該考慮動畫可用性。 對於患有前庭障礙（一種面對運動過快的物體會發生眩暈的病症）的人，運動會引起頭暈，眩暈或噁心。 這是Apple iOS7可以關閉動畫過渡和移動背景的原因之一。
視差滾動，一種背景移動速度比前景慢的方法，是運動的一個例子，如果使用不當，會導致噁心。 為了解決這個問題，設計師要考慮不讓動效自動播放。 如果是由用戶啟動動效，他們將會更加準備，而且不會引起不適。
設計師應牢記以下幾點，保證最佳的實際輸出效果：
目標：與用戶溝通的動畫是什麼？焦點：用戶目前的焦點在哪裡 – 用戶在哪裡看？運動力學：
頻率：這部動畫多久播放一次？持續時間：此動畫應播放多長時間？速度：這部動畫應該播放多快？觸發器：動畫如何觸發？通過用戶操作？還是自動？協助工具：如果用戶關閉動畫，用戶體驗將如何受到影響？原文地址：https://uxdesign.cc/ui-animation-please-use-responsibly-e707dbdb12d5
本文由 @小賤劍 翻譯發佈于人人都是產品經理，未經作者許可，禁止轉載
題圖來自 Pexels，基於 CC0 協議
這是至關重要的，用戶可以很容易地迷失在移動端小螢幕的迷宮中。但是，動效可以讓使用者通過返回螢幕間的步驟，來學習如何使用應用程式。例如：使用者通過右滑動進入到一個頁面中，他們會發現如果想要回到主頁面，他們可以向左滑動。為了確保視覺的可發現性，應結合動效。
五、新手入門動畫可以幫助創建新用戶的上手入門，通過在正確的時間向用戶展示正確的東西，設計師能夠有一個高效的資訊傳遞，漸進地資訊傳遞使系統更容易被使用者學習和使用。在向使用者介紹應用程式的工作方式的同時，可以在新內容中加入輕鬆的動畫，這有利於用戶記住重要的事情。
六、製造驚喜動畫是給用戶帶來驚喜和增強使用者體驗的絕佳方式。但是，在嘗試用動畫取悅用戶之前，設計師應該先滿足用戶的基本期望，並首先嘗試消除體驗不好的基本因素。否則，不會有令人愉快的動畫效果。
動畫的頻率、持續時間和速度也會影響使用者對系統的感知，這是設計師在創建動畫時應考慮的。
理想的添加動效令用戶愉悅的地方是使用者真正需要動效的地方，而且你的動效也不應妨礙用戶的行為。
頻率設計師應該考慮使用者多久會看到一次動效。動效第一次看起來很新穎，可以讓用戶感到驚喜。但是，此後多次出現可能會變得煩人。在用戶測試和回饋中，可以經常收集到類似的回饋。
八、持續時間設計師應該意識到用戶在放棄任務之前願意等待動畫或其他操作的時間。
NN組的研究發現：任何100毫秒（1秒=1000毫秒）的內容對使用者來說是瞬間的。 理解動效需要一些時間，時間範圍從150ms到350ms。
根據Val Head的說法：一般的動效持續時間指標應該在200ms-500ms之間運行。 因為這是一個指導方針，所以我們的目標是讓動效看起來很自然。 用戶認同看起來很熟悉的東西，所以最終取決於設計師的最佳判斷。 當涉及動效運行多長時間時，速度太快，使用者可能會錯過它，速度太慢，使用者可能會認為系統太慢。
九、速度整體動效的速度會影響到使用者的感知； 較慢的動效會導致使用者感覺整個系統也很慢。 然而，動效可以用來隱藏載入延遲，並提高用戶的參與感。
載入動效可以讓使用者佔用視覺回饋，因此使用者可以感受到更短的等待時間，動效中的週期數量也可以提高感知速度。 Facebook有一個骨架內容載入動畫，這是傳統載入的優雅解決方案。
Viget的一項研究發現：相比較一般的動效而言，人們會等待更長的品牌載入動效。
十、可用性設計師應該考慮動畫可用性。 對於患有前庭障礙（一種面對運動過快的物體會發生眩暈的病症）的人，運動會引起頭暈，眩暈或噁心。 這是Apple iOS7可以關閉動畫過渡和移動背景的原因之一。
視差滾動，一種背景移動速度比前景慢的方法，是運動的一個例子，如果使用不當，會導致噁心。 為了解決這個問題，設計師要考慮不讓動效自動播放。 如果是由用戶啟動動效，他們將會更加準備，而且不會引起不適。
設計師應牢記以下幾點，保證最佳的實際輸出效果：
目標：與用戶溝通的動畫是什麼？焦點：用戶目前的焦點在哪裡 – 用戶在哪裡看？運動力學：
頻率：這部動畫多久播放一次？持續時間：此動畫應播放多長時間？速度：這部動畫應該播放多快？觸發器：動畫如何觸發？通過用戶操作？還是自動？協助工具：如果用戶關閉動畫，用戶體驗將如何受到影響？原文地址：https://uxdesign.cc/ui-animation-please-use-responsibly-e707dbdb12d5
本文由 @小賤劍 翻譯發佈于人人都是產品經理，未經作者許可，禁止轉載
題圖來自 Pexels，基於 CC0 協議