design-motion-principles

Motion through Kowalski, Krehel and Jhey lenses.

SKILL.md

GitHub

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 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 Common implementation failure modes when writing motion Create mode; apply relevant checks
Audit Checklist Systematic audit checklist Audit mode; inspect applicable categories
Anti-Checklist Quality gate — AI-generated motion anti-pattern categories and motion issues to flag Audit mode; inspect applicable categories
Emil Kowalski Restraint philosophy, frequency rule, decision frameworks Either mode, if Emil is weighted
Jakub Krehel Production polish philosophy and decision frameworks Either mode, if Jakub is weighted
Jhey Tompkins Playful experimentation philosophy and frameworks Either mode, if Jhey is weighted
Accessibility prefers-reduced-motion, vestibular safety Both modes (mandatory)
Performance GPU optimization, will-change, layout thrash Either mode, for complex animations
Output Format Audit report template — inline default + optional rich HTML Optional rich audit output
Demo Shell Visual container template for per-finding demo cards in the HTML report Audit mode, HTML output

Workflow Index

Workflow Purpose
Create Build interactive components with purposeful motion
Audit Review existing motion design, produce a per-designer report