How fast should your UI animations be?

This is a question I get asked a lot at workshops and talks. Essentially this question hits on the important topic of timing for UI animations. Good timing is essential for creating a good experience.

Often times I hear designers and developers say they have one specific small number, like 200ms, to use as the duration for any and all interface animations no matter what. This sounds like a good solution, but it over-simplifies the complexities of timing and won’t always get you the best results.

Good animation timing is more of an art than a science. Thinking in terms of a range instead of one set duration value will serve you much better in your design work.

200ms to 500ms seconds is a good range to start with for interface animations.

Using this range as a guide, small UI animations — ones that involve smaller elements or small amounts of change — tend to be on the lower end in the 200ms to 300ms range. Larger motion that covers a lot of ground, or motion that uses complex bounce and elastic easing, usually works best on the higher end of this range, getting up to 400 – 500ms.

timing range

Where do these numbers come from? (aka geeking out over the research)

This suggest range are largely based on research from the Neilson Norman Group and the Model Human Processor. The Neilson Norman Group write that 100ms is perceived as instant, and 1 second is considered the upper limit of a user’s flow of thought. Together these outline a range of 0.1s to 1s for feedback to feel connected to a specific user action or input. One entire second feels like ages for UI animation though, so that’s why the suggested upper limit for durations is half that at 500ms.

The Model Human Processor finds that on average it takes a human 230ms to visually perceive something. So, an animation with a duration of 200ms will likely be within range to be perceived by the average person. Much shorter and you risk it not be visually perceived at all, which would kind of defeat the purpose of animating it in the first place.

There are exceptions to every rule, of course, but using a range as a starting point will help make your timing decisions easier. Starting with numbers based on this range gives you place to work from to find the timing that feels right for the interaction or effect you’re going for. Getting UI animations to feel right is more important than the exact numbers behind them.

  • Nice one, Val! Totally agree with “Getting UI animations to feel right is more important than the exact numbers behind them.” The speed of animation depends on the effect you want to achieve. It’s not necessarily small objects should be animated with the upper limit of 300ms. At the same time, not necessarily large areas should be animated with the lower limit of

    But there is one minor note – NNG has nothing to do with “found that 100ms is … 1 second is…” These are based on scientific research and not on NNG’s finding. Nielsen himself refers to the research as [Miller 1968; Card et al. 1991]

  • valhead

    Ah, you’re right! They’re basing that on research from others. Totally missed that.Thanks for pointing that out.

  • Pingback: How fast should your UI animations be? | Val Head – Designer & UI Animation Consultant – Andres' blog()

  • Pingback: Sélection de liens #webperf n°9 - ? Nicolas Hodin()

  • SocialChooozy

    Best option may be play with UI speed on own eye while developing. Change speed, check, if don’t like how it feels – change again, etc..

  • valhead

    Yes, that’s a good method. Especially since the more you do, the better you’ll get at timing in general.

  • valhead

    To your first point. Yes, the overall feel and the effect you’re going for should hold more weight than any numbers, range or absolute. Timing is more of an art than a science :) I like the range as a starting point to work off of. A lot of people find it more helpful than starting with a “blank page” or infinite possibilities.

  • valhead

    It could be just a coincidence. Response time, no matter how it’s measured, probably varies greatly based on the individual and their current context as well.

  • I think these numbers can also be applied to JavaScript debouncing of event listeners that fire often (mouse scroll, user input, window resize).

    I tend to use 150ms for debouncing user input – it gets noticeabley visible in delay if you go up to 500ms and makes it feel as if your site is unresponsive.

  • Great article!
    Indeed, what you should use is contextual, however the 100ms to 500ms range is a good rule of thumb, so beginners won’t just mindlessly throw in numbers and hope for the best.

    Btw it’s Nielsen not: “Neilson” or “Neilsen” (you used both) — I know because he’s a Dane like me :-)

  • One of the big issues I’ve always had with the current system is how it only accepts a singular value of time, when we should be phrasing it as time *and* distance. Just as we do when we measure the speed of anything else. Imagine the following conversation:
    “So, how fast were you going?”
    “32 minutes!”
    Understanding that context is key, we know that a runner keeps a pace of minutes per mile or kilometer. Vehicles are miles or kilometers per hour. Web animations are milliseconds per… what? 100px?
    I.e. 250ms on an icon pop does not at all equal 250ms on a page-wide motion.
    Granted, this theory does falter when the object is not moving, but just adjusting transparency. But never-mind that. ;)

  • Half Crazed

    This is true. A successful UX will use the triad of calculating speed, distance, and time to determine what types of UX animations are occurring.

    Speed = Distance / Time
    Distance = Speed x Time
    Time = Distance / Speed

    Time: How much time do you think a user will put up with an animation? Obviously they would not appreciate a 1+ second animation for a UI interaction in most cases.

    Distance: How much movement really needs to occur? 10px? 50px? 20%?

    Speed: At what speed is comfortable for both (A) visually seeing a transition without jank, stutter, etc?, and (B) not too slow or not too fast as to cause frustration?

    The distance measurements we use is either absolute (px, cm, in, etc) or relative (vw, vh, em, %). It’s important to understand the amount of distance an animation/object is covering so that the transition is smooth. You wouldn’t want something moving 2000px at 100ms – it wouldn’t be a very smooth or gentle transition – even at 60fps.

    So… really, they are all variable. If someone says to transition an item and the animation speed is 200ms, one should kind of know if it will work (or they’re not paying attention). It’s definitely contextual, but it may vary too much to set a defined limit… quantifying and qualifying these limits would be difficult, and if it has been done already, I’d be interested in seeing the results.

  • Pingback: ease-out, in; ease-in, out | Tech +()

  • DanialKeshani

    Good words. animating an item for 1000px in 500ms won’t make a consistent experience for the user.

  • Marco Aurélio Rodrigues

    Great article. I’d say the animation speed will always depend on the context too. The same animation on a desktop may have a different speed in a mobile device. The 200 to 500ms seems to be a nice range.

  • valhead

    Oh yes, the context plays a part in what feels right or looks right for UI animations as well. That can affect both the coding choices and the art direction/design choices at times. I cover a few examples of how some sites change their animation approach based on available screen size in this video: http://valhead.com/2015/06/19/screencast-animation-in-responsive-design/. It’s really interesting to see how the different sized “stages” on which the animations play out affect its perception.

  • Marco Aurélio Rodrigues

    Really interesting video Val. Thanks