Design Motion Principles
Ship UI motion that stays usable for motion-sensitive users by applying reduced-motion CSS, functional-vs-decorative rules, and an accessibility implementation checklist.
Overview
Design Motion Principles is an agent skill most often used in Build (also Ship perf, Launch distribution polish) that teaches accessible UI motion with reduced-motion CSS and functional-vs-decorative rules.
Install
npx skills add https://github.com/kylezantos/design-motion-principles --skill design-motion-principlesWhat is this skill?
- Provides copy-paste `prefers-reduced-motion: reduce` CSS that collapses durations while preserving layout final states
- Separates functional motion (state/orientation) from decorative motion with explicit reduced-motion behavior
- Calls out vestibular triggers: large-scale motion, parallax, zoom, spin, and looping animations
- Includes an implementation checklist covering reduced-motion testing, pause controls, and trigger avoidance
- implementation checklist with reduced-motion and vestibular items
Adoption & trust: 3.5k installs on skills.sh; 657 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want polished UI motion but do not know how to honor `prefers-reduced-motion` or avoid vestibular triggers without stripping meaning from state changes.
Who is it for?
Solo builders shipping SaaS or marketing sites with CSS or framework transitions who need a clear accessibility bar for motion.
Skip if: Teams that only need brand motion guidelines with no implementation constraints, or apps with zero animation where this skill adds little.
When should I use this skill?
Adding or reviewing CSS animations, transitions, scroll-behavior, or decorative motion in a UI.
What do I get? / Deliverables
Your agent applies reduced-motion-safe CSS, classifies each animation as functional or decorative, and validates against the skill’s accessibility checklist before merge.
- Reduced-motion CSS snippet applied project-wide
- Classified motion inventory (functional vs decorative)
- Completed accessibility implementation checklist
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Motion and transitions are authored during product UI work, which maps to the Build phase as the canonical shelf. CSS animation, transitions, and scroll behavior are front-end concerns, so frontend is the primary subphase.
Where it fits
Refactor modal enter/exit transitions so reduced-motion users get instant state changes without layout breakage.
Audit looping hero animations and add pause controls before release.
Strip decorative parallax from a launch landing page while keeping functional loading indicators.
How it compares
Principle-and-checklist skill for accessible motion—not a Lottie asset pack or a performance-only Lighthouse pass.
Common Questions / FAQ
Who is design-motion-principles for?
Indie and solo front-end builders and designers pairing with AI agents to add transitions, loaders, or scroll effects without excluding motion-sensitive users.
When should I use design-motion-principles?
Use it during Build frontend when adding animations; during Ship perf when tuning transitions; and before Launch when polishing landing-page motion—all with reduced-motion testing.
Is design-motion-principles safe to install?
It is documentation-style guidance with no shell or network behavior implied; review the Security Audits panel on this Prism page before installing any skill from the repo.
SKILL.md
READMESKILL.md - Design Motion Principles
# Accessibility **This is not optional.** Motion can cause discomfort, nausea, or distraction for many users. --- ## Respect User Preferences ```css @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } } ``` **What this does**: Effectively disables animations while preserving final states (so layouts don't break). --- ## Functional vs. Decorative Motion | Type | Purpose | Reduced Motion Behavior | |------|---------|------------------------| | **Functional** | Indicates state changes, spatial relationships, orientation | May need alternative (instant state change, no transition) | | **Decorative** | Pure delight, visual interest | Can be fully removed | **The test**: Does removing this animation break the user's ability to understand what happened? If yes, it's functional. --- ## Motion Sensitivity Considerations - Avoid large-scale motion (full-screen transitions, parallax) - Avoid continuous or looping animations that can't be paused - Provide pause controls for any ambient animation - Be especially careful with vestibular triggers: zooming, spinning, parallax --- ## Implementation Checklist - [ ] Tested with `prefers-reduced-motion: reduce` enabled - [ ] No vestibular triggers (excessive zoom, spin, parallax) - [ ] Looping animations can be paused - [ ] Functional animations have non-motion alternatives - [ ] Users can complete all tasks with animations disabled # Anti-Checklist This file is the audit's quality gate. The categories below describe motion patterns to **flag** in audited code — AI-slop tells at the top (where most 2026 motion problems live), followed by perspective-specific anti-patterns from Emil, Jakub, and Jhey, then general motion mistakes and code-shaped red flags. When audited code matches a pattern here, the audit surfaces a finding and the agent generates a per-finding motion suggestion by reading the relevant philosophy reference (`emil-kowalski.md`, `jakub-krehel.md`, `jhey-tompkins.md`). The file frames patterns as "things to flag," not "mistakes to avoid" — language that makes the audit's adversarial posture explicit. --- ## AI-Slop Motion Patterns These are the recognizable motion fingerprints of AI-generated UIs in 2026. They're not always wrong in isolation — what makes them slop is *frequency* and *uniformity*. Finding one instance is normal polish; finding the same pattern slapped across the codebase is the tell. Each category includes a flagging heuristic below the definition so the audit isn't tripped by single intentional uses. --- ### Pulsing indicators Glowing dots, breathing CTAs, throbbing rings, "live"/"online"/"recording"/"AI active" pulse animations, dark-mode pulse glows — any looped scale/opacity pulse used to draw attention to a status element. **Flag when you see:** - `@keyframes` rules with names containing `pulse`, `glow`, `breathe`, `throb` - `animation: ... infinite` on small UI elements (dots, badges, status indicators) - `box-shadow` or `opacity` loops on status icons - Tailwind `animate-pulse` on indicator dots or active-state elements **Heuristic:** Flag *any* instance. Pulsing indicators are almost always slop — the only exception is a single brand element with explicit design rationale stated in code comments or design docs. **Fix lens:** Emil — purposeful restraint. See `references/emil-kowalski.md`. --- ### Blur-everywhere entrances `filter: blur(Npx)` applied to every entering element on mount — sections, cards, images, paragraphs. Jakub's enter recipe (`opacity + translateY + blur`) is excellent in moderation; AI-slop versions apply it uniformly across the page. **Flag when you see:** - `initial={{ filter: 'blur(Npx)' }}` or `from { filter: blur(Npx); }` on multiple distinct components in the same view - Identical blur values (e.g., `blur(4px)`)