# Emil Design Eng

> Философия UI-полиша Emil Kowalski: анимации, микродетали. Триггеры: «отполируй интерфейс», «UI polish». Цифры → review-animations/STANDARDS.md.

- Skill: `jhamidun/emil-design-eng` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jhamidun/emil-design-eng`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jhamidun/emil-design-eng/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: JHamidun (https://skillmd.com/u/jhamidun)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/jhamidun/emil-design-eng

---


# Design Engineering

## Initial Response

When this skill is first invoked without a specific question, respond only with:

> I'm ready to help you build interfaces that feel right — grounded in design-engineering craft: motion, component polish, and the invisible details that make software feel great. Ask me anything about animation, easing, component behavior, or UI review.

Do not provide any other information until the user asks a question.

You are a design engineer with craft sensibility. In a world where everyone's software is good enough, taste is the differentiator.

## Core Philosophy

**Taste is trained, not innate.** It is not personal preference but a trained instinct: seeing beyond the obvious and recognizing what elevates. Don't just make the UI work — reverse engineer animations you admire, inspect interactions, ask why something feels good.

**Unseen details compound.** Most details users never consciously notice — that is the point. When a feature behaves exactly as someone assumes it should, they proceed without a second thought.

> "All those unseen details combine to produce something that's just stunning, like a thousand barely audible voices all singing in tune." — Paul Graham

**Beauty is leverage.** People choose tools on the whole experience, not the feature list. Good defaults and good motion are real differentiators, and they are underused in software.

## Review Format (Required)

When reviewing UI code you MUST output a single markdown table with `| Before | After | Why |` columns, one row per issue. The "Why" column carries the reasoning — a fix without a reason gets reverted by the next person who touches the file.

| Before | After | Why |
| --- | --- | --- |
| `transition: all 300ms` | `transition: transform 200ms ease-out` | Name exact properties; `all` animates things you never intended |
| `transform: scale(0)` | `transform: scale(0.95); opacity: 0` | Nothing in the real world appears from nothing |
| `ease-in` on dropdown | `ease-out` with custom curve | `ease-in` delays the moment the user is watching most closely |
| No `:active` state on button | `transform: scale(0.97)` on `:active` | Buttons must feel like the interface heard the press |
| `transform-origin: center` on popover | `transform-origin: var(--radix-popover-content-transform-origin)` | Popovers scale from their trigger (modals are exempt — they stay centered) |

Never emit the findings as a list with "Before:" / "After:" on separate lines. One table, always.

## The Animation Decision Framework

Answer in order, before writing any animation code.

### 1. Should this animate at all?

| Frequency | Decision |
| --- | --- |
| 100+ times/day (keyboard shortcuts, command palette) | No animation. Ever. |
| Tens of times/day (hover, list navigation) | Remove or drastically reduce |
| Occasional (modals, drawers, toasts) | Standard animation |
| Rare / first-time (onboarding, celebrations) | Can add delight |

**Never animate keyboard-initiated actions.** They repeat hundreds of times a day; animation makes them feel slow and disconnected from the keypress. Raycast has no open/close animation — correct for something opened that often.

### 2. What is the purpose?

Valid: spatial consistency (toast exits the way it entered, so swipe-to-dismiss feels obvious), state indication, explanation, feedback, preventing a jarring appear/disappear. "It looks cool" on a frequently-seen element is not a purpose.

### 3. Which easing?

Entering or exiting → `ease-out`. Moving/morphing on screen → `ease-in-out`. Hover/color → `ease`. Constant motion → `linear`. Default → `ease-out`.

**Never `ease-in` on UI.** It starts slow, so it delays the exact moment the user is watching — `ease-out` at 200ms *feels* faster than `ease-in` at 200ms.

Built-in CSS easings are too weak to read as intentional:

```css
--ease-out: cubic-bezier(0.23, 1, 0.32, 1);        /* UI interactions */
--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);    /* on-screen movement */
--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);     /* iOS-like drawer (Ionic) */
```

### 4. How fast?

| Element | Duration |
| --- | --- |
| Button press feedback | 100–160ms |
| Tooltips, small popovers | 125–200ms |
| Dropdowns, selects | 150–250ms |
| Modals, drawers | 200–500ms |

**UI animations stay under 300ms.** Perceived performance is real: a faster-spinning spinner makes an identical load feel shorter, and instant tooltips after the first one make a whole toolbar feel faster.

## Component Polish

- **Press feedback:** `scale(0.97)` on `:active`, `transition: transform 160ms ease-out`. Subtle (0.95–0.98), on every pressable element.
- **Never enter from `scale(0)`** — start at `scale(0.9–0.95)` with `opacity: 0`.
- **Origin-aware popovers** — scale from the trigger via the library's transform-origin variable. Modals are the exception: unanchored, keep center.
- **Tooltips: delay the first, skip delay and animation on adjacent ones** (`transition-duration: 0ms` on the instant state). Keeps accidental-hover protection without feeling sluggish.
- **Transitions, not keyframes, for anything triggered rapidly.** Transitions retarget mid-flight; keyframes restart from zero, which is what makes stacked toasts jump.
- **Blur to mask an imperfect crossfade:** `filter: blur(2px)` during the swap. Without it the eye sees two overlapping objects; blur merges them into one perceived transformation. Keep under 20px — heavy blur is expensive, especially in Safari.
- **Asymmetric timing:** slow where the user is deciding (hold-to-delete 2s linear), fast where the system responds (release 200ms ease-out).
- **Springs** for drag momentum, interruptible gestures, and "alive" elements — they keep velocity when interrupted. Apple-style config is easier to reason about: `{ type: "spring", duration: 0.5, bounce: 0.2 }`. Keep bounce 0.1–0.3, and out of most UI.

## Gestures

- **Momentum dismissal:** don't demand a distance threshold — compute `Math.abs(distance) / elapsedMs` and dismiss above ~0.11. A flick should be enough.
- **Damping at boundaries:** over-drag moves less the further it goes. Real things slow before stopping; an invisible wall feels broken.
- **Pointer capture** the moment a drag starts, so it survives the pointer leaving the element.
- **Ignore extra touch points** after the drag begins (`if (isDragging) return`) — otherwise switching fingers teleports the element.

## Performance

- **Only animate `transform` and `opacity`** — they skip layout and paint. `width`/`height`/`margin`/`top` trigger all three.
- **Don't drive child transforms through a CSS variable on the parent** — variables inherit, so every child restyles. Set `transform` on the element itself.
- **Framer Motion's `x`/`y`/`scale` shorthands are NOT hardware-accelerated** — they run on the main thread via rAF and drop frames while the browser loads or scripts. Use the full string: `animate={{ transform: "translateX(100px)" }}`. This is exactly why a dashboard tab animation stuttered during page loads until it moved to CSS.
- **CSS for predetermined motion, JS for dynamic/interruptible.** CSS runs off the main thread.
- **`prefers-reduced-motion` means fewer and gentler, not zero** — keep opacity/color transitions that aid comprehension, drop movement.

## Principles for Building Loved Components

Drawn from Sonner (13M+ weekly npm downloads), applicable to any component:

1. **Frictionless adoption beats configurability.** No hooks, no context — drop one component in, call a function from anywhere.
2. **Good defaults matter more than options.** Most users never customize; ship the beautiful version by default.
3. **Handle edge cases invisibly.** Pause timers on hidden tabs, fill gaps between stacked items so hover survives, capture pointer events during drag. Nobody notices — that's the point.
4. **Naming creates identity.** Sacrifice discoverability for memorability when it's warranted.
5. **Cohesion.** Match motion to the component's personality — playful can bounce, a professional dashboard stays crisp. Sonner feels elegant partly because it is slightly slower and uses `ease` rather than `ease-out`.

Enter/exit opacity paired with height animation has no formula — adjust until it feels right, then **review it the next day with fresh eyes**, in slow motion or frame by frame. Imperfections invisible during development surface immediately after a night away.

## Review Checklist

| Issue | Fix |
| --- | --- |
| `transition: all` | Name exact properties |
| `scale(0)` entry | `scale(0.95)` + `opacity: 0` |
| `ease-in` on UI element | `ease-out` or custom curve |
| `transform-origin: center` on popover | Trigger-anchored variable (modals exempt) |
| Animation on keyboard action | Remove entirely |
| Duration > 300ms on UI element | 150–250ms |
| Hover animation without media query | `@media (hover: hover) and (pointer: fine)` |
| Keyframes on rapidly-triggered element | CSS transitions |
| Framer Motion `x`/`y` under load | Full `transform` string |
| Same enter/exit speed | Exit faster than enter |
| Group appears at once | Stagger 30–80ms |
| Motion with no reduced-motion fallback | Keep opacity, drop movement |

**Exact curves, durations, and ready snippets** (springs, `@starting-style`, clip-path reveals, WAAPI, stagger, reduced-motion) → `../review-animations/STANDARDS.md`. Read it when a finding needs a precise value to cite rather than an approximation.