Use when designing, building, reviewing, or polishing user interfaces, motion, component behavior, interaction details, and product-feel across any frontend stack. Generalized from Emil Kowalski-style design engineering principles; framework-neutral, implementation-first.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Use when designing, building, reviewing, or polishing user interfaces, motion, component behavior, interaction details, and product-feel across any frontend stack. Generalized from Emil Kowalski-style design engineering principles; framework-neutral, implementation-first.
Design Engineering
Purpose
Use this skill to make interfaces feel intentional, fast, and physically believable โ not merely functional. It is framework-neutral: apply it to HTML/CSS, Svelte, React, Vue, native apps, Web Components, canvas/WebGL, or design specs.
The goal is not decoration. The goal is product feel: the compounding effect of layout, motion, responsiveness, accessibility, and tiny interaction details that users rarely notice consciously but absolutely feel.
When to Use
Use for:
UI polish passes
Interaction design and component behavior
Motion design, transitions, gestures, and microinteractions
Reviewing frontend code for feel, responsiveness, and accessibility
Turning a rough UI into something crisp and shippable
Designing component APIs where behavior and styling must stay coherent
Diagnosing why an interface feels slow, awkward, cheap, or janky
Do not use for:
Pure backend work with no user-facing behavior
Brand strategy without UI execution
Large design-system governance unless the task includes concrete UI behavior
Core Philosophy
Taste is trained
Good taste is not vibes. It is pattern recognition built by studying great interfaces, reverse-engineering why they feel good, inspecting tiny details, and practicing until the defaults become sharp.
Do not stop at โit works.โ Ask what the user feels in the first 100ms after they act.
Invisible details compound
The best UI details disappear. A popover opens from the trigger. A button visibly responds to pressure. A list reorders without losing spatial continuity. A destructive action feels serious without feeling dramatic.
Users may not name these details, but their nervous system does.
Beauty is leverage
Most software is good enough. Taste is a differentiator. Strong defaults, precise motion, and coherent interaction details make tools feel more trustworthy and more desirable.
Operating Loop
Identify the user action.
Identify the expected physical response.
Decide whether motion helps or hurts.
Make the first frame responsive.
Preserve spatial continuity.
Implement with the least fragile primitive.
Test slowly, quickly, interrupted, repeated, keyboard-only, touch, and reduced-motion.
Remove anything that feels ornamental under repetition.
Review Output Contract
When reviewing UI or code, prefer a compact table:
Animate transform and opacity by default. Treat layout properties (height, width, top, left, margin) as expensive and suspicious unless the element count is small and you have tested it.
If animating layout is necessary, isolate the damage:
Guard multi-touch if the gesture is single-pointer.
Release must settle somewhere believable
On release, animate to the nearest intentional state: closed, open, dismissed, snapped, reordered. Do not leave fractional awkward states unless the UI is truly continuous.
Layout and Visual Polish
Alignment beats decoration
Before adding effects, fix:
Uneven spacing
Optical alignment
Baseline rhythm
Hit target size
Text contrast
Icon/text balance
Ragged wrapping in common widths
Use hierarchy before chrome
If a screen feels confusing, do not add borders everywhere. Clarify hierarchy with grouping, spacing, type scale, and content order first.
Defaults should be opinionated
A high-quality component should look good with minimal configuration. If every usage needs five props/classes to look acceptable, the abstraction is weak.
Responsive behavior is not just breakpoints
Check:
Long labels
Narrow containers
Tall content
Touch targets
Safe areas / notches
Reduced pointer precision
Text zoom
OS/browser font rendering differences
Accessibility and User Preferences
Reduced motion is not optional
Implement prefers-reduced-motion. Reduced does not always mean zero; it means remove vestibular motion and long transitions.
A disabled button with no explanation is often bad UX. Prefer visible requirements, inline validation, or enabled actions that explain what is missing.
Performance Rules
Measure the feeling, not just the profiler
A transition can be technically cheap and still feel wrong. Test with real interaction speed, repeated use, and interruption.
CSS usually wins for simple state animation
For simple enter/exit/hover/press states, CSS transitions are smaller, interruptible, and resilient. Use JavaScript when animation depends on runtime measurement, gestures, sequencing, physics, or canvas/WebGL.
Use JS animation deliberately
If using a JS animation library:
Know whether it writes transform/opacity or layout properties
Ensure animations are interruptible
Avoid rerendering the app every frame
Keep animation state out of broad reactive/global state when possible
Test with CPU throttling
Beware inherited CSS variables in hot paths
Animating a CSS custom property can invalidate more than expected because variables inherit. It can be fine; just test it in real DOM shape before assuming it is free.
Debugging and QA
Slow it down
Temporarily multiply durations by 4โ10x. Bad origins, weird easing, cross-fades, and layout jumps become obvious.
Inspect frame by frame
Use browser/devtool animation inspection or screen recording scrub. Verify:
Start with opacity + 2โ6px translate, not a huge slide
Scale from trigger origin only if it helps
Modal feels cheap
Keep modal centered
Fade/soft-scale backdrop and content separately
Avoid huge zooms
Ensure focus trap and Escape behavior are correct
Make exit slightly faster than enter
Button feels dead
Add active state
Tighten hover feedback
Check disabled/loading states
Make loading preserve width to avoid layout shift
Confirm focus style is visible
List reorder feels confusing
Preserve object identity visually
Animate moved items, not the entire list opacity
Avoid cross-fading text unless content actually changed
Keep duration short under repeated interactions
Page transition feels slow
Remove it if navigation is frequent
Animate only persistent shell/context, not every piece of content
Show immediate feedback first
Preserve scroll/focus expectations
Final Review Checklist
Before shipping UI, answer yes:
Does the first frame respond immediately to user input?
Does every animation have a purpose besides decoration?
Are frequent actions instant or nearly instant?
Are transitions limited to exact properties?
Are transform origins physically believable?
Are press, hover, focus, loading, empty, error, and disabled states handled?
Does keyboard behavior match mouse behavior where appropriate?
Is reduced motion handled?
Does the UI survive interruption and spam-clicking?
Has it been tested in the smallest realistic container/viewport?
Has it been tested on touch or touch emulation if touch users exist?
Is the component API expressing intent rather than leaking arbitrary styling knobs?
Did you remove ornamental motion that becomes annoying under repetition?
If any answer is no, fix it before calling the interface polished.
Source Note
This skill is generalized from Emil Kowalski-style design engineering principles and the source skill Scott provided, with framework-specific React/Framer assumptions removed. Keep the craft, lose the framework lock-in.
