跳到主要内容
知仓学习社ZHICANG

design-engineering

Apply interface craft when building or reviewing UI - motion, easing, timing, springs, component feel, and visual foundations. Use when building a c…

不碰外部(只输出文字)无严重或高危命中rohitg00/pro-workflow

它会碰到什么

扫了多少1 个文本文件,5 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

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:

--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 |

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。

它属于哪个仓库

星标★ 2,870
本站分层T1
该仓技能数41
原文件路径skills/design-engineering/SKILL.md

同一个仓库里的其他技能

看这个仓库的全部 41 个技能