Is there an optimal duration for animating subtle transition effects? 150-250ms usually seems about right to me for most effects. Is there any research to confirm that this is good for most users or give a more precise duration? Does it vary widely for different kinds of transitions?
You can use the "Model Human Processor" system to decide the length of an animation.*
On average it takes a human 230 ms to visually perceive something, with a min/max of 70-700 ms across different people. That basically means that some people are faster at perceiving motion than others, and what some people can perceive in 100ms will take others else 600ms to notice. (Like most human traits, perception time distribution approximately follows a normal curve.)
The other answers give good advice for how choose longer vs shorter animations – but these are the numbers that actually define the human limits of how long is too long or too short. If an animation is repeated for many interactions (like a contextual menu), a slower, more-perceivable animation (600ms) is going to feel quite tedious to most of your users. Micro-animations (like a nav bar or a context menu) of ~250ms will be noticeable by most people, but just noticeable enough that they won't feel like they're waiting for it.
[*] This is a methodology of formal Human-Computer Interaction that's used to estimate the time to complete various interactions with a system, including humans' typical times for cognitive processing, sensory perception, and motion.
The advice is: it depends. But here are numbers that can help us figure out what works best:
Google ran experiments wherein their search results pages were slowed by 100 to 400 milliseconds. The slower response times had an impact on the number of searches per user: even weeks later, users from the slowed pages were not searching as much: https://research.googleblog.com/2009/06/speed-matters.html
Another study from 2016 indicates 53% of mobile site visits are abandoned if they take longer than 3 seconds to load: https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/
So the 100ms to 1s window is quantifiably narrower than previous research suggests based on user habits.
It takes humans on average 215ms just to react to a visual stimulus: https://www.humanbenchmark.com/tests/reactiontime
The farther away something is from the eye, the longer its duration must be to ensure:
- it attracts attention and
- it's still animating after the eye has swiveled into position to observe it. (70-700ms according to the Human Processor Model.)
I dug through all this research for a book, Animation at Work. I hope you'll enjoy it when it comes out later this year :) In the meantime, may these numbers help you figure out a good duration!
Previous answer from 2 years prior
I recently covered this in a seminar on UIE:
You have a window between 100ms to 1 second for transitions. At 100ms, animations happen so fast as to appear instantaneous, defeating their purpose. (From a study popularized by Jacob Nielsen.)
The sweet spot that shows up time after time in game and UI design is 250-300ms. For transitions that bounce or are elastic, 400-500ms lets the motion read better.
Hope this helps.
According to Google's Material Design guidelines:
Larger animations on mobile devices are 300-400ms long. Smaller animations can be as short as 150-200ms. Animations longer or shorter than these can feel sluggish or difficult to follow.
I think this isn't Material-specific, but a good guideline for general-purpose UI animations. I'd imagine Google researched these numbers thoroughly, too.
My (personal, largely unsourced) view is "as fast as possible while still communicating what you need". I almost always start with a default of 200ms then tweak, usually ending up faster.
I can tell you from experience that it does vary for different types of transition: shorter animations work for smaller elements and/or small displacement. To animate a large element a long way you'll need a longer transition time.
I've found what helps a UI feel consistent is actually to retain similar velocities, rather than similar timings.
I would say (from personal preferences) - make them as fast as possible, without being too fast so the user can't distinguish what happened.
If, for example, a navigation bar is to slide in from the left side on a button click, make it as fast as possible, without losing the feeling of the menu sliding in, thus making it look like it just suddenly appeared.
"Does it vary widely for different kinds of transitions?"
I think the key here is the impact the transition has on the usability of the interface.
If the transition makes the user wait before they can continue with a common task, even a short transition can become very frustrating. For example, a 200ms transition that delays displaying the options for a command may result in an unresponsive feel for a power user who knows how to execute many commands in sequence using keyboard shortcuts.
On the other hand, even a very long transition may be fine for something that is not time-sensitive. An alert taking 3 seconds to appear in the corner would not harm the user experience.
The right approach is probably to test your interface (with real-world use in mind, especially anything that is likely to be repeated a lot) and assess the impact.
Another important consideration is to make sure any animations don't prevent a user from being able to perform actions. If there is anything they could start doing before seeing the interface, make sure it still works before the interface has actually appeared.
Two contrasting Windows 8 features, which I both use a lot, illustrate the difference:
Pressing the Windows key and typing the start of an application name is the easiest way to start a program in Windows 8. This features two relatively fast animation steps, but it works correctly even if you don't wait for the interface to appear. I can press Win then type w and press enter before anything appears on screen, and Microsoft Word still opens correctly. The animation doesn't interrupt my workflow.
Logging into Windows when on the lock screen requires you to press a key to make the password box appear, then type your password. However, there is an animation for the password box to appear, and nothing you type before it appears gets entered in the box. This is extra annoying because:
- You can't see the password you typed, so you don't realize not all of the password was entered.
- There is a several second delay security feature after entering an incorrect password.
The animation is quite short, but because it interrupts the workflow on a common task and has frustrating consequences, the result is a bad user experience.