Motion Design Principles for Product Interfaces
We treat every animation as an answer to a question: where did this element come from, and where is it going? A card that appears instantly in a new position forces the user to reorient themselves from scratch. A card that visibly slides or scales from its origin point lets the eye track the change instead of re-scanning the whole screen. That single rule has driven most of our motion decisions across client apps.
Duration matters more than easing curves in practice, even though easing gets more attention in design discussions. We settled on a rough house rule: 100–150ms for small state changes like a toggle or checkbox, 200–300ms for elements entering or leaving the viewport, and anything longer needs a specific justification. On one fintech dashboard, a designer had set modal transitions to 400ms because it 'felt premium' in isolation — in actual use, tapping through five modals in a row felt sluggish, and we cut it to 220ms.
Motion is also an accessibility feature we underused for a long time. Users with vestibular disorders can be genuinely harmed by large-scale parallax or spring-heavy animations, so every product we ship now respects prefers-reduced-motion at the OS level, swapping slides and springs for simple opacity fades. This isn't a nice-to-have layered on afterward; it has to be built into the animation system from the start or it never gets retrofitted.
The failure mode we see most often in client handoffs is animating things that don't need it — page transitions, tooltips, list reorders — until the interface feels busy rather than responsive. Our rule of thumb is that motion should clarify a cause-and-effect relationship the user just triggered. If nothing changed as a direct result of user input, it usually doesn't need to move.
