Why Linear Timeline Animations Fail in Product UI

What a linear timeline assumes

A linear timeline animations model assumes a known beginning, a known end and a fixed duration between them. That is the right model for a title sequence, an explainer or a marketing loop. It is a poor model for a button that can be pressed twice, a drawer that can be dragged back before it opens, or a form that moves from idle to loading to error while the user keeps typing. The timeline describes playback, not behaviour.

Failure 1: users interrupt the motion

People do not wait for an animation to finish before they act again. They tap the close button while a sheet is still opening, reverse a swipe halfway through, or hover away before a tooltip settles. A timeline that restarts from frame zero on every change feels disconnected. A transition that can be redirected from its current position and velocity feels physical. Apple's interface guidance calls this interruptibility, and it is a core reason its motion model is built around springs rather than fixed playback.

Failure 2: product states multiply

A single component can be idle, hovered, pressed, loading, successful, failed, disabled or cancelled. Each combination may need a different visual result. A timeline can hold a separate animation for each state, but the logic that chooses between them still has to live somewhere. When that logic is a set of boolean flags in component code, impossible combinations appear: a spinner and an error message at the same time, or a success check while a retry is still running.

• A timeline answers what the motion looks like, not which state is valid
• Every new state adds another clip and another hand-written condition
• Interruptions expose transitions the timeline never described
• The same interaction gets rebuilt differently on each platform

Failure 3: input carries velocity

A fixed ease curve ignores how fast the user was moving. A slow drag and a fast flick should not settle the same way. Springs can accept the gesture's velocity as an input, so the motion continues from the user's hand instead of restarting from a canned curve. That is why gesture-driven interfaces tend to use spring physics for the parts a person can grab, and timelines only for sequences nobody is touching.

When a timeline is still the right tool

Timelines are excellent for non-interactive sequences: product films, onboarding illustrations, animated diagrams and exportable video. They are also useful inside a state, for example a celebratory burst that plays once after a successful action. The mistake is using a timeline as the whole interaction model. Use it for the performance, and use states for the decisions around it.

What to use instead

Put the logic in a state machine and the feel in springs. The state machine names the valid states and the events that move between them. Springs handle position, scale and opacity so the result survives interruption. If the animation has to ship to more than one platform, keep that model in a file the runtimes can read instead of rewriting the same conditions in React, SwiftUI and Flutter. If the logic already lives in application code, a code-first state machine is the simpler choice.