In most apps, transitions like these tend to be painfully slow. A 300-millisecond transition animation blocks the user just like a blocking system call stops a running process; it forces them to do nothing but stare at your animation, because they can't read or target any UI elements until they've stopped moving.

You wouldn't randomly put "usleep(300000)" in your programs, so why punish your users by blocking them in the same way?

Yes, I understand that it's pretty. But often, I think, as designers we can be so enthralled by the beauty of our creations that we appreciate them as art and forget the perspective of a user who is simply trying to find the answer to a question or get something done.

In the vast majority of situations, no transition is necessary. As a user, I don't want to wait 300 ms to do the next thing. Don't make me wait. If I must wait, keep the delay under 100 ms so that the system feels responsive.

This is Webflow, a website building tool, so its design choices have a bigger impact; they affect the design of many websites. I would argue against making it trivially easy for website designers to force their users to wait. If the user really does want a transition, use a shorter default duration, like 100 ms.

My rule of thumb is that animation is something you only add to your designs when it's already good, and when you really know what you're doing.

If you're relying on animations to hide jankiness or spruce up a design it's probably not going to work. If anything, it will probably make things worse. For example a delayed response to an interaction feels like a slow application, not a smooth one. This is especially true on the web where many animations run on the main thread and compete for resources with whatever is causing slowness.

Wow. I rejoice that someone is passionate about this UX finery.

Because I'm found at the far end of the stack.

My main takeaway is "make the whole thing clickable" as several of the animations show missed clicks trying to find the invisible click boundary.