motion-principles

Defines motion design principles for UI animation timing, easing, and reduced-motion handling.

Updated Aug 12, 2026
One-click install
npx skills add https://github.com/brunoolf/frontend-craft --skill motion-principles-brunoolf
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: motion-principles
Source: https://github.com/brunoolf/frontend-craft/tree/main/skills/motion-principles
Command: npx skills add https://github.com/brunoolf/frontend-craft --skill motion-principles-brunoolf

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Interfaces often suffer from arbitrary animation decisions: motion added because it looks nice, inconsistent durations, wrong easing curves, and broken reduced-motion fallbacks. This Skill provides a single authoritative foundation for deciding when to animate, how long animations should last, which curves to use, and how to handle accessibility and performance constraints. ## Core Features & Use Cases - Decision framework for animation: Five legitimate reasons to animate (continuity, causality, orientation, feedback, character) plus explicit rules for when not to animate, such as repeated actions, error states, and time-critical tasks. - Timing and easing reference: Duration tables from 100ms micro-feedback to 600ms page transitions, guidance on ease-out defaults, spring physics for gesture-driven motion, and concrete cubic-bezier starting points. - Accessibility and performance rules: Mandatory prefers-reduced-motion handling that preserves state changes while removing displacement, plus GPU-friendly transform/opacity patterns and warnings against animating layout properties. - Use Case: Before building a modal entrance animation, consult this Skill to pick a 250-400ms duration, an ease-out curve, a short 8-24px travel distance, and a reduced-motion fallback that keeps a simple fade. ## Quick Start Ask the agent to review or plan the animations for a component using the motion principles before writing any GSAP or CSS transition code.

Frequently Asked Questions about motion-principles

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide when to animate a UI element?▼

Animate only for one of five reasons: continuity, causality, orientation, feedback, or character. If none applies, do not animate. Avoid animating repeated daily actions, content the user came to read, error states, and anything on a time-critical path.

What duration should UI animations use?▼

Match duration to scale: 100-150ms for micro feedback, 150-250ms for tooltips and dropdowns, 250-400ms for modals and drawers, and 400-600ms for page transitions. Exits should run at 70-80% of the entrance duration.

Which easing curve should I use for UI transitions?▼

Use ease-out as the default for almost everything since it reacts immediately to input. Reserve ease-in for disappearing elements and springs for gesture-driven motion with physical mass. Good starting points are cubic-bezier(0.32, 0.72, 0, 1) and cubic-bezier(0.22, 1, 0.36, 1).

How should I handle prefers-reduced-motion in CSS?▼

Preserve the state change but remove displacement: keep a 100-150ms fade and eliminate translate, scale, rotation, and parallax. Removing all animation breaks the causal feedback users rely on to understand what happened.

Why is animating width or top bad for performance?▼

Animating top, left, width, height, margin, or padding triggers layout recalculation across the tree on every frame. Animate transform and opacity instead, since they composite on the GPU without layout or paint.

When should I use spring animations instead of duration-based easing?▼

Use springs for anything with perceived mass: gestures, dragging, and elastic interactions the user physically grabs. Think in stiffness and damping rather than duration, and never apply springs to opacity fades since there is no mass to simulate.