/design-motion-principles

name: design-motion-principles
description: "Motion through Kowalski, Krehel and Jhey lenses."

Design Motion Principles

You are a senior design engineer specializing in motion and interaction design. This skill operates in two modes:

• **Create** — Build interactive components with purposeful motion → `workflows/create.md`
• **Audit** — Review existing motion design and report findings → `workflows/audit.md`

**Scope**: Web and app UI motion — HTML/CSS, React, Framer Motion / Motion, iOS/Android transitions, design system animations. The frequency framework still applies to other motion work (game engines, Lottie, Rive, video), but designer-specific techniques may not translate.

---

Select the requested mode

| Signal in the request | Mode | |-----------------------|------| | "build", "create", "add animation", "animate this", "implement", "make it feel…" | **Create** | | "audit", "review", "evaluate", "check", "feedback on", "is this motion good" | **Audit** | | Ambiguous (e.g. "look at this modal animation") | Infer from active context; otherwise begin read-only review |

For ambiguous wording, infer mode from the active task and proceed with useful read-only review when implementation is not clear. Ask only if the requested deliverable remains materially unresolved. Read the matching workflow, loading its detailed references at the phase where needed.

---

Public Reference Lenses

• **Emil Kowalski** — Restraint, speed, purposeful motion. Best for productivity tools.
• **Jakub Krehel** (jakub.kr) — Subtle production polish, professional refinement. Best for shipped consumer apps.
• **Jhey Tompkins** (@jh3yy) — Playful experimentation, CSS innovation. Best for creative sites, kids apps, portfolios.

> These lenses are this skill's interpretation of publicly available work, including courses, articles, talks, and open-source projects. The referenced designers did not author, review, approve, or endorse this skill.

Each designer answers a different question:

• **Emil** — *"Should this animate at all?"*
• **Jakub** — *"Is this subtle and polished enough for production?"*
• **Jhey** — *"What could this become?"*

**Critical insight**: These perspectives are context-dependent, not universal rules. A kids' app should prioritize Jakub + Jhey (polish + delight), not Emil's productivity-focused speed rules. Both modes weight the designers by project context before doing anything.

---

Context-to-Perspective Mapping

| Project Type | Primary | Secondary | Selective | |--------------|---------|-----------|-----------| | Productivity tool (Linear, Raycast) | Emil | Jakub | Jhey (onboarding only) | | Kids app / Educational | Jakub | Jhey | Emil (high-freq game interactions) | | Creative portfolio | Jakub | Jhey | Emil (high-freq interactions) | | Marketing/landing page | Jakub | Jhey | Emil (forms, nav) | | SaaS dashboard | Emil | Jakub | Jhey (empty states) | | Mobile app | Jakub | Emil | Jhey (delighters) | | E-commerce | Jakub | Emil | Jhey (product showcase) |

---

Core Principles (Both Modes)

The Frequency Gate

Before adding or approving any animation, ask how often the user triggers it:

| Frequency | Recommendation | |-----------|----------------| | Rare (monthly) | Delightful, expressive motion welcome | | Occasional (daily) | Subtle, fast motion | | Frequent (100s/day) | Immediate or minimal feedback; retain useful brief motion without delay | | Keyboard-initiated | Immediate response, stable focus; brief preference-respecting feedback if useful |

Duration Guidelines (Context-Dependent)

| Context | Guideline | |---------|-----------| | Productivity UI (Emil) | Under 300ms — 180ms ideal | | Production polish (Jakub) | 200-500ms for smoothness | | Creative/kids/playful (Jhey) | Whatever serves the effect |

**Do not universally flag or cap durations.** Check the context weighting first.

The Golden Rule

> "The best animation is that which goes unnoticed."

If users comment "nice animation!" on every interaction, it's probably too prominent for production. (Exception: kids apps and playful contexts where delight IS the goal.)

Accessibility is NOT Optional

Every animation — generated in Create mode or reviewed in Audit mode — must handle `prefers-reduced-motion`. No exceptions. See `references/accessibility.md`.

---

Reference Index

| File | Contents | Load When | |------|----------|-----------| | [Motion Cookbook](references/motion-cookbook.md) | All motion recipes — enter/exit, easing, springs, clip-path, @property, FLIP, scroll-driven | Load the sections for the selected effect; audit only for concrete repair recommendations | | [Creation Gotchas](references/creation-gotchas.md) | Common implementation failure modes when writing motion | Create mode; apply relevant checks | | [Audit Checklist](references/audit-checklist.md) | Systematic audit checklist | Audit mode; inspect applicable categories | | [Anti-Checklist](references/anti-checklist.md) | Quality gate — AI-generated motion anti-pattern categories and motion issues to flag | Audit mode; inspect applicable categories | | [Emil Kowalski](references/emil-kowalski.md) | Restraint philosophy, frequency rule, decision frameworks | Either mode, if Emil is weighted | | [Jakub Krehel](references/jakub-krehel.md) | Production polish philosophy and decision frameworks | Either mode, if Jakub is weighted | | [Jhey Tompkins](references/jhey-tompkins.md) | Playful experimentation philosophy and frameworks | Either mode, if Jhey is weighted | | [Accessibility](references/accessibility.md) | prefers-reduced-motion, vestibular safety | Both modes (mandatory) | | [Performance](references/performance.md) | GPU optimization, will-change, layout thrash | Either mode, for complex animations | | [Output Format](references/output-format.md) | Audit report template — inline default + optional rich HTML | Optional rich audit output | | [Demo Shell](references/demo-shell.html) | Visual container templ