Every time I see animation discussed by designers, they're thinking about it in terms of polish and "delight", and then balancing those things with perceptual latency. It's not entirely incorrect, but a couple of minor nits:
1. Delight is overblown, in my opinion. I think most of the people truly delighted by fancy animation are just other designers.
2. It's more useful to think about state when deciding when to animate. Could the user have trouble perceiving the change in state that just occurred? If so, then use an animation to help them visualize what happened. I believe this is the primary reason to use an animation - all others are vanity.
> Delight is overblown, in my opinion. I think most of the people truly delighted by fancy animation are just other designers.
If (and that’s a big if) animation is used in moderation only when it actually communicates something and isn’t an active impedence (as demonstrated in the linked post), I think it has a significant effect for users. It’s just not the effect that many might expect.
Meaningful, unintrusive animations are one of the myriad puzzle pieces that come together to form a positive impression. They’re a sizeable chunk of that last 20% that separates “good” and “excellent” in users’ minds. They’re not strictly necessary, but between two equally good competitors they’ll help one pull ahead of the other, because users come away with a stronger impression of “solidness”. It’s not unlike how people tend to consider heft and resistance to flexing as markers of higher quality in physical products.
The problem is that since a decade or so ago, UI design as a whole has veered heavily in the direction of vibes, slideshow wow factor, and “branding value” (I felt a pang of nausea just writing that) and away from the volumes of well-researched best practices, and regard for good use of animation has been lost along with it. We’re well overdue for a correction that pushes UI design back in the direction of practical usability and away from Dribbble appeal.
> users come away with a stronger impression of “solidness”
This really is what UI polish of any kind is all about. You feel like you can trust it more, it feels more robust and reliable. Animation and gestures are a part of this, but it’s only the last mile after everything already feels robust.
Before you make it more glitzy you have to make it less glitchy.
> Before you make it more glitzy you have to make it less glitchy.
I am copying this so that I can use it later when the marketing comes in and suggests we devote more dev time to yet another landing page renewal when we are at capacity just handling Bug tickets
That I can agree with. Applying polish to glitchy software is like putting a high end leather interior and soundproofing in a car that only starts 85% of the time and occaisionally opens its rear hatch while on the road for no apparent reason.
> communicates something and isn’t an active impedence (as demonstrated in the linked post)
woah! you are starting from the point an individual preference is any metric to gneral public preferences and understanding... there's not a SINGLE study cited on the blog!
Fully agreeing with this. I was also surprised that the appearance change of a button on mousedown is considered an animation here. ("Another purposeful animation is this subtle scale down effect when pressing a button.")
Isn't this just very basic optical feedback to indicate that a component is clickable at all and that the click was registered?
It fits both the dictionary and colloquial definitions of animation. If there is any domain specific jargon, surely that applies too. I can't understand why this wouldn't be considered an animation...
I can see either side of it, but in my mind animation (in this context) means the generation and timed display of synthetic tween states to smooth the transition between the display of actual states. The mouse-down case is (in this context) an immediate change from the up- to down- states, without additional frames in between, so is not an animation by this particular domain-specific definition.
That makes sense. I think of it like visual movement, a difference in position over time. Even a single step represents a change in position, even if the time increment is very small. The transition is the animation, the duration would be 2 frames: up, and down.
In a nutshell: put two different frames in sequence, and you have an animation.
But the up and down really consists of two user actions, pressing the mouse button, and releasing it again. See drag-and-drop for example, where that distinction is important. It’s even important for simple buttons: You can generally abort a button press by moving the mouse pointer outside the button area before releasing the mouse button again. In that case, the button action isn’t triggered. The pressed-down state visualizes that the action will be triggered when you release the mouse button while still in the button area.
Animation is when more than one consecutive step happens on it’s own. I’d argue that even tooltips appearing and disappearing after a timeout doesn’t constitute an animation, because the disappearance isn’t immediately consecutive with the appearance, and (maybe more importantly) the intervening state of the tooltip being shown is meaningful to the user as a distinct state.
> Delight is overblown, in my opinion. I think most of the people truly delighted by fancy animation are just other designers.
Appreciating delight (for it's own sake) in software design I'd consider a core trait of (old-school?) Apple fans. E.g., lamenting the decline of whimsy in the post-Jobs era.
I think there's truth to it being relatively niche, appreciating delight that is, but it's certainly not confined just to designers. E.g., like I'm saying here, a core trait of Apple fans is appreciating these kinds of details.
I should've been more specific. I was moreso referring to the trend of designers claiming they're adding delight, where in reality they're just muddying the experience with visual effects that might be striking, but lack any depth or improvement to the core experience.
I absolutely do believe that software can be delightful. Linear comes to mind as an example - there are lots of little nuances to their interactions and it just feels so good to use.
The other problem I encounter is designers working in B2B, but designing like they're working in B2C.
For B2B (especially enterprise B2B), your software is just a tool your customers' employees need for their day jobs. Fancy animations, multi-colored gradients (because gradients mean "AI" now, right), and other gaudy crap does not make it easier for anyone to do their job. It's just noise -- constantly distracting users who are just trying to navigate through dense, text-heavy dashboards.
If you want to design "pretty" and "delightful" experiences, then it doesn't make much sense to join a company that revolves around CRM/ERP workflows. Work for a company whose value is directly tied to users' warm and fuzzy feelings.
Also most consumers don't want to admire fancy animations.
If they want to switch channels on their TV, they want the channels to switch now, not wait for a fancy animation to entertain them in the meantime.
Delight sounds similar to what game designers call "juice" and, done well, it really does make a game feel delightful beyond its pure gameplay.
I've had the same feeling with more utilitarian interfaces, but it's pretty rare. I don't know why. I expect it's partly because we have different expectations for programs than we do for games, partly because the context and the interactions are pretty different, and partly because most organizations do not have the will or the ability to make interfaces that satisfying. (After all, it's the worst sort of thing for most organizations: something that requires taste, time and experience and cannot be managed, measured or executed by committee.)
Frequency often depends on individual use case, though. In an actual application, there are few elements where you can safely exclude the possibility that someone will use the element frequently.
I can tell you from experience that impressive hero banners and animations that get the user's attention reduce bounce rate. That might not matter if you're established and you get customers via product market fit and word of mouth, but for small shops trying to land early customers it's crucial.
It makes a significant difference if you’re talking about a web page that’s more like a product brochure, or if you are talking about an application the user wants to get a task done with. The latter shouldn’t have “impressive hero banners”, and “animations that get the user's attention” only when the user needs to be made aware of an important application event.
> Could the user have trouble perceiving the change in state that just occurred? If so, then use an animation to help them visualize what happened
I think this is the only justified use of animation in UI, however I wasn't satisfied with the dilemma of increasing perceived transition while increasing perceived UI latency.
I found it's possible to get the best of both for event triggered state changes i.e clicking on stuff, by sticking to ease-out based transitions, where the start of the transition is instant and the end decelerates.
This makes it feel just as snappy as no animation, while still helping to communicate a transition, because we are more sensitive to the latency of the start of the transition when it's an event - since we are anticipating a reaction, which is satisfied as soon as it starts to react.
> Delight is overblown, in my opinion. I think most of the people truly delighted by fancy animation are just other designers.
I disagree with this, as much as I want it to be true. Just ask an Apple/iPhone user to use an Android phone for a week and then ask them how the experience was, they'll tell you something felt off or janky about it, and a lot of it comes down to really well designed animations on iOS for everything you interact with.
Regular consumers may not use the word delight to describe the user experience, but they do notice it when faced with what is (to them) an inferior experience.
Except "Reduce Motion" is one of the most well-known and praised setting, it has been passed on as a tip to increase the overall snappiness for as long as the setting existed.
To the point people regularly ask for a stronger setting to straight disable animations and not just reduce them.
I used to be a huge fan of disabled animations on Linux, but unfortunately many websites end up being completely unusable. Somehow the animations affect functionality. Probably the developers never test their software with disabled animations.
So now I just have the setting to be super fast, but not disabled. Works perfectly well.
Especially when I press the volume button, and it shows up rotated 90 degrees at a different side of the screen, or the litany of other iOS bugs..
This experience has stopped being the case for quite some time now. Sure, a 60 USD low-end device is no ground for proper comparison with a 1000 dollar one, but androids in a similar category absolutely have similar animations and "niceties". I have actually recently moved from iOS to Android, and I do prefer the latter's visual UX. I will even go as far and say that there are less UI bugs.
(As for "smoothness", sure, apple's SoC game is far above any android manufacturer's, which helps a lot)
Apple could learn a thing or two from this. Too often I'm waiting for their silly animations to finish. Just a moment ago I swiped to scroll the view to the bottom, then immediately tapped the button when it came into view, but I had to tap it multiple times until the bouncing stopped.
That's just one example because it just happened, but this happens ALL the time. I know Apple can do better. My Android phone felt so much more responsive (the 120hz screen helped, I'm sure), simply because the animations were snappier.
Other examples that come to mind real quick:
- Swiping up to switch apps. That one is awfully slow. (Actually, most gesture-based activities are painfully slow!)
- Dismissing notifications (esp. on Mac)
- Opening the drawer thing
- Revealing the dock
- Sometimes I see animations stacked upon each other. One animation has to fully complete, then another one, THEN I can finally use my computer again.
It's ironic that I have to go to Accessibility settings and disable these things to make my device accessible.
Whenever my apple wallet connects to my phone, It plays a totally useless animation that feels like it takes forever, and covers the entire screen. In that time, you cant see or do anything on the phone. So annoying, and for no reason. Just give me a little haptic when it connects.
When does my wallet slide slightly from the magnetic center and then back into place most often? When I’m getting it out of my pocket.
When am I trying to just use my goddamn phone the most? When I get it out of my pocket.
So, it ends up being that ~50% of the time I need to use my phone, I have to wait for that goddamn 3 second animation first.
If some engineer introduced a 3 second regression in the time for Face ID to unlock your phone 50% of the time, it would be noticed and fixed immediately. But call that 3 second regression a “surprise and delight animation” and suddenly Apple designers love it and force it on you.
same when attaching a locked phone to a magsafe charger. it seems like a small thing but i actually interact with my locked phone enough for that to get on my nerves. i'd prefer the haptic feedback but i would even settle for being able to swipe it away - nope. not an option.
Not all of them. For example if you open a conversation in messages it slides left, and you have to wait before you can scroll. When you cancel a route in Maps it zooms back on your position and you have to wait before you can move the map again (and it’s really slow).
An extremely infuriating one that repeatedly gets me because I forget about it: the AM/PM wheel when setting an iOS alarm. If I set an alarm the night before and the last thing I do is flick the wheel to AM, but then hit save before the animation has finished it's very subtle and slight easing/bouncing animation, the setting remains at its original value (PM because I'm creating the alarm at night) and thus the alarm does not go off in the morning when I expected it to.
You're right, that one drives me nuts. Any slide wheel doesn't change its underlying value until it stops animating, even if it's 99% of the way there. You navigate away from the screen thinking the new value is set, but it's not.
That one falls into the category of UX felony as far as I'm concerned. It's not just delay or confusion, but actively misrepresenting a value.
the macos switching between spaces/desktops is INFURIATING, because until the animation fully finishes, all the clicks/keys are registered on the last space, and the animation takes a while...
apple have completely lost the plot, and organisations of that size are incapable of producing good user experience w/o a de facto dictatorship person who has an idea what here doing (a la steve jobs)
this is worsened by the the fact that even on hn people have no idea what's they're doing in terms of design most of the time, because they fail to realise that the average person isn't like a fan of their product lol, they just see it as a utility that needs to perform a bare minimum of functions reliably, with a consistent ui, like thats literally it...
every time you want to change something, ask yourself, if I show this to my grandma, and unless her reaction is "omg yes this is a million times better, pls do that" DO NOT CHANGE ANYTHING
I’ve tried to find a way to reduce or eliminate those workspace switching animations and have not found a solution. I will say that using a hotkey to access it makes it go the fastest compared to swiping, but that’s about it. There are more extreme solutions like Flashspace but it’s not the greatest.
it got on my nerves to the point i switched to https://github.com/nikitabobko/AeroSpace, lol. things like smooth scroll help you follow your place in the text (its something i cant live without, even in a tui editor). a fullscreen workspace switch should not need that.
FYI there is a long-standing bug with ProMotion and switching spaces. Their length is tied to refresh rate somehow. Switching to static 60hz makes them faster (but what an annoying choice to have to make!)
iOS default animation speed is 350 ms, at least for SwiftUI. This has always felt a bit too slow. And recent system animation changes felt gratuitous to me (opening the action bar on iMessage for example).
OTOH this article is basically downstream of Apple’s interface design philosophy.
Personally I would even speed up these animations. 300ms is too high. I prefer animations that are almost imperceptible. You might even only notice them if you take them away.
I used to go for 250ms, now I go for 200ms. I find that about the sweet spot for UI transitions where it helps you to understand what’s changing and how and why. And if it doesn’t meet those criteria, don’t transition it.
200ms is also nice and short to write in CSS, .2s. I contemplated shorter, but I found that by 150ms a transition can start to feel like it’s a mistake, a brief rendering glitch, especially if the first few frames of the animation are dropped, as can be common (.2s is already down to only ~10 intermediate frames). It’s too short to get the benefits of an animating transition, but too long to be or look or feel instant.
I think if the animation "helps you understand what's changing and why", sometimes that's a sign that the change could be redesigned - moved to a different part of the screen, for example - so that it becomes clearer without needing to be animated.
For example, if pressing a "Save" button makes a "Save successful" toast appear on top of the screen, it's tempting to animate it in, so that the user notices it. But it's better to replace the button text with "Saved" and gray it out, which achieves the same goal and feels great without any animation.
In general I think toasts are a borderline antipattern, particularly those presented as a chance for the user to undo some action that they accidentally triggered (doubling the panic since now the undo has become a time bomb). Just don’t make the consequencial action so easy to trigger in the first place and where relevant (on iOS or desktop) support the standard undo stack.
Toasts on large displays are definitely an anti-pattern, they're just too far from where the action that triggered them actually happened.
On mobile it's a bit different, because often you don't have the space to put an "undo" button or status text right next to the thing you just did. So you put it at the bottom or something in a toast.
Still not good, but more justifiable.
Also iOS does not have reliable undo actions. Android does, but on iOS there isn't an equivalent. No back button. Well, maybe a back button but definitely not required and not enforced in any way.
Still iffy on mobile because the way the device is being held can’t be assumed. The area the toast appears is very easily hidden by a hovering thumb for instance, especially for people with larger hands.
Undo and back are conceptually similar but different. On iOS, consistently anywhere you can enter text you can give your phone a quick shake (similar to a person shaking their head “no”) and it’ll offer to undo the last edit. Many apps like Reminders use this for actions like item completion too. There’s a native undo stack you can use to leverage this as a third party dev. There’s also a gesture that can trigger this but I have yet to commit that to memory.
Android does not have an undo gesture. Some skins (like Samsung’s) implement something similar but it’s not consistent and it’s limited to text editing.
For going back, all apps built with native iOS UI toolkits have a swipe gesture that goes back to the previous screen. Cross platform apps built with other frameworks are notoriously bad about not implementing this, though. It’s true that there’s no cross-app back gesture, but swiping back and forth on the home bar is a rough approximation.
IME it's the exact opposite. That iOS undo action is more or less theoretical - the apps that support that are some of Apples... And that's it.
The android back action is universally supported. Its literally a button, still, to this day, persistent on your screen by the OS.
Also, the "swipe back" action on iOS is more or less fake. Its applied so inconsistently it might as well not exist.
In my head "back" and "undo" are usually the same thing. iOS has a good interface, but this is one glaring blind spot they missed to Android and browsers. It actually makes iOS quiet frustrating to use.
Also, barely related: but the "shaking your device is like shaking your head no" thing is the stupidest thing I've ever heard in my life. I'm sure Apple thinks its very intuitive and good design, but it's really, really not. That's one of the least discoverable things I've ever heard. Apple please don't do that.
Swipe to go back support is pretty wide if you select for iOS-first apps (I do). It’s glaring when I try to use it and it’s not there, so when that happens I’ll either go find an alternative or drop back to the web app (where Safari will definitely implement it).
My Android devices all have the gesture bar enabled because the old style button bar is an eyesore and easy to trigger accidentally (Android’s swiping from the right to go back is also too easy to trigger as a right-handed person, but that’s another story).
My metal model for the undo/back split actually follows desktop browsers. Cmd-Z isn’t going to undo navigation while Cmd-[ will, and so the two are separate and distinct.
With saving, I usually add a confirmation directly next to the save button, so the save button itself doesn't change state (people often like pressing save multiple times!). But even then, I find a little bit of animation that moves the "saved" text away from the button to indicate where it's come from can be really helpful for intuitively connecting the two interactions. The animation should be fast (100-150ms max, often as low as 75ms), and subtle (just a slight step to the side), but it gives the user more of a feeling about what's happening.
> With saving, I usually add a confirmation directly next to the save button, so the save button itself doesn't change state (people often like pressing save multiple times!).
There is no problem with the button changing states as long as it only happens after the current document state was successfully saved and becomes active again when you make changes to the document. That way the button doesn't represent the outcome of some action but the sate of the document - unsaved changes = button enabled, no unsaved changes = button disabled.
First thing I do on any android phone is enable developer mode and double the speed of animations. Drives me crazy when I see one running them at normal speed!
I feel like web design animations are more similar to PowerPoint than folks want to admit. What I mean by that is that quick cross-fades can be used 99% of the time to tidy the look of UI but you rarely need to do anything beyond that.
>> This animation explains how Product Intelligence (Linear’s feature) works. We could have used a static asset, but the animated version helps the user understand what this feature does, straight in the initial viewport of the page.
That might be the designers intent, but that's not what it does for me at all. First, the animation shown is on some weird 3D angle which is not part of any sane UI. Why is that? Not to convey anything about the actual experience of the app shown. That 3d look certainly does not "help the user understand what this feature does"
The fade-in of the animation seems to draw me in to that area of the page which I assume is the intent. The 3D perspective helps me understand that the text in that box is not part of the page I'm reading, but a view of something else - their product. But it doesn't really help me to understand the product.
Interesting. Apparently browsers (at least Firefox) uses the OS' setting for this. I still have animations enabled in Windows 10 due to how windows are rendered when they are opened, but the content isn't painted yet.
However, there seems to be way to set this manually in Firefox. [1]
Go to about:config and add `ui.prefersReducedMotion` set to `1`.
Can be verified with https://animate.style
Here's a subtle problem: An animation that looks "delightful" on the screens you have, might look pretty bad on a screen you don't have. For example, the author's animation for scaling a button looks fine on my M1 MacBook Pro, but jittery and sluggish on the crappy IBM ThinkVision monitor attached to my MacBook. See for yourself:
> But they can also do the opposite. They can make an interface feel unpredictable, slow, and annoying.
Indeed, just like the immediately following example, which slows down page scrolling, breaking predictability and consistency of one of the most frequently used and fundamental page operations
And its purpose is, of course, only fulfilled in the imagination of the designer
> This animation explains how Product Intelligence (Linear’s feature) works. We could have used a static asset, but the animated version helps the user understand what this feature does, straight in the initial viewport of the page.
It doesn't really do that: first, it's happening partially out of focus because I read top to bottom, so I'm still reading your title and leading paragraph, or did you want me to be distracted and skip the text? So I see the same thing on first focus: static image. And I can't rewind it to watch again since I missed it the first time.
Then it has a very weird angle which makes all the text harder to read, my guess is to help see the 3D nature of the animation when to show the arrival of the product as a separate overlay? So this would likely not exist in a static image and be an improvement.
> To give you an example, a faster-spinning spinner makes the app seem to load faster, even though the load time is the same. This improves perceived performance.
Perhaps due to poor design by companies that abuse the fast loading spinner when, in fact, nothing is happening, I instinctively trusted the slower spinner more.
The only thing that I trust is loading bars that make nonlinear progress, clearly indicating that there's specific steps and/or measurable progress happening.
Android 16 just introduced a stupid animation when unlocking your phone. Rather than show you what you want to see as fast as possible, the designers decided you would have to sit through watching their fade in animation dozens of times a day.
Designers either don't use their own products, or have no taste (possibly both).
You can disable animations in Android in the accessibility settings. Not just make faster but completely disable. That's one of the reasons I'll never go to iOS. I can't stand losing time on pointless UI stuff. Wasting my time isn't delighting at all.
Great tip. I had the "Remove animations" setting feature enabled. Hopefully it's just a temporary bug that this doesn't disable the lockscreen animation.
One thing that instantly ruins my day is animation where the element state is inconsistent during the animation.
For example - I think it's on Windows where I keep running into this - on notification popups from some apps, you can't click "X" to close until sufficient time has passed after the popup animation. If you try to close it in that time, it instead acts as if you clicked the notification to open it. Super annoying.
Another, on Mac, when switching desktops, sometimes an app will show on the screen briefly before flashing to another app. The animation is slow enough that it often tricks me into thinking it's ok to do stuff and then nope the app changes. Even worse, I think it occurs randomly.
Note to designers: if you do choose to include an animation, it better be the most rock solid implementation ever or I will immediately think you're a twat and your app is a buggy pile of crap.
I'm a big believer that animations need to validate what you already know, they aren't the information itself.
This means, if you turned animations off you would still work as fast and understand the flow the same as if animations were enabled.
For me, the purpose of animations is to soften the UX journey, and to confirm what I already knew, by giving me small indications that yes, the UI is truly in the state I expect it to be.
Such as fast highlighting of on hover items, so I don't have to correlate the mouse position to the control.
I love that example of tool tip popups taking 0ms once you have popped up one, that is a clear signal that the UX understands you are trying to learn more about the controls you're hovering over.
That's a perfect representation of how animations signal understanding of your UX journey.
Clickbaity title; more like "things to consider when designing animations."
I appreciate subtle animations like the button press. Visual feedback gives me confidence in UI actions and makes things less jarring. Same idea with CSS smooth scroll.
But a lot of this feels subjective. Anybody have user studies on the effectiveness of UI animation?
Also, I think a lot of people would be happier if web apps exposed settings like zero animation / mild animation/ full animation. Power users could speed up their workflows by turning off animations. Kinda like my phone UI settings.
That is very not-enough, as it is literally "prefers reduced" but i need (not prefer) zero animation. And yet with this present several years already websites just happily ignore the setting. So i believe this should be honored by browsers which should just stop animating transitions. But then there is the other elephant in the room (JS anims).
It might be kind of interesting to see a well-done usability study around animations. I tend to assume they are pretty useless, but I guess I can see some point in drawing the eye from a button you press, to some UI component that it generates.
OTOH, it isn’t clear what the baseline should be. The easy way to do an incorrect study would just be to toggle off animations and have the very dynamic design with components popping into existence without any hints. But, that’s flawed, a UI made from the ground up with the assumption of “no animations” should just be less dynamic, rendering the whole concern moot…
In my opinion the bare minimum for UI animations is where a large percentage (30%-40% or above) of the screen changes. This kind of thing doesn’t faze even moderately advanced users, but for many below that level it’s confusing because there’s not necessarily anything that ties the two UI states together.
Hmm. That isn’t my preference—animation is best used to draw attention to something where I might noticed the cause-and-effect. If nearly half of the screen has changed after I hit a button, I hope to notice that!
Like I said, there’s a split between those who are and aren’t technically inclined.
The issue for non-technical users is that without an in-between state, UIs can be confusing because it’s not clear what triggered the dramatic change. If we take a typical mobile app as an example, the animations that occur when a user drills down communicates a couple of things:
- The list item in the screen being pushed out of view maintains its pressed-down highlighted state through the transition, making it clear what was tapped to trigger the action
- The horizontal animation of the following screen pushing the previous screen out of view makes it clear that the how the two screens are connected and that the user is traversing a hierarchy, similar to going through a series of doors (which in turn, communicates how to get back out)
Similar principals apply to sheets/drawers animating in. Without this animation, it can be unclear if the screen appeared as the result of a user action (and if it did, what action) or if the app just did it of its own volition.
I am pretty anti-animation, but you make the point well. Animation allows apps to be more featured, using animation to help new users follow what's happening. As long as it can be turned off, experienced users benefit from the extra features. I had never thought of it as a learning aid, rather just an unnecessary distraction to make the app look cool.
I have a blog post draft called, “5 principals of interactive animation” aping the “12 principles of animation” from the 80's that I thought every would-be UX designer might learn from. It mirrors a lot from this post!
UI animations actually do have one valid use: clarifying UI state changes to third parties.
When you're the only person using the computer, UI animations are pure time-wasting anti-features. You obviously know how the UI state changed because you're the one who requested the change. If the UI state changed without your explicit request, that's a bug that needs fixing. But somebody viewing your screen remotely can't see which keys you're pressing, and they don't know what you intend to click on before you've actually clicked it, so to them UI state changes can be surprising. Animations can help them follow what's happening.
Of course, animations should be disabled by default, because most computer use is not performed for an audience, but having the option to enable them is occasionally useful.
> You obviously know how the UI state changed because you're the one who requested the change.
We must be using different devices because mine often fail to register my intent and in that case the failure to animate is often the only signal I have (that doesn't take more than a few seconds to register)
None of the animations described in the article are of this type. Opening a text input area or changing desktop should be instant on all modern hardware. If you genuinely have something that can't be accomplished within one frame it's acceptable to display a progress bar, but I don't consider progress bars to be a "UI animations".
I have a problem with animation every time it induces latency. It's okay to animate some action that would take that much time anyway, but waiting for purely cosmetic animation to finish feels sluggish and not enjoyable.
Yes, animations are fine for things like progress bars, where they visualize something happening without interfering with user actions. But otherwise, animations should be avoided, or limited to something like 100ms.
Whoever designed the keyboard animation for Walmart self checkouts should take note.
Every time you want to type in a product by name, you must endure a 2 second slide-in of the keyboard before you can start typing on it. It's so slow that I feel that I could have completed the search and started on the next item before it's even done animating, if there was a way to disable it.
I sincerely hope employees don't have to use systems like this all day that reduce their throughout by more than half.
I remember early in my career I was working for a consultancy and the user was complaining that the search results were slow, our tech manager just LOVED this problem, in his mind he would get to go down the search engine rabbit hole - analyse the search query, maybe theres a more advanced indexing algorithm that he could find to speed it up, this could take weeks of benchmarking and comparing and prototyping and everything, what a wonderful rabbit-hole where the first prize is a happy client because of his algorithmic genius!
But me, being a bit more pragmatic, instantly benchmarked it, saw the search backend was responding quickly and it was just the animating menu that showed the results that was slow to animate. I changed 1.6 second animation to a 0.2 second animation, a change that look maybe 5 minutes to benchmark, find the code, and then change it,
The tech manager refused to accept that the solution was that simple, and only confonted with irrefutable evidence (direct client feedback AND benchmarks that showed that the search backend was already fast) that he accepted.
This recently happened to me when I was using an online website for preparing for a drivers license test. After finishing a 20 question practice test, the site would show a cool confetti animation on top of everything. While cool, it would prevent any clicks from registering on the entire site for the entire 5 second duration of the animation. I emailed the company to add `pointer-events: none;` to the confetti `div`. That fixed the problem.
Since the website had been around for a very long time, I wonder how many millions of seconds had been wasted on this animation to complete.
The "perception of speed" argument reminded me of when I was asked to add spinners and animations to a web app I was building, because without them the UI would have felt too fast and fake.
Thoughtful article. I read the introduction several times, picking it apart in my head.
> When done right, animations make an interface feel predictable, [...]
Predictable how? If you anticipate the animation, then you will have predicted it. But you also could anticipate the lack of an animation, and you will have predicated that.
> When done right, animations make an interface feel [...] faster,
Do they make the interface feel faster because no transition ever occurs in less time than the animation? Or is it that literal motion on the screen tricks us into thinking something is "going fast"? A nearly instantaneous, unanimated change in view must feel faster than an animation, no?
> When done right, animations make an interface [...] more enjoyable to use. [...]
This is true sometimes. It's particularly true when you're interacting with controls that have a "real physical world" analogy, like buttons, sliders, and page flips. On the other hand, if I click a button and a bunch of sparkles happen, that's not enjoyable to me.
> When done right, animations [...] help you and your product stand out.
If your product has animations and competing products do not, then yours stands out insofar that it has animations.
> But they can also do the opposite. [...]
Correct!
> So how do you know when and how to animate to improve the experience?
> Step one is making sure your animations have a purpose.
Or... don't use animations unless the app involves animation. Or do, there's nothing I can do about it.
old school bios/DOS interfaces are kings of usability to this day imo. sub 1ms latency, arguably even a little too quick - sometimes it feels like the interface changed right before my input.
Instead of trying to decide one animation speed for all things, the UI should be adaptive. The author stumbles onto this and walks right past it: whatever raycast is, they use it a lot, and find the animation (any animation) annoying.
The UI should learn the user's patterns: when they're new and unfamiliar, the animations are slower and more deliberate, instructional (initially including more information re: expected workflow). As the user "walks" a certain path again and again, every time more smoothly and confidently, the suggestions / assists / animations diminish, shorten, and disappear. For a pro user with muscle memory and memorized keystroke sequences, the UI does its best to just get out of the way.
YES. I love the examples here. The best one to me is the row background color transition on hover. It's painful, it feels like the UI is sluggish, when it reality it was someone going a little too hard on animation for no reason. Too often we think more animations = better.
I personally LOVE when the software I use has smooth animations. Telegram, Hyprland, GNOME, iOS, those are some examples of it. but apparently, I am the only person that cares about animations at all. I made a mockup of an app with quite a lot of animations, and asked random people what did they think about it. not a single person mentioned animations.
> How often users will see an animation is a key factor in deciding whether to animate or not.
That's the reason why I removed every animation in GNOME on my desktop. I also removed anything that morphs the screen into something else. For example, I don't use the activities screen. I jump to the other virtual desktops with hotkeys.
At least on desktop screens I think chronostasis might make animations seem more sluggish depending on where you looked before.
I wonder if this leads experienced users of the app in question to not like any animations, because they know click paths better and place their focus in an anticipatory manner.
Maybe one could measure click speed and reduce animation times based on that.
While animations in general may add juice they can also hide better ux, like the feedback button, it's one more click(actually two as it seems not to automatically focus on the textarea once opened) to send feedback. But the more years come by the more it looks being a choice to not have a great ux, in the case of the feedback button one might want to be sure the user intention is to send some
I think motion blur could enhance UI animations by making fast transitions feel smoother, even with the low number of frames the animation has to be rendered with. I wonder if this idea has been explored in mainstream UI frameworks, and if not, why - is it too computationally expensive, technically infeasible, or just a bad idea.
Android has really failed at this. Android apps are full of animations that serve no purpose or are even misleading, and slow down the experience. It's cargo cult copying from iOS. And the animations are janky, too.
Luckily Android has a developer option to double the speed of animations system-wide. It's the first thing I turn on every time I get a new phone. I find that double speed is about right. Designers tend to make every animation at least half as fast as it should be, to make sure you notice their effort.
One that gets me routinely is Android's two-stage quick control/notification drawer, which is further complicated by gesture-expandable notifications. It feels like a poorly thought out bodge to fit everything into a single screen. It’s annoying to me even as a software developer and must be terribly confusing to someone not well versed in the arcane incantations of mobile operating systems.
The two-swipe controls are truly evil and I can't believe it hasn't been fixed yet. The first screen shows you next to nothing if you have no notifications, which I never do.
Its a lot of work to get to quick control. The 4 they let you see on the first swipe is just not enough.
But wait, there's more! Even after the second swipe you have to swipe back and forth to get to all the controls.
But wait, there's more! In landscape mode the interface goes from difficult to downright infuriating.
I would say that the interaction is enabled by the animation. Without the animation it would be even more nonsensical than it already is and probably wouldn’t have been implemented.
There's an accessibility setting to disable all animations and the result is even better, it feels like living in a future where everything is instantaneous.
The one that bites me daily is in keeper. The web UI opens with icons collapsed, expanding after ?500ms?, right about when I want to click on a category to expand it, thus collapsing it again.
Absolutely right. I even find that 300ms in UI animations is still too long, but like TFA says, it depends on how often that piece of UI is used. Great Raycast example.
Good post with useful info. The author doesn't discuss it but I like the momentum inertia (aka spring animation) of the dropdown example - a nice touch.
not to nitpick because i mostly agree, but the second example (scaling a button on press/hold) is so ugly and weird that it comes across more like a glitch than an intentional animation. maybe it doesn't fit as well into a (post-)flat UI world but i always liked the bevel-shade-inversion technique of old MS Windows buttons to simulate pressing them "down".
Ethics and design guy here-- I think this is one of the most, "purposeful" articles I've seen in forever if you don't mind the pun. (I'm from Utah).
I'm asking myself the question of fundamentally why UI designers are making decisions to include the, "tasteful delay" and its ultimately as the article points out prioritizing, "delightful presentations" for, "tools that ultimately serve the users purposes most effectively." I don't think I have to preach to a converted choir here about that but I'm reminded of Thorstein Veblen's famous book and I wonder; at a deeper level isn't misanthropic to reduce software to, "tools?" Lumiere created motion pictures and we told stories. We invented the interactive motion picture and we jerry-rigged into an automated office suite. Outside of the very sexy Alan Kay-Dan Ingalls fringe computer interfaces of all stripes descended from that very idiosyncratic paradigm.
I wonder what crazy shit Ted Nelson is building with Claude right now. Sweet fuck.
> Another purposeful animation is this subtle scale down effect when pressing a button. It’s a small thing, but it helps the interface feel more alive and responsive.
If you haven't watched the Half Life documentary, I can't recommend it enough. In it Gabe Newell talks about the way he wanted the game to be different from games that came before it in that you could interact with things around you so you felt like you were actually in with and interacting with this world. He then related it to a psychological concept (maybe associated with self realization or external validation) and how as humans we crave the kind of physical objective feedback as recognition of our existence and how important and valuable that is. Really a neat idea and whether or not the science is sound, there is something immensely satisfying about interacting with virtual objects and having them respond in a physical manner that replicates physical reality.
If I could make one plea to people who program these systems, please take all necessary steps to prevent the following from occurring:
I find the button I need to press. I press it. The button animates to show it recognizes my action, but nothing else happens. I press it again and it works normally.
If only UX/UI people spent their time optimizing their code rather than polishing their animations.
Sorry for this rant, but hell, the web, the apps, everything is so sloooow and bloated. Make it instant! I just want to do my things, not to wait for drawings to draw!
Every time I see animation discussed by designers, they're thinking about it in terms of polish and "delight", and then balancing those things with perceptual latency. It's not entirely incorrect, but a couple of minor nits:
1. Delight is overblown, in my opinion. I think most of the people truly delighted by fancy animation are just other designers.
2. It's more useful to think about state when deciding when to animate. Could the user have trouble perceiving the change in state that just occurred? If so, then use an animation to help them visualize what happened. I believe this is the primary reason to use an animation - all others are vanity.
> Delight is overblown, in my opinion. I think most of the people truly delighted by fancy animation are just other designers.
If (and that’s a big if) animation is used in moderation only when it actually communicates something and isn’t an active impedence (as demonstrated in the linked post), I think it has a significant effect for users. It’s just not the effect that many might expect.
Meaningful, unintrusive animations are one of the myriad puzzle pieces that come together to form a positive impression. They’re a sizeable chunk of that last 20% that separates “good” and “excellent” in users’ minds. They’re not strictly necessary, but between two equally good competitors they’ll help one pull ahead of the other, because users come away with a stronger impression of “solidness”. It’s not unlike how people tend to consider heft and resistance to flexing as markers of higher quality in physical products.
The problem is that since a decade or so ago, UI design as a whole has veered heavily in the direction of vibes, slideshow wow factor, and “branding value” (I felt a pang of nausea just writing that) and away from the volumes of well-researched best practices, and regard for good use of animation has been lost along with it. We’re well overdue for a correction that pushes UI design back in the direction of practical usability and away from Dribbble appeal.
> users come away with a stronger impression of “solidness”
This really is what UI polish of any kind is all about. You feel like you can trust it more, it feels more robust and reliable. Animation and gestures are a part of this, but it’s only the last mile after everything already feels robust.
Before you make it more glitzy you have to make it less glitchy.
> Before you make it more glitzy you have to make it less glitchy.
I am copying this so that I can use it later when the marketing comes in and suggests we devote more dev time to yet another landing page renewal when we are at capacity just handling Bug tickets
That I can agree with. Applying polish to glitchy software is like putting a high end leather interior and soundproofing in a car that only starts 85% of the time and occaisionally opens its rear hatch while on the road for no apparent reason.
Or, more simply: "lipstick on a pig".
> occaisionally opens its rear hatch while on the road for no apparent reason.
That is how "our army of well trained monkeys" can get in to fix the "oops. something went wrong" problem.
#include <rant_about_paternizing_users.h>
> communicates something and isn’t an active impedence (as demonstrated in the linked post)
woah! you are starting from the point an individual preference is any metric to gneral public preferences and understanding... there's not a SINGLE study cited on the blog!
Fully agreeing with this. I was also surprised that the appearance change of a button on mousedown is considered an animation here. ("Another purposeful animation is this subtle scale down effect when pressing a button.")
Isn't this just very basic optical feedback to indicate that a component is clickable at all and that the click was registered?
It fits both the dictionary and colloquial definitions of animation. If there is any domain specific jargon, surely that applies too. I can't understand why this wouldn't be considered an animation...
I can see either side of it, but in my mind animation (in this context) means the generation and timed display of synthetic tween states to smooth the transition between the display of actual states. The mouse-down case is (in this context) an immediate change from the up- to down- states, without additional frames in between, so is not an animation by this particular domain-specific definition.
The example on the site does have tween frames: `transition-duration: .15s`
That makes sense. I think of it like visual movement, a difference in position over time. Even a single step represents a change in position, even if the time increment is very small. The transition is the animation, the duration would be 2 frames: up, and down.
In a nutshell: put two different frames in sequence, and you have an animation.
But the up and down really consists of two user actions, pressing the mouse button, and releasing it again. See drag-and-drop for example, where that distinction is important. It’s even important for simple buttons: You can generally abort a button press by moving the mouse pointer outside the button area before releasing the mouse button again. In that case, the button action isn’t triggered. The pressed-down state visualizes that the action will be triggered when you release the mouse button while still in the button area.
Animation is when more than one consecutive step happens on it’s own. I’d argue that even tooltips appearing and disappearing after a timeout doesn’t constitute an animation, because the disappearance isn’t immediately consecutive with the appearance, and (maybe more importantly) the intervening state of the tooltip being shown is meaningful to the user as a distinct state.
Why would it not be an animation?
It’s a pretty basic animation.
> Delight is overblown, in my opinion. I think most of the people truly delighted by fancy animation are just other designers.
Appreciating delight (for it's own sake) in software design I'd consider a core trait of (old-school?) Apple fans. E.g., lamenting the decline of whimsy in the post-Jobs era.
I don't know of a canonical piece that summarizes this idea, but it's referenced a bit in this short piece https://daringfireball.net/linked/2024/12/05/festivitas
I think there's truth to it being relatively niche, appreciating delight that is, but it's certainly not confined just to designers. E.g., like I'm saying here, a core trait of Apple fans is appreciating these kinds of details.
I should've been more specific. I was moreso referring to the trend of designers claiming they're adding delight, where in reality they're just muddying the experience with visual effects that might be striking, but lack any depth or improvement to the core experience.
I absolutely do believe that software can be delightful. Linear comes to mind as an example - there are lots of little nuances to their interactions and it just feels so good to use.
The other problem I encounter is designers working in B2B, but designing like they're working in B2C.
For B2B (especially enterprise B2B), your software is just a tool your customers' employees need for their day jobs. Fancy animations, multi-colored gradients (because gradients mean "AI" now, right), and other gaudy crap does not make it easier for anyone to do their job. It's just noise -- constantly distracting users who are just trying to navigate through dense, text-heavy dashboards.
If you want to design "pretty" and "delightful" experiences, then it doesn't make much sense to join a company that revolves around CRM/ERP workflows. Work for a company whose value is directly tied to users' warm and fuzzy feelings.
Also most consumers don't want to admire fancy animations. If they want to switch channels on their TV, they want the channels to switch now, not wait for a fancy animation to entertain them in the meantime.
Delight sounds similar to what game designers call "juice" and, done well, it really does make a game feel delightful beyond its pure gameplay.
I've had the same feeling with more utilitarian interfaces, but it's pretty rare. I don't know why. I expect it's partly because we have different expectations for programs than we do for games, partly because the context and the interactions are pretty different, and partly because most organizations do not have the will or the ability to make interfaces that satisfying. (After all, it's the worst sort of thing for most organizations: something that requires taste, time and experience and cannot be managed, measured or executed by committee.)
> 1. Delight is overblown, in my opinion
I might delight in seeing an animation the first three times, after that I want it off. Don't add extra latency to my process.
The author made that point, in considering frequency of use as a criteria for whether to use an animation or not.
Frequency often depends on individual use case, though. In an actual application, there are few elements where you can safely exclude the possibility that someone will use the element frequently.
I can tell you from experience that impressive hero banners and animations that get the user's attention reduce bounce rate. That might not matter if you're established and you get customers via product market fit and word of mouth, but for small shops trying to land early customers it's crucial.
It makes a significant difference if you’re talking about a web page that’s more like a product brochure, or if you are talking about an application the user wants to get a task done with. The latter shouldn’t have “impressive hero banners”, and “animations that get the user's attention” only when the user needs to be made aware of an important application event.
The assumptions buried here are that bounce rate is accurately measurable and that reduced bounce rate correlates to increased sales.
The buried assumption is also that increasing sales at all costs leads to increased profits long term.
> Could the user have trouble perceiving the change in state that just occurred? If so, then use an animation to help them visualize what happened
I think this is the only justified use of animation in UI, however I wasn't satisfied with the dilemma of increasing perceived transition while increasing perceived UI latency.
I found it's possible to get the best of both for event triggered state changes i.e clicking on stuff, by sticking to ease-out based transitions, where the start of the transition is instant and the end decelerates.
This makes it feel just as snappy as no animation, while still helping to communicate a transition, because we are more sensitive to the latency of the start of the transition when it's an event - since we are anticipating a reaction, which is satisfied as soon as it starts to react.
> Delight is overblown, in my opinion. I think most of the people truly delighted by fancy animation are just other designers.
I disagree with this, as much as I want it to be true. Just ask an Apple/iPhone user to use an Android phone for a week and then ask them how the experience was, they'll tell you something felt off or janky about it, and a lot of it comes down to really well designed animations on iOS for everything you interact with.
Regular consumers may not use the word delight to describe the user experience, but they do notice it when faced with what is (to them) an inferior experience.
Except "Reduce Motion" is one of the most well-known and praised setting, it has been passed on as a tip to increase the overall snappiness for as long as the setting existed.
To the point people regularly ask for a stronger setting to straight disable animations and not just reduce them.
I used to be a huge fan of disabled animations on Linux, but unfortunately many websites end up being completely unusable. Somehow the animations affect functionality. Probably the developers never test their software with disabled animations.
So now I just have the setting to be super fast, but not disabled. Works perfectly well.
Especially when I press the volume button, and it shows up rotated 90 degrees at a different side of the screen, or the litany of other iOS bugs..
This experience has stopped being the case for quite some time now. Sure, a 60 USD low-end device is no ground for proper comparison with a 1000 dollar one, but androids in a similar category absolutely have similar animations and "niceties". I have actually recently moved from iOS to Android, and I do prefer the latter's visual UX. I will even go as far and say that there are less UI bugs.
(As for "smoothness", sure, apple's SoC game is far above any android manufacturer's, which helps a lot)
>1. Delight is overblown, in my opinion. I think most of the people truly delighted by fancy animation are just other designers.
If you go in and read TFA you'll see that's one of the main points being made.
> Delight is overblown, in my opinion
Nerdsnipe perpetuated by other engineers/designers admiring it on Twitter. Nothing wrong with that, just shouldn’t pretend that most users care.
Most users don't know better. That doesn't mean you shouldn't aim higher.
Those designers aren't good at their job. What you're describing is a failed artist. There are a lot of these that call themselves designers.
Apple could learn a thing or two from this. Too often I'm waiting for their silly animations to finish. Just a moment ago I swiped to scroll the view to the bottom, then immediately tapped the button when it came into view, but I had to tap it multiple times until the bouncing stopped.
That's just one example because it just happened, but this happens ALL the time. I know Apple can do better. My Android phone felt so much more responsive (the 120hz screen helped, I'm sure), simply because the animations were snappier.
Other examples that come to mind real quick:
- Swiping up to switch apps. That one is awfully slow. (Actually, most gesture-based activities are painfully slow!)
- Dismissing notifications (esp. on Mac)
- Opening the drawer thing
- Revealing the dock
- Sometimes I see animations stacked upon each other. One animation has to fully complete, then another one, THEN I can finally use my computer again.
It's ironic that I have to go to Accessibility settings and disable these things to make my device accessible.
Whenever my apple wallet connects to my phone, It plays a totally useless animation that feels like it takes forever, and covers the entire screen. In that time, you cant see or do anything on the phone. So annoying, and for no reason. Just give me a little haptic when it connects.
This enrages me so fucking much.
When does my wallet slide slightly from the magnetic center and then back into place most often? When I’m getting it out of my pocket.
When am I trying to just use my goddamn phone the most? When I get it out of my pocket.
So, it ends up being that ~50% of the time I need to use my phone, I have to wait for that goddamn 3 second animation first.
If some engineer introduced a 3 second regression in the time for Face ID to unlock your phone 50% of the time, it would be noticed and fixed immediately. But call that 3 second regression a “surprise and delight animation” and suddenly Apple designers love it and force it on you.
same when attaching a locked phone to a magsafe charger. it seems like a small thing but i actually interact with my locked phone enough for that to get on my nerves. i'd prefer the haptic feedback but i would even settle for being able to swipe it away - nope. not an option.
You don’t have to wait for the iOS navigation animations to finish, they’re designed to be fully interruptible.
Not all of them. For example if you open a conversation in messages it slides left, and you have to wait before you can scroll. When you cancel a route in Maps it zooms back on your position and you have to wait before you can move the map again (and it’s really slow).
An extremely infuriating one that repeatedly gets me because I forget about it: the AM/PM wheel when setting an iOS alarm. If I set an alarm the night before and the last thing I do is flick the wheel to AM, but then hit save before the animation has finished it's very subtle and slight easing/bouncing animation, the setting remains at its original value (PM because I'm creating the alarm at night) and thus the alarm does not go off in the morning when I expected it to.
You're right, that one drives me nuts. Any slide wheel doesn't change its underlying value until it stops animating, even if it's 99% of the way there. You navigate away from the screen thinking the new value is set, but it's not.
That one falls into the category of UX felony as far as I'm concerned. It's not just delay or confusion, but actively misrepresenting a value.
the macos switching between spaces/desktops is INFURIATING, because until the animation fully finishes, all the clicks/keys are registered on the last space, and the animation takes a while...
apple have completely lost the plot, and organisations of that size are incapable of producing good user experience w/o a de facto dictatorship person who has an idea what here doing (a la steve jobs)
this is worsened by the the fact that even on hn people have no idea what's they're doing in terms of design most of the time, because they fail to realise that the average person isn't like a fan of their product lol, they just see it as a utility that needs to perform a bare minimum of functions reliably, with a consistent ui, like thats literally it...
every time you want to change something, ask yourself, if I show this to my grandma, and unless her reaction is "omg yes this is a million times better, pls do that" DO NOT CHANGE ANYTHING
I’ve tried to find a way to reduce or eliminate those workspace switching animations and have not found a solution. I will say that using a hotkey to access it makes it go the fastest compared to swiping, but that’s about it. There are more extreme solutions like Flashspace but it’s not the greatest.
it got on my nerves to the point i switched to https://github.com/nikitabobko/AeroSpace, lol. things like smooth scroll help you follow your place in the text (its something i cant live without, even in a tui editor). a fullscreen workspace switch should not need that.
> things like smooth scroll help you follow your place in the text
I dislike smooth scroll (and many other UI animations), but there are other things that might help, such as:
- Xaw scroll bars; click to scroll so that the clicked position is now at the top of the screen.
- Line numbers.
- Marker for bottom and top of previous scroll position, if what was previously on the screen is still visible.
smooth scrolling text is one of worst mistakes in UX
FYI there is a long-standing bug with ProMotion and switching spaces. Their length is tied to refresh rate somehow. Switching to static 60hz makes them faster (but what an annoying choice to have to make!)
iOS default animation speed is 350 ms, at least for SwiftUI. This has always felt a bit too slow. And recent system animation changes felt gratuitous to me (opening the action bar on iMessage for example).
OTOH this article is basically downstream of Apple’s interface design philosophy.
Ironically enough their HIGs used to tell you not to overuse animations, and to keep them short.
Personally I would even speed up these animations. 300ms is too high. I prefer animations that are almost imperceptible. You might even only notice them if you take them away.
Anything longer than that I consider too slow.
I used to go for 250ms, now I go for 200ms. I find that about the sweet spot for UI transitions where it helps you to understand what’s changing and how and why. And if it doesn’t meet those criteria, don’t transition it.
200ms is also nice and short to write in CSS, .2s. I contemplated shorter, but I found that by 150ms a transition can start to feel like it’s a mistake, a brief rendering glitch, especially if the first few frames of the animation are dropped, as can be common (.2s is already down to only ~10 intermediate frames). It’s too short to get the benefits of an animating transition, but too long to be or look or feel instant.
I think if the animation "helps you understand what's changing and why", sometimes that's a sign that the change could be redesigned - moved to a different part of the screen, for example - so that it becomes clearer without needing to be animated.
For example, if pressing a "Save" button makes a "Save successful" toast appear on top of the screen, it's tempting to animate it in, so that the user notices it. But it's better to replace the button text with "Saved" and gray it out, which achieves the same goal and feels great without any animation.
In general I think toasts are a borderline antipattern, particularly those presented as a chance for the user to undo some action that they accidentally triggered (doubling the panic since now the undo has become a time bomb). Just don’t make the consequencial action so easy to trigger in the first place and where relevant (on iOS or desktop) support the standard undo stack.
Toasts on large displays are definitely an anti-pattern, they're just too far from where the action that triggered them actually happened.
On mobile it's a bit different, because often you don't have the space to put an "undo" button or status text right next to the thing you just did. So you put it at the bottom or something in a toast.
Still not good, but more justifiable.
Also iOS does not have reliable undo actions. Android does, but on iOS there isn't an equivalent. No back button. Well, maybe a back button but definitely not required and not enforced in any way.
Still iffy on mobile because the way the device is being held can’t be assumed. The area the toast appears is very easily hidden by a hovering thumb for instance, especially for people with larger hands.
Undo and back are conceptually similar but different. On iOS, consistently anywhere you can enter text you can give your phone a quick shake (similar to a person shaking their head “no”) and it’ll offer to undo the last edit. Many apps like Reminders use this for actions like item completion too. There’s a native undo stack you can use to leverage this as a third party dev. There’s also a gesture that can trigger this but I have yet to commit that to memory.
Android does not have an undo gesture. Some skins (like Samsung’s) implement something similar but it’s not consistent and it’s limited to text editing.
For going back, all apps built with native iOS UI toolkits have a swipe gesture that goes back to the previous screen. Cross platform apps built with other frameworks are notoriously bad about not implementing this, though. It’s true that there’s no cross-app back gesture, but swiping back and forth on the home bar is a rough approximation.
IME it's the exact opposite. That iOS undo action is more or less theoretical - the apps that support that are some of Apples... And that's it.
The android back action is universally supported. Its literally a button, still, to this day, persistent on your screen by the OS.
Also, the "swipe back" action on iOS is more or less fake. Its applied so inconsistently it might as well not exist.
In my head "back" and "undo" are usually the same thing. iOS has a good interface, but this is one glaring blind spot they missed to Android and browsers. It actually makes iOS quiet frustrating to use.
Also, barely related: but the "shaking your device is like shaking your head no" thing is the stupidest thing I've ever heard in my life. I'm sure Apple thinks its very intuitive and good design, but it's really, really not. That's one of the least discoverable things I've ever heard. Apple please don't do that.
Swipe to go back support is pretty wide if you select for iOS-first apps (I do). It’s glaring when I try to use it and it’s not there, so when that happens I’ll either go find an alternative or drop back to the web app (where Safari will definitely implement it).
My Android devices all have the gesture bar enabled because the old style button bar is an eyesore and easy to trigger accidentally (Android’s swiping from the right to go back is also too easy to trigger as a right-handed person, but that’s another story).
My metal model for the undo/back split actually follows desktop browsers. Cmd-Z isn’t going to undo navigation while Cmd-[ will, and so the two are separate and distinct.
With saving, I usually add a confirmation directly next to the save button, so the save button itself doesn't change state (people often like pressing save multiple times!). But even then, I find a little bit of animation that moves the "saved" text away from the button to indicate where it's come from can be really helpful for intuitively connecting the two interactions. The animation should be fast (100-150ms max, often as low as 75ms), and subtle (just a slight step to the side), but it gives the user more of a feeling about what's happening.
> With saving, I usually add a confirmation directly next to the save button, so the save button itself doesn't change state (people often like pressing save multiple times!).
There is no problem with the button changing states as long as it only happens after the current document state was successfully saved and becomes active again when you make changes to the document. That way the button doesn't represent the outcome of some action but the sate of the document - unsaved changes = button enabled, no unsaved changes = button disabled.
The toast doesn't block the user from saving again in quick succession
First thing I do on any android phone is enable developer mode and double the speed of animations. Drives me crazy when I see one running them at normal speed!
There's an accessibility setting to disable animations altogether. It's paradise.
I feel like web design animations are more similar to PowerPoint than folks want to admit. What I mean by that is that quick cross-fades can be used 99% of the time to tidy the look of UI but you rarely need to do anything beyond that.
>> This animation explains how Product Intelligence (Linear’s feature) works. We could have used a static asset, but the animated version helps the user understand what this feature does, straight in the initial viewport of the page.
That might be the designers intent, but that's not what it does for me at all. First, the animation shown is on some weird 3D angle which is not part of any sane UI. Why is that? Not to convey anything about the actual experience of the app shown. That 3d look certainly does not "help the user understand what this feature does"
The fade-in of the animation seems to draw me in to that area of the page which I assume is the intent. The 3D perspective helps me understand that the text in that box is not part of the page I'm reading, but a view of something else - their product. But it doesn't really help me to understand the product.
My rule of thumb: if the user has to wait for the animation to play out, before they can continue, remove it.
And, always provide an accessibility option to turn off all animations.
Worth noting, the prefers-reduced-motion media query is great for this:
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
Interesting. Apparently browsers (at least Firefox) uses the OS' setting for this. I still have animations enabled in Windows 10 due to how windows are rendered when they are opened, but the content isn't painted yet.
However, there seems to be way to set this manually in Firefox. [1] Go to about:config and add `ui.prefersReducedMotion` set to `1`. Can be verified with https://animate.style
[1] https://stackoverflow.com/a/59709067
Here's a subtle problem: An animation that looks "delightful" on the screens you have, might look pretty bad on a screen you don't have. For example, the author's animation for scaling a button looks fine on my M1 MacBook Pro, but jittery and sluggish on the crappy IBM ThinkVision monitor attached to my MacBook. See for yourself:
MacBook: https://drive.google.com/file/d/1UjJnxobPlBh_nv18Ych0XHwHEMw...
Crappy Monitor: https://drive.google.com/file/d/1jtwJKIFvteLOWD1Pzj1mTZjQwVX...
Are you using your IBM at its native resolution?
Does it matter? Some users will perceive it this way (or better or worse).
It matters if you want to attribute the problem to the correct source.
> But they can also do the opposite. They can make an interface feel unpredictable, slow, and annoying.
Indeed, just like the immediately following example, which slows down page scrolling, breaking predictability and consistency of one of the most frequently used and fundamental page operations
And its purpose is, of course, only fulfilled in the imagination of the designer
> This animation explains how Product Intelligence (Linear’s feature) works. We could have used a static asset, but the animated version helps the user understand what this feature does, straight in the initial viewport of the page.
It doesn't really do that: first, it's happening partially out of focus because I read top to bottom, so I'm still reading your title and leading paragraph, or did you want me to be distracted and skip the text? So I see the same thing on first focus: static image. And I can't rewind it to watch again since I missed it the first time.
Then it has a very weird angle which makes all the text harder to read, my guess is to help see the 3D nature of the animation when to show the arrival of the product as a separate overlay? So this would likely not exist in a static image and be an improvement.
One thought about this section:
> To give you an example, a faster-spinning spinner makes the app seem to load faster, even though the load time is the same. This improves perceived performance.
Perhaps due to poor design by companies that abuse the fast loading spinner when, in fact, nothing is happening, I instinctively trusted the slower spinner more.
The only thing that I trust is loading bars that make nonlinear progress, clearly indicating that there's specific steps and/or measurable progress happening.
my first instinct was "the slow one is struggling so it must be doing some heavy work"
Android 16 just introduced a stupid animation when unlocking your phone. Rather than show you what you want to see as fast as possible, the designers decided you would have to sit through watching their fade in animation dozens of times a day.
Designers either don't use their own products, or have no taste (possibly both).
You can disable animations in Android in the accessibility settings. Not just make faster but completely disable. That's one of the reasons I'll never go to iOS. I can't stand losing time on pointless UI stuff. Wasting my time isn't delighting at all.
Great tip. I had the "Remove animations" setting feature enabled. Hopefully it's just a temporary bug that this doesn't disable the lockscreen animation.
One thing that instantly ruins my day is animation where the element state is inconsistent during the animation.
For example - I think it's on Windows where I keep running into this - on notification popups from some apps, you can't click "X" to close until sufficient time has passed after the popup animation. If you try to close it in that time, it instead acts as if you clicked the notification to open it. Super annoying.
Another, on Mac, when switching desktops, sometimes an app will show on the screen briefly before flashing to another app. The animation is slow enough that it often tricks me into thinking it's ok to do stuff and then nope the app changes. Even worse, I think it occurs randomly.
Note to designers: if you do choose to include an animation, it better be the most rock solid implementation ever or I will immediately think you're a twat and your app is a buggy pile of crap.
I'm a big believer that animations need to validate what you already know, they aren't the information itself.
This means, if you turned animations off you would still work as fast and understand the flow the same as if animations were enabled.
For me, the purpose of animations is to soften the UX journey, and to confirm what I already knew, by giving me small indications that yes, the UI is truly in the state I expect it to be.
Such as fast highlighting of on hover items, so I don't have to correlate the mouse position to the control.
I love that example of tool tip popups taking 0ms once you have popped up one, that is a clear signal that the UX understands you are trying to learn more about the controls you're hovering over.
That's a perfect representation of how animations signal understanding of your UX journey.
Clickbaity title; more like "things to consider when designing animations."
I appreciate subtle animations like the button press. Visual feedback gives me confidence in UI actions and makes things less jarring. Same idea with CSS smooth scroll.
But a lot of this feels subjective. Anybody have user studies on the effectiveness of UI animation?
Also, I think a lot of people would be happier if web apps exposed settings like zero animation / mild animation/ full animation. Power users could speed up their workflows by turning off animations. Kinda like my phone UI settings.
> Also, I think a lot of people would be happier if web apps exposed settings like zero animation
This exists as a browser setting, it's called "prefers-reduced-motion", an example usage in my code: https://github.com/mickael-kerjean/filestash/blob/master/pub...
That is very not-enough, as it is literally "prefers reduced" but i need (not prefer) zero animation. And yet with this present several years already websites just happily ignore the setting. So i believe this should be honored by browsers which should just stop animating transitions. But then there is the other elephant in the room (JS anims).
It might be kind of interesting to see a well-done usability study around animations. I tend to assume they are pretty useless, but I guess I can see some point in drawing the eye from a button you press, to some UI component that it generates.
OTOH, it isn’t clear what the baseline should be. The easy way to do an incorrect study would just be to toggle off animations and have the very dynamic design with components popping into existence without any hints. But, that’s flawed, a UI made from the ground up with the assumption of “no animations” should just be less dynamic, rendering the whole concern moot…
In my opinion the bare minimum for UI animations is where a large percentage (30%-40% or above) of the screen changes. This kind of thing doesn’t faze even moderately advanced users, but for many below that level it’s confusing because there’s not necessarily anything that ties the two UI states together.
Hmm. That isn’t my preference—animation is best used to draw attention to something where I might noticed the cause-and-effect. If nearly half of the screen has changed after I hit a button, I hope to notice that!
Like I said, there’s a split between those who are and aren’t technically inclined.
The issue for non-technical users is that without an in-between state, UIs can be confusing because it’s not clear what triggered the dramatic change. If we take a typical mobile app as an example, the animations that occur when a user drills down communicates a couple of things:
- The list item in the screen being pushed out of view maintains its pressed-down highlighted state through the transition, making it clear what was tapped to trigger the action
- The horizontal animation of the following screen pushing the previous screen out of view makes it clear that the how the two screens are connected and that the user is traversing a hierarchy, similar to going through a series of doors (which in turn, communicates how to get back out)
Similar principals apply to sheets/drawers animating in. Without this animation, it can be unclear if the screen appeared as the result of a user action (and if it did, what action) or if the app just did it of its own volition.
I am pretty anti-animation, but you make the point well. Animation allows apps to be more featured, using animation to help new users follow what's happening. As long as it can be turned off, experienced users benefit from the extra features. I had never thought of it as a learning aid, rather just an unnecessary distraction to make the app look cool.
I wish more designers thought this way.
I have a blog post draft called, “5 principals of interactive animation” aping the “12 principles of animation” from the 80's that I thought every would-be UX designer might learn from. It mirrors a lot from this post!
1. Purpose over ornament.
2. The more often, the less.
3. Timing shapes perception.
4. Motion adapts to state.
5. Silence is an option.
UI animations actually do have one valid use: clarifying UI state changes to third parties.
When you're the only person using the computer, UI animations are pure time-wasting anti-features. You obviously know how the UI state changed because you're the one who requested the change. If the UI state changed without your explicit request, that's a bug that needs fixing. But somebody viewing your screen remotely can't see which keys you're pressing, and they don't know what you intend to click on before you've actually clicked it, so to them UI state changes can be surprising. Animations can help them follow what's happening.
Of course, animations should be disabled by default, because most computer use is not performed for an audience, but having the option to enable them is occasionally useful.
> You obviously know how the UI state changed because you're the one who requested the change.
We must be using different devices because mine often fail to register my intent and in that case the failure to animate is often the only signal I have (that doesn't take more than a few seconds to register)
I use keyboard and mouse. Unlike touchscreens, these always work reliably.
And if you're using animations as indications of correctly functioning hardware, why not just use useful work as the indication instead?
Useful work takes longer to do than the animation that indicates the work has been queued.
None of the animations described in the article are of this type. Opening a text input area or changing desktop should be instant on all modern hardware. If you genuinely have something that can't be accomplished within one frame it's acceptable to display a progress bar, but I don't consider progress bars to be a "UI animations".
I have a problem with animation every time it induces latency. It's okay to animate some action that would take that much time anyway, but waiting for purely cosmetic animation to finish feels sluggish and not enjoyable.
Yes, animations are fine for things like progress bars, where they visualize something happening without interfering with user actions. But otherwise, animations should be avoided, or limited to something like 100ms.
Whoever designed the keyboard animation for Walmart self checkouts should take note.
Every time you want to type in a product by name, you must endure a 2 second slide-in of the keyboard before you can start typing on it. It's so slow that I feel that I could have completed the search and started on the next item before it's even done animating, if there was a way to disable it.
I sincerely hope employees don't have to use systems like this all day that reduce their throughout by more than half.
I remember early in my career I was working for a consultancy and the user was complaining that the search results were slow, our tech manager just LOVED this problem, in his mind he would get to go down the search engine rabbit hole - analyse the search query, maybe theres a more advanced indexing algorithm that he could find to speed it up, this could take weeks of benchmarking and comparing and prototyping and everything, what a wonderful rabbit-hole where the first prize is a happy client because of his algorithmic genius!
But me, being a bit more pragmatic, instantly benchmarked it, saw the search backend was responding quickly and it was just the animating menu that showed the results that was slow to animate. I changed 1.6 second animation to a 0.2 second animation, a change that look maybe 5 minutes to benchmark, find the code, and then change it,
The tech manager refused to accept that the solution was that simple, and only confonted with irrefutable evidence (direct client feedback AND benchmarks that showed that the search backend was already fast) that he accepted.
This recently happened to me when I was using an online website for preparing for a drivers license test. After finishing a 20 question practice test, the site would show a cool confetti animation on top of everything. While cool, it would prevent any clicks from registering on the entire site for the entire 5 second duration of the animation. I emailed the company to add `pointer-events: none;` to the confetti `div`. That fixed the problem.
Since the website had been around for a very long time, I wonder how many millions of seconds had been wasted on this animation to complete.
The "perception of speed" argument reminded me of when I was asked to add spinners and animations to a web app I was building, because without them the UI would have felt too fast and fake.
Thoughtful article. I read the introduction several times, picking it apart in my head.
> When done right, animations make an interface feel predictable, [...]
Predictable how? If you anticipate the animation, then you will have predicted it. But you also could anticipate the lack of an animation, and you will have predicated that.
> When done right, animations make an interface feel [...] faster,
Do they make the interface feel faster because no transition ever occurs in less time than the animation? Or is it that literal motion on the screen tricks us into thinking something is "going fast"? A nearly instantaneous, unanimated change in view must feel faster than an animation, no?
> When done right, animations make an interface [...] more enjoyable to use. [...]
This is true sometimes. It's particularly true when you're interacting with controls that have a "real physical world" analogy, like buttons, sliders, and page flips. On the other hand, if I click a button and a bunch of sparkles happen, that's not enjoyable to me.
> When done right, animations [...] help you and your product stand out.
If your product has animations and competing products do not, then yours stands out insofar that it has animations.
> But they can also do the opposite. [...]
Correct!
> So how do you know when and how to animate to improve the experience?
> Step one is making sure your animations have a purpose.
Or... don't use animations unless the app involves animation. Or do, there's nothing I can do about it.
old school bios/DOS interfaces are kings of usability to this day imo. sub 1ms latency, arguably even a little too quick - sometimes it feels like the interface changed right before my input.
Instead of trying to decide one animation speed for all things, the UI should be adaptive. The author stumbles onto this and walks right past it: whatever raycast is, they use it a lot, and find the animation (any animation) annoying.
The UI should learn the user's patterns: when they're new and unfamiliar, the animations are slower and more deliberate, instructional (initially including more information re: expected workflow). As the user "walks" a certain path again and again, every time more smoothly and confidently, the suggestions / assists / animations diminish, shorten, and disappear. For a pro user with muscle memory and memorized keystroke sequences, the UI does its best to just get out of the way.
YES. I love the examples here. The best one to me is the row background color transition on hover. It's painful, it feels like the UI is sluggish, when it reality it was someone going a little too hard on animation for no reason. Too often we think more animations = better.
I personally LOVE when the software I use has smooth animations. Telegram, Hyprland, GNOME, iOS, those are some examples of it. but apparently, I am the only person that cares about animations at all. I made a mockup of an app with quite a lot of animations, and asked random people what did they think about it. not a single person mentioned animations.
> How often users will see an animation is a key factor in deciding whether to animate or not.
That's the reason why I removed every animation in GNOME on my desktop. I also removed anything that morphs the screen into something else. For example, I don't use the activities screen. I jump to the other virtual desktops with hotkeys.
At least on desktop screens I think chronostasis might make animations seem more sluggish depending on where you looked before.
I wonder if this leads experienced users of the app in question to not like any animations, because they know click paths better and place their focus in an anticipatory manner.
Maybe one could measure click speed and reduce animation times based on that.
While animations in general may add juice they can also hide better ux, like the feedback button, it's one more click(actually two as it seems not to automatically focus on the textarea once opened) to send feedback. But the more years come by the more it looks being a choice to not have a great ux, in the case of the feedback button one might want to be sure the user intention is to send some
I think motion blur could enhance UI animations by making fast transitions feel smoother, even with the low number of frames the animation has to be rendered with. I wonder if this idea has been explored in mainstream UI frameworks, and if not, why - is it too computationally expensive, technically infeasible, or just a bad idea.
Android has really failed at this. Android apps are full of animations that serve no purpose or are even misleading, and slow down the experience. It's cargo cult copying from iOS. And the animations are janky, too.
Luckily Android has a developer option to double the speed of animations system-wide. It's the first thing I turn on every time I get a new phone. I find that double speed is about right. Designers tend to make every animation at least half as fast as it should be, to make sure you notice their effort.
One that gets me routinely is Android's two-stage quick control/notification drawer, which is further complicated by gesture-expandable notifications. It feels like a poorly thought out bodge to fit everything into a single screen. It’s annoying to me even as a software developer and must be terribly confusing to someone not well versed in the arcane incantations of mobile operating systems.
The two-swipe controls are truly evil and I can't believe it hasn't been fixed yet. The first screen shows you next to nothing if you have no notifications, which I never do.
Its a lot of work to get to quick control. The 4 they let you see on the first swipe is just not enough.
But wait, there's more! Even after the second swipe you have to swipe back and forth to get to all the controls.
But wait, there's more! In landscape mode the interface goes from difficult to downright infuriating.
Those interactions are kind of annoying but not because of animations.
I would say that the interaction is enabled by the animation. Without the animation it would be even more nonsensical than it already is and probably wouldn’t have been implemented.
There's an accessibility setting to disable all animations and the result is even better, it feels like living in a future where everything is instantaneous.
The one that bites me daily is in keeper. The web UI opens with icons collapsed, expanding after ?500ms?, right about when I want to click on a category to expand it, thus collapsing it again.
Absolutely right. I even find that 300ms in UI animations is still too long, but like TFA says, it depends on how often that piece of UI is used. Great Raycast example.
Good post with useful info. The author doesn't discuss it but I like the momentum inertia (aka spring animation) of the dropdown example - a nice touch.
not to nitpick because i mostly agree, but the second example (scaling a button on press/hold) is so ugly and weird that it comes across more like a glitch than an intentional animation. maybe it doesn't fit as well into a (post-)flat UI world but i always liked the bevel-shade-inversion technique of old MS Windows buttons to simulate pressing them "down".
Ethics and design guy here-- I think this is one of the most, "purposeful" articles I've seen in forever if you don't mind the pun. (I'm from Utah).
I'm asking myself the question of fundamentally why UI designers are making decisions to include the, "tasteful delay" and its ultimately as the article points out prioritizing, "delightful presentations" for, "tools that ultimately serve the users purposes most effectively." I don't think I have to preach to a converted choir here about that but I'm reminded of Thorstein Veblen's famous book and I wonder; at a deeper level isn't misanthropic to reduce software to, "tools?" Lumiere created motion pictures and we told stories. We invented the interactive motion picture and we jerry-rigged into an automated office suite. Outside of the very sexy Alan Kay-Dan Ingalls fringe computer interfaces of all stripes descended from that very idiosyncratic paradigm.
I wonder what crazy shit Ted Nelson is building with Claude right now. Sweet fuck.
https://moglen.law.columbia.edu/LCS/theoryleisureclass.pdf
> Another purposeful animation is this subtle scale down effect when pressing a button. It’s a small thing, but it helps the interface feel more alive and responsive.
If you haven't watched the Half Life documentary, I can't recommend it enough. In it Gabe Newell talks about the way he wanted the game to be different from games that came before it in that you could interact with things around you so you felt like you were actually in with and interacting with this world. He then related it to a psychological concept (maybe associated with self realization or external validation) and how as humans we crave the kind of physical objective feedback as recognition of our existence and how important and valuable that is. Really a neat idea and whether or not the science is sound, there is something immensely satisfying about interacting with virtual objects and having them respond in a physical manner that replicates physical reality.
oh the policing of blog titles now, can't wait for an AI to neutralize any post that would otherwise stand out unfairly on HN's first page
If I could make one plea to people who program these systems, please take all necessary steps to prevent the following from occurring:
I find the button I need to press. I press it. The button animates to show it recognizes my action, but nothing else happens. I press it again and it works normally.
I really hate that.
Yells at cloud with visions of Windows 98 menu slide out animations stuttering on the barely good enough for the new OS pc! ;-p
If only UX/UI people spent their time optimizing their code rather than polishing their animations.
Sorry for this rant, but hell, the web, the apps, everything is so sloooow and bloated. Make it instant! I just want to do my things, not to wait for drawings to draw!
Am I the only one who dislikes off-angle animations?
No, you're not.
Frontend design is looking more and more like a jobs program at worst, and at best cost allocation justification.
I already foresee a lot of people jumping on me for this, so do your worst, nerds.
> Frontend design ...
UI frontend design*
maybe they never tried a TUI
TUI is the superior choice.