# Designing Interfaces That Respond Naturally > A practical take on UI motion: remove animation first, keep what explains layout, feedback, state, or origin, and cut anything that only looks polished. Canonical HTML: https://www.edwinvakayil.info/writings/designing-interfaces-that-respond-naturally Markdown mirror: https://www.edwinvakayil.info/writings/designing-interfaces-that-respond-naturally.md Author: Edwin Vakayil Published: 2026-01-10 Updated: 2026-08-10 Reading time: ~6 min Topics: UI animation, micro-interactions, interface design, UX motion, frontend, usability, prefers-reduced-motion ## Subtitle Start with no motion at all. Add only what makes each change easier to understand. ## Outline - Motion that explains a layout change - Feedback should be felt, not watched - State changes need continuity, not ceremony - Show where something came from - When motion gets in the way - A few craft defaults I trust - A simple rule for deciding whether to animate - Motion should have a job ## Interactive demos on the page - Accordion: without motion vs with motion - Button: Action Only vs Action + Feedback - Switch: Instant State Change vs Smooth State Change - Tooltip: instant feedback vs Guided feedback - Select: slow 900ms vs instant feedback ## Article Before I animate anything, I try the interaction with no motion at all. If nothing becomes harder to understand, the animation was never doing real work. That test has saved me from more decorative transitions than any motion guideline ever has. Useful motion has a job: it gives context, confirms an action, clarifies a state change, or shows where something came from. If it only looks polished, cut it. Motion that explains a layout change Accordions make the point quickly. Without animation, content appears and the page jumps. With a short expand, the section you clicked becomes the origin of the change, and the rest of the layout follows. Both versions are usable. The animated one is easier to follow because it explains the transition instead of forcing you to re-parse the new layout instantly. That is the bar I use for layout motion: does it reduce surprise, or does it just delay the inevitable? Feedback should be felt, not watched Buttons are different. You already know what a click does. What you want is confirmation that the interface registered it, especially when the real result takes a moment. A slight press is enough. If the motion is more noticeable than the action, it is competing with the task. Good micro-interactions disappear into the feel of the product. If someone compliments the animation, I usually made it too loud. State changes need continuity, not ceremony A switch is an explicit state change. Instant jumps work, but a short travel between positions makes the before and after feel connected. I would rather ship a slightly dull switch than one that turns every toggle into a ceremony. Continuity helps; performance theater does not. The same idea applies to tabs, checkboxes, selected rows, and filters: animate the relationship between states when that relationship matters. Skip everything else. Show where something came from Tooltips are easy to over-design and easy to under-connect. An instant tooltip is readable, but a quick fade with a slight move from the trigger makes the source feel obvious. Keep it small. The job is association, not entrance choreography, especially in dense UIs where icons lean on tooltips for meaning. When motion gets in the way If the interaction is already obvious, motion is often just latency with better branding. Try the same control at different durations. The slow version usually fails the moment you use it twice. The animation did not become clearer. It became something you wait for. Duration is the most common failure mode, but not the only one. Motion also fails when it fights the layout (content shifts while you try to click), when every element eases in like a hero moment, or when reduced-motion preferences are ignored and the interface keeps bouncing anyway. A few craft defaults I trust These match the with-motion examples above. They are starting points, not laws. Feedback and snappy controls (button presses, quick menus) usually sit around 120-200ms. Local state and origin cues, like switch travel or a tooltip entering, feel right closer to 180-280ms. Layout explanation can run longer when the job is reducing surprise; accordion height often needs about a quarter to a third of a second of visible travel. If the motion makes you wait, like a ~900ms menu open, it needs a clear explanatory job, or it is too slow. Ease out for things arriving, ease in for things leaving. Springs fit physical controls; linear easing almost never does for UI. And respect prefers-reduced-motion : prefer instant state changes, and keep only the color, opacity, or position updates that still carry meaning without the flourish. When in doubt, shorten first. Most “premium” motion I regret shipping was just long. A simple rule for deciding whether to animate Try the interaction without motion. Then ask what the user loses. If they lose context, feedback, a clear state change, or a sense of origin, add motion. If nothing becomes harder to understand, leave it alone. The best approach is usually to add the smallest amount of motion that solves the problem . Not the most impressive animation. Not the most complicated one. Just enough to make the change easier to follow. Motion should have a job A good micro-interaction does not ask anyone to stop and watch. It quietly confirms an action, explains a change, or keeps context intact while the interface moves. When motion does that work, it stops being decoration and becomes part of the interface. The goal isn't to make an interface move. The goal is to make a change easier to understand. ## FAQ ### What is “Designing Interfaces That Respond Naturally” about? A practical take on UI motion: remove animation first, keep what explains layout, feedback, state, or origin, and cut anything that only looks polished. Read it at https://www.edwinvakayil.info/writings/designing-interfaces-that-respond-naturally. ### Who wrote “Designing Interfaces That Respond Naturally”? Edwin Vakayil wrote “Designing Interfaces That Respond Naturally”. Canonical page: https://www.edwinvakayil.info/writings/designing-interfaces-that-respond-naturally. ### What sections are in “Designing Interfaces That Respond Naturally”? The article covers: Motion that explains a layout change; Feedback should be felt, not watched; State changes need continuity, not ceremony; Show where something came from; When motion gets in the way; A few craft defaults I trust; A simple rule for deciding whether to animate; Motion should have a job. ### When does UI animation improve usability? Motion helps when it gives context, feedback, a clearer state change, or shows where something came from. If removing animation makes an interaction harder to understand, motion is earning its place. ### When should you avoid animating an interface? Skip motion when the interaction is already obvious. Slow dropdowns, delayed tabs, layout-fighting transitions, or decorative easing can make a fast interface feel sluggish without improving understanding. ### What is a simple rule for deciding whether to animate? Try the interaction without motion first, then ask what the user loses. If they lose context, feedback, state clarity, or origin, add the smallest amount of motion that solves the problem. ### How long should UI micro-interactions take? As a starting point: about 120-200ms for feedback, 180-280ms for local state and origin cues, longer only when layout motion is explaining a change, and treat wait-y timing like a ~900ms menu open as too slow unless it has a clear job.