The productive lie
A network request takes time. A database query takes time. Rendering a new view takes time. The question is never whether the gap exists; it is whether you show the gap as a gap or use it for something.
This is where transition animation earns a specific, functional justification that has nothing to do with delight or brand personality. When a user taps a card and the new screen slides in over roughly two hundred milliseconds, the interface is not decorating the experience — it is consuming dead time that the system needed anyway. The animation and the fetch run in parallel. If the fetch completes before the transition ends, the content appears to have arrived instantly. If it runs long, a skeleton or placeholder is waiting, already in frame. Either way, the hard stop — the blank screen or spinner — is gone.
This is sometimes called perceived performance, and it is one of the few places where motion and usability research point clearly in the same direction. Human temporal perception is not linear: a delay obscured by continuous movement feels shorter than the same delay served plain. Rail guidelines from Google's performance work, and earlier research into animation at the Human Interface level from Apple's original iOS frameworks, both converged on the same practical window: transitions that complete between one hundred and three hundred milliseconds feel responsive; much shorter and they read as glitch; much longer and the user stops believing the system is doing anything.
The discipline, then, is in matching transition duration to realistic latency. A local operation that takes thirty milliseconds does not need a two-hundred-millisecond slide to cover it — that transition becomes the movement nobody asked for, pure overhead dressed as feedback. But a cross-network content load almost always has a gap worth filling, and a well-timed transition fills it without asking the user to notice.
The honest version of this technique requires knowing your actual latency numbers per interaction type, not applying a single easing curve to everything in the system. It also requires resisting the temptation to add motion to operations that are already fast, because animation on a snappy action creates the impression of slowness where none existed. Cover the wait that exists. Don't manufacture a wait to justify the cover.