seenry-motion
Seenry Motion
Motion exists to explain a change: where something came from, what the input did, what state the interface is in now. Build every animation through the sequence below, in order; steps 1 and 2 decide whether any code gets written at all.
Make the call and state it in one line; do not offer a menu of motion options. Extend the project's existing motion tokens and components instead of adding a parallel set.
The build sequence
1. Should it animate at all? Decide by frequency.
| How often people see it | Decision |
|---|---|
| 100+ times a day (command menu, keyboard shortcuts, list navigation with arrows) | No animation. Instant. |
| Tens of times a day (hover, tabs, toggles) | Brief opacity/color feedback on the existing state clock, or nothing; never delay the accepted state |
| Occasionally (menus, dialogs, sheets, toasts) | Standard motion from the table below |
| Rarely (onboarding, first success, empty-to-full moments) | Room for character |
Keyboard-triggered actions never wait on animation. If the gate says no, say so and ship the instant state change.
2. Name the purpose in one word: feedback, orientation (where it came from or went), state, continuity (avoid a jarring jump), explanation (marketing and onboarding only), or delight (rare moments only). No purpose, no animation. Data people are reading never moves for style.