Interaction becomes inconsistent when every team invents it one screen at a time.
I treat feedback, motion, and state changes as part of the component, not decoration added at the end.
Write the behaviour first
Before animating, I write a small state table. It covers the trigger, response, completed state, failure state, and reduced-motion option.
For a multi-selection control, I define how an item is selected, how it is removed, where focus stays, and how the change is announced. Motion supports that behaviour. It does not define it.
On a global automotive design system, we used shared motion roles such as fast, standard, and emphasised. Designers chose a role based on the interaction. Developers got the exact duration and easing from a token instead of estimating it from a prototype.
Each component specification recorded the property that changes, its start and end state, the motion role, and the reduced-motion behaviour. That made the interaction repeatable beyond the original screen.
I then review it in a working component. I test keyboard use, repeated actions, slow loading, errors, content changes, and the operating system’s reduced-motion setting.
We keep those states in Storybook so product teams can inspect the behaviour before building their feature.
The result is simple. Teams reuse the same behaviour instead of recreating it screen by screen.