Skills for Design Engineers

Project Overview

Skills (emilkowalski/skills) is a curated collection of UI interaction patterns and animation techniques built for design engineers — practitioners who own both the visual design and the frontend code. Created by Emil Kowalski, the project documents concrete animation patterns and interaction mechanics that show up repeatedly in high-quality product work.

The repo isn't a component library. You won't add it to your package.json. Instead, it's a reference — production-tested patterns you read, understand, and adapt into your own codebase. With over 16,000 stars, it's clearly useful to engineers who want their interfaces to move like native apps rather than static web pages.

If you're looking for a drop-in, versioned dependency with a changelog and semver guarantees, look elsewhere. Skills trades that for something different: unusually clean, readable implementations that you own once you copy them.

Key Challenges Addressed

Two things make UI animation hard in practice: getting the physics right, and knowing which pattern to reach for.

Timing that feels wrong: Most engineers default to CSS ease-in-out or a fixed-duration Framer Motion fade. This works for simple opacity changes, but for anything involving position, scale, or layout, it reads as stiff. Physical objects don't decelerate uniformly — they overshoot, they respond to velocity. Skills targets this with spring-physics configurations tuned for common UI scenarios.

Interaction patterns with no reference implementation: Swipe-to-dismiss, drag reorder, shared element transitions — these are well-documented in native iOS/Android SDKs but poorly documented for the web. Skills covers full implementations, including the failure modes you'll hit after the happy path.

Layout animation coordination: Animating elements as they enter, leave, or reorder in a list is hard to do without visual glitches. Framer Motion's AnimatePresence and layout animation features handle this well, but using them correctly requires specific composition patterns that aren't obvious from the documentation alone.

Getting Started

Clone the repo and run it locally to see all patterns in context:

git clone https://github.com/emilkowalski/skills.git
cd skills
npm install
npm run dev

Sharp edges you'll hit early:

• Framer Motion version pinning: Copying a pattern into a project on a different major Framer Motion version silently breaks animations — AnimatePresence exit callbacks and useAnimate signatures changed between v10 and v11. Run npm list framer-motion in both codebases before copying any pattern.
• Node version: Node version mismatches surface as cryptic CSS/JS optimization errors in Next.js builds, not obvious version complaints. Match the .nvmrc version or the engines.node field in package.json exactly.

Once it's running, each skill renders in isolation so you can inspect its behavior without surrounding page noise. That's intentional — treat it like a sandboxed component demo.

Features and Use Cases

Spring-physics animations: Pre-tuned configurations for common UI movements — panel slide-in, modal entrance, card hover lift. These use actual spring physics so the motion feels responsive to simulated inertia rather than just decelerated timing curves.

Gesture-driven interactions: Patterns for drag, press, and swipe that respond correctly to input velocity, not just position. If you've built a swipe gesture that works on desktop but feels wrong on mobile because it ignores gesture speed, these implementations address that gap directly.

Layout animations: Techniques for animating list reordering, content expansion, and collapsing panels without frame drops. The patterns clarify when to use the layout prop versus layoutId for shared-element transitions — a distinction the Framer Motion docs explain but don't illustrate well in realistic component compositions.

Micro-interactions: Smaller patterns — focus ring animations, button press feedback, checkbox state transitions — that layer onto existing components without conflicting with their structure.

Realistic use cases: a SaaS dashboard where the command palette needs to feel snappy and precise; a mobile web app where card interactions need to match native gesture expectations; an existing design system you want to upgrade from flat CSS transitions to physics-based motion.

Ecosystem and Dependencies

Skills is built on a stack common to contemporary design-engineering work:

• Framer Motion: The animation engine for everything in the repo. You'll get the most value here if you're already committed to this library. The Framer Motion documentation covers the full API and pairs well with React's component model.
• Next.js: The demo app runs on Next.js. The component patterns themselves are framework-agnostic React and port cleanly to Vite or any other React environment without changes.
• Tailwind CSS: Class-based styling throughout, which keeps visual logic cleanly separated from animation logic when adapting patterns.
• TypeScript: Types are included in the implementations. You won't need to reconstruct them when copying into a typed codebase.

The Framer Motion + Tailwind + Next.js combination is the current consensus stack for this kind of work. If you're already on it, copying from Skills into your project is nearly frictionless.

Architectural Overview

The repo is structured as a Next.js app where each skill or technique gets its own page or route. The component architecture is deliberately flat: each pattern lives in a single file (or a small cluster of co-located files) with animation logic inline rather than abstracted into hooks or utility layers.

This is the right call for a reference project. Abstraction hides intent. When you're reading these patterns to learn or adapt them, seeing the Framer Motion props directly on the motion component — rather than buried in a custom hook — tells you exactly what each parameter does and why.

There's no state management library, no API integration, no routing complexity beyond Next.js defaults. Every bit of complexity in the codebase is there because the pattern itself requires it. You won't mistake scaffolding complexity for pattern complexity.

Pros and Cons

Pros

• Patterns reflect decisions made when shipping interfaces where visual quality is a product requirement — not toy examples.
• Short, readable code with no framework abstractions to unwrap before you reach the interesting part.
• You own the code completely once you copy it — no upstream dependency surprises, no API deprecations that silently break your UI.
• Curated, not exhaustive. High signal-to-noise ratio compared to broader UI component repos.

Cons

• No installable package. You copy and own the code, which means you're responsible for keeping patterns current as Framer Motion evolves.
• Deep Framer Motion coupling. Adapting any pattern to GSAP, CSS keyframes, or another animation engine is a rewrite, not a port.
• Not a component library. No form controls, data tables, layout primitives, or navigation components. Skills is specifically about animation and interaction mechanics.
• Sparse explanation. The patterns are clean but lightly commented. If you're learning Framer Motion simultaneously, you'll need the library docs open alongside to understand why each parameter value was chosen.

Comparison and Alternatives

For teams that want something more installable or with broader scope, several strong alternatives exist.

shadcn/ui takes a similar copy-paste philosophy but focuses on accessibility-first component primitives using Radix UI under the hood. It's broader in scope — full form controls, navigation, dialogs — and has extensive documentation. If you need a full component system rather than an animation reference, start here.

Framer Motion itself is the underlying animation library Skills uses. If you want to build patterns from scratch rather than adapt existing ones, the Framer Motion documentation and examples cover the full API surface. Skills is a curated cookbook built on top of it.

Magic UI offers animated components as installable packages, also built on Framer Motion and Tailwind. If you want animated components you can add via a CLI command rather than copying implementations by hand, Magic UI fits that workflow.

animate.css is a CSS-only animation library requiring no JavaScript runtime. It's useful for simple entrance/exit animations in projects without a React dependency, but it doesn't address spring physics, gesture-driven interactions, or layout animations.

The best overall alternative is shadcn/ui. It has the most complete documentation, the largest contributor community, and a similarly opinionated copy-paste delivery model. It won't match Skills' depth on animation mechanics, but as a foundation for a full design system it's far more complete.

Conclusion

If you build React interfaces where interaction quality matters and you're already using Framer Motion, Skills is the most direct reference available for production-grade animation patterns. Read the project on GitHub, find a pattern that matches your use case, and adapt it directly — you'll skip weeks of trial-and-error on spring tuning.

Do not copy patterns wholesale across major Framer Motion version boundaries. If your project runs Framer Motion v10 and the Skills repo has moved to v11, AnimatePresence exit behavior and layout animation sizing will diverge silently — elements snap to wrong positions or animations skip entirely. Before copying any pattern, run npm list framer-motion in both your project and the Skills repo and match the major version.