---
name: design-engineering
description: Apply interface craft when building or reviewing UI - motion, easing, timing, springs, component feel, and visual foundations. Use when building a component, animation, transition, hover or press state, modal, drawer, toast, or when polishing an interface so it feels right. Says "make this feel better", "add an animation", "polish the UI", "review this component".
---
# design-engineering
In a world where most software works well enough, feel is the differentiator.
Most of what makes an interface feel right is detail the user never
consciously notices - the aggregate of small correct choices. Build for that
aggregate.
## Motion decision framework
Answer these in order before writing any animation.
### 1. Should it animate at all?
The deciding factor is frequency. The more often a user sees it, the less it
should move.
| How often the user sees it | Decision |
|----------------------------|----------|
| 100+ times/day (shortcuts, command palette) | No animation, ever |
| Tens of times/day (hover, list nav) | Remove or drastically reduce |
| Occasional (modals, drawers, toasts) | Standard animation |
| Rare or first-time (onboarding, celebration) | Room for delight |
Never animate a keyboard-initiated action. It repeats all day; animation makes
it feel slow and disconnected from the keypress.
### 2. What is the purpose?
Every animation needs an answer to "why does this move?" Valid ones: spatial
consistency (enters and exits the same edge), state change, feedback (a press
that confirms the interface heard you), or preventing a jarring appear/disappear.
"It looks cool" is not a purpose for anything the user sees often.
### 3. What easing?
- Entering or exiting -> `ease-out` (fast start, feels responsive).
- Moving or morphing on screen -> `ease-in-out`.
- Hover or color change -> `ease`.
- Constant motion (marquee, progress) -> `linear`.
Never use `ease-in` for UI. It delays the first moment of movement - exactly
when the user is watching - so a 300ms `ease-in` dropdown feels slower than a
300ms `ease-out` one. The built-in curves are weak; use stronger custom ones:
```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 */
```
### 4. How fast?
| Element | Duration |
|---------|----------|
| Button press feedback | 100-160ms |
| Tooltip, small popover | 125-200ms |
| Dropdown, select | 150-250ms |
| Modal, drawer | 200-500ms |
Keep frequent, interactive UI under 300ms; the modal and drawer range above (up to 500ms) is the deliberate exception for occasional, first-time surfaces. Perceived speed is real: a faster spinner makes
a load feel faster at the same load time, and an instant tooltip after the first
one makes a whole toolbar feel quick.
## Springs
Springs settle on physics, not a fixed duration, so they feel alive and, unlike
CSS keyframes, keep their velocity when interrupted. Reach for them on drag and
gesture interactions the user can reverse mid-motion, and on decorative,
mouse-tracked motion. Keep bounce subtle (0.1 to 0.3) and usually absent - save
it for drag-to-dismiss and playful moments, not functional UI.
## Component feel
- **Press feedback.** Any pressable element gets `transform: scale(0.97)` on
`:active` with a ~160ms `ease-out` transition. Subtle (0.95 to 0.98); it makes
the interface feel like it is listening.
- **Never animate from `scale(0)`.** Nothing real appears from nothing. Start at
`scale(0.9)` or higher plus opacity so the entrance has shape.
- **Scale from the trigger.** Popovers and dropdowns scale from their origin, not
their center. Modals stay centered.
- **Respect `prefers-reduced-motion`.** Drop or shorten non-essential motion.
## Visual foundations
- One spacing scale, one type scale. Consistency reads as intent; ad-hoc values
read as noise.
- Restrained color: a small palette with clear roles beats many accents.
- Make every interactive state explicit - hover, active, focus-visible, disabled.
A control with no states feels dead.
## Review format
When reviewing UI code, output a single markdown table, one row per issue, with
`Before | After | Why`. Do not use separate "Before:" / "After:" lines.
| Before | After | Why |
|--------|-------|-----|
| `transition: all 300ms` | `transition: transform 200ms ease-out` | Name exact properties; avoid `all` |
| `transform: scale(0)` | `scale(0.95); opacity: 0` | Nothing appears from nothing |
| `ease-in` on a dropdown | strong `ease-out` | `ease-in` reads as sluggish |
| no `:active` state | `scale(0.97)` on `:active` | Presses must feel responsive |