Interface · 21 April 2026
Use motion for state, then stop

A block fading up as it scrolls into view is about the easiest motion to add, and I find it the hardest to defend. It doesn't tell me anything I couldn't already see. By the third section I'm not watching the effect any more, I'm waiting for it.
When I do use motion, it's tied to a change of state. A panel opened. A result arrived. A save failed. A row slides into focus, or the active line in a list moves. Take the movement away and you lose part of the explanation.
I also check every animation with reduced motion switched on. The page still has to read properly with the movement gone, so the order, the hierarchy, and the words carry the meaning. Animation is a second channel, never the only one.
Continuous motion can earn its place when the content really is a sequence, like a strip of names or a rotating focus. Even then it should be slow enough to read and should pause when someone settles on one item. If it can't be stopped, it's a screensaver.
Inside a product I'm stricter. A chart that updates because the data changed is useful. A chart that moves because the page felt quiet comes out.
More insights
- Design the failed login path firstEngineering
- Connect the model to a real systemAI
- Agree what a finding is before building the dashboardInfrastructure
- Write the empty state before the full oneEngineering
- Leave a handoff the next developer can useEngineering
- Give an agent a boundary people can seeAI
- Build a company site for the next page, not the firstInterface
- Show the feed that stopped reportingInfrastructure
- Design for the return visit firstInterface