design-eng

原文涵盖的主题

• Design engineering
• What this skill is, and is not
• Hard rules
• Decision framework
• 1. Should this animate at all?
• 2. What is the purpose?
• 3. What easing?
• 4. How fast?

Motion decisions from Emil Kowalski's design-engineering notes (MIT). Unseen details compound. Keyboard actions never animate. Do the task. Do not open with a philosophy recap. | This skill | Not this skill | | --- | --- | | Should this animate, and with which easing, duration, and origin | Exact polish numbers (vd:better-ui) | | Popovers, tooltips, toasts, drawers, clip-path, drag | Design-system choice, tokens, page build (vd:uiuxdesign) | | A Before / After / Why review table | Posting that table on a PR (vd:code-review) | When vd:better-ui already names an exact value, use that value. | Interaction | Use | | --- | --- | | Press scale | 0.96 from vd:better-ui, not 0.97 | | Icon cross-fade | scale 0.25, blur 4px, bounce 0 from vd:better-ui | | Page-level stagger | 100ms from vd:better-ui | | List stagger | 30-80ms, in motion.md | | Crossfade mask | blur(2px) here, not the icon blur | 1. Answer "should this animate?" before writing a curve. Frequency decides. A keyboard shortcut or command palette never animates. 2. Never use ease-in on UI. It delays the first frame, which is the moment the user is watching. Never use transition: all. 3. Never enter from scale(0). Start at scale(0

这里只展示节选，请以完整原文和当前要求为准。