Motion, Interaction & Prototyping

Smooth motion is a budget problem. You have ~16.7ms per frame at 60fps and the difference between a Design Engineer and a front-end engineer is knowing exactly which CSS properties spend that budget cheaply.

Cursor runs in Electron, a Chromium renderer wrapped in a desktop shell. The browser does the same pipeline work it does on the web: style, layout, paint, composite. Animate the wrong property and you force the whole pipeline to re-run sixty times a second on a window that is already busy rendering a code editor.

Animate on the compositor, not the main threadthe single most important rule

Two properties animate without touching layout or paint: transform and opacity. The compositor handles them on the GPU, often on a separate thread, so they keep moving even when JavaScript is blocked. Everything else is suspect.

CSS animation vs the Web Animations APIdeclarative when you can, imperative when you must

CSS transitions and keyframes are the right default. They are declarative, the browser optimizes them and they survive a busy main thread. Reach for the Web Animations API when motion has to be dynamic - a value computed at runtime, a spring you cancel mid-flight or choreography you sequence in code.

const anim = el.animate(
  [{ transform: "translateY(8px)", opacity: 0 },
   { transform: "translateY(0)",   opacity: 1 }],
  { duration: 180, easing: "cubic-bezier(0.2, 0, 0, 1)", fill: "both" }
);
anim.finished.then(() => el.classList.add("settled"));
// Interruptible: anim.reverse() or anim.cancel() at any time.

Springs vs easing curveswhy interactive motion feels alive

An easing curve has a fixed duration: it always takes 180ms regardless of how far the element travels. A spring is defined by physics - stiffness, damping, mass - so its duration emerges from the motion and it carries velocity. That is why a dragged panel that you release feels right with a spring and wrong with a tween.

• Easing for discrete state changes: a menu opens, a toast appears. Duration is known, distance is fixed.
• Spring for anything continuous or interruptible: drag-and-release, a value that can be re-targeted mid-flight, gestures that hand velocity to the animation.
• Settle on a small easing vocabulary. A standard ease-out for entrances, a sharper curve for exits and one spring config for interactive motion covers most of a product.

FLIP: animate layout changes cheaplyFirst, Last, Invert, Play

FLIP lets you animate a layout change using only compositor properties. You measure the element's First position, apply the Last layout instantly, compute the Invert transform that visually places it back at First, then Play by transitioning that transform to zero.

1. 1First. Record the element’s box with getBoundingClientRect() before the change.
2. 2Last. Make the DOM change (reorder, resize, reparent) and read the new box.
3. 3Invert. Set a transform that maps Last back onto First, so it looks unmoved.
4. 4Play. On the next frame, transition the transform to none - the browser animates the delta on the GPU.

Measuring instead of guessingthe performance panel is the source of truth

Open the Performance panel, record an interaction and look for long tasks and a green-bar frame rate that holds at 60. Purple layout bars firing every frame mean layout thrash: you are reading geometry and writing styles in the same loop, forcing synchronous reflow. Batch reads, then writes.

The JD says it plainly: get experiences from 90% to 100%. That last 10% is almost entirely micro-interactions and states - the work most engineers skip and most users feel.

A button that works is 90%. A button that has a focus-visible ring, a satisfying active depression, a hover transition tuned to ~120ms, a hit target that extends past its visible bounds and a disabled state that explains itself - that is the 100% Cursor is paying for.

Interaction states are not optionalhover, active, focus-visible, disabled

Motion that masks latencythe gap between click and result is where polish lives

An AI editor is full of operations that take real time: a completion arrives, a diff applies, an agent thinks. You cannot make the network faster, so you manage the perception of waiting.

• Optimistic UI for reversible actions: apply the change immediately, reconcile when the server confirms, roll back visibly if it fails.
• Skeletons over spinners when you know the shape of what’s coming - a skeleton that matches the final layout reads as “almost there” rather than “stuck.”
• Entrance choreography so content does not pop. A 150ms fade-and-rise on arriving results turns a jarring snap into something that feels intentional.
• Honest progress for long operations: a determinate bar when you have real progress, a calm indeterminate state when you don’t. Never fake a percentage.

The states where magical is won or lostempty, loading, error, first-run

Engineers build the happy path and ship. The states around it are where craft shows, because they are the moments a user is most likely confused or frustrated.

Timing, choreography & reduced motionstagger with intent and honor the preference

When several elements enter at once, a small stagger - 20 to 40ms between items - reads as orchestrated instead of chaotic. Keep durations short: 150 to 250ms for most UI motion. Long animations feel slow on the tenth use even if they delight on the first.

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}
/* Better: keep opacity fades, drop large translates/parallax for
   users who get motion sick. Reduced motion != no feedback. */

Critique drill: find five improvementsthe skill the portfolio round tests

Take a real Cursor interaction - say, accepting an inline completion - and force yourself to list five concrete polish improvements. Not vibes, specifics you could ship.

• Tune the ghost-text fade so accepted text settles in ~80ms instead of snapping.
• Add a focus-visible ring to the accept affordance so keyboard users see the target.
• Stagger multi-line diff reveals by ~25ms per line so the change reads top to bottom.
• Give the reject path the same motion weight as accept, so dismissing never feels punished.
• Show a calm pending state while the model streams, not a spinner that implies a hang.

Prototyping is written into the role: rapidly prototype concepts to validate interaction and product ideas before committing to full builds. The skill is not building fast - it is building the right amount before you throw it away.

On an AI-native editor, interaction paradigms are still being invented. You cannot spec your way to whether a new diff UI feels good; you have to make it clickable and put hands on it. The 2-day in-person trial is, in large part, a test of exactly this loop.

Have a stack you can stand up in minutesthe cost of starting must be near zero

If spinning up a prototype takes an hour, you will prototype less and learn slower. Practice until a blank canvas is a two-minute command, not a project.

Fidelity disciplinematch fidelity to the question

Every prototype answers a question. Build only enough to answer it. Over-building is the most common prototyping mistake, because polishing feels like progress while it quietly burns the time you needed to test the idea.

Prototype-to-production judgmentwhat to keep, what to rewrite

Sometimes a prototype earns a path to production. Knowing what survives that transition is its own craft. The interaction model and the timing usually keep; the implementation usually does not.

Practice timed prototype sprintsrehearse the rhythm of the trial

1. 1Pick a question (5 min). State the single thing the prototype must answer. Write it down.
2. 2Scaffold (5 min). Blank Vite app running, fixtures in place, one screen rendering.
3. 3Build the hero (45 min). The interaction and motion that answer the question, nothing else.
4. 4Critique (10 min). Use it for real, list five polish gaps, fix the top two.
5. 5Present the decision (5 min). What you learned and what you’d build next - not a feature tour.

Cursor’s edge as a product is its interaction language for AI: inline diffs, tab prediction, agent surfaces. These patterns are young, which is precisely why a Design Engineer who can reason about them is valuable.

The throughline across all of them is trust and control. An AI is acting on the user’s code and the UI’s job is to keep the human in command - every AI action must be legible, reversible and dismissable without friction.

Inline diffs and accept/rejectmake AI edits legible and reversible

Reject deserves as much design care as accept. If dismissing an AI suggestion is slow or leaves the buffer altered, users stop trusting the feature and stop inviting the AI in at all.

Tab / ghost-text predictionlatency, dismissal and trust

Ghost text is a high-frequency interaction - it fires on nearly every keystroke - so its rules are unforgiving. It must be visually distinct from real code, it must never block typing and it must vanish the instant the user types something else.

Agent and chat UIsstreaming, tool calls, interruption, context

An agent runs over time and takes actions, which is a harder UI problem than a chat bubble. The user needs to follow what it’s doing, trust the steps and stop it the moment it goes wrong.

• Streaming so the user sees thinking arrive token by token - silence reads as a hang, even when work is happening.
• Tool-call surfaces that make each action visible: which file it read, what command it ran, what it’s about to change.
• Interruption as a first-class control. A stop button that actually halts the run, immediately, is non-negotiable for trust.
• Context display so the user knows what the agent can see. Hidden context is the fastest way to lose a user’s confidence.

Keyboard-first and command surfacesthe primary interaction model for power users

Developers live on the keyboard. A command palette is often the main entry point to functionality, not a fallback. Design it as a primary surface: fast fuzzy matching, discoverable shortcuts shown inline and a flow that never forces a reach for the mouse.

The bridge between design and engineering runs both directions. You translate Figma into pixel-perfect code and when implementation reveals a flaw the design tool couldn’t show, you propose the fix.

Faithful translation starts with reading Figma like a system, not a picture. Auto-layout maps to flexbox and gap; constraints describe responsive behavior; variants are your component’s state matrix; tokens are the values you should never hardcode.

Reading a Figma file structurallyauto-layout, constraints, variants, tokens

Match exactly, then improve where code canfidelity first, judgment second

Get spacing, type and color exact before you get clever. Pull the real values, don’t eyeball them. Then apply the things a static design tool literally cannot express, because that is where code adds value the mockup couldn’t.

• Real interaction states - hover, focus-visible, active, disabled - that the frame only hints at.
• Motion and transitions between the states a designer drew as separate frames.
• Fluid behavior across viewport and density that fixed-width artboards can’t represent.
• Edge cases: long strings, empty data, RTL and the dark-mode pairing of every token.

The bidirectional bridgewhen code reveals a design flaw, propose the fix

Implementation surfaces problems Figma hides: a layout that breaks at a real string length, a contrast ratio that fails in dark mode, a transition the static frames implied but never specified. The Design Engineer doesn’t silently “fix” it or rigidly ship the broken spec - you raise it with a concrete proposal.

Tokens as the single source of truthone definition, two consumers

When Figma and code drift, every screen becomes a negotiation. Keep design tokens authoritative - color, spacing, type, radius defined once and consumed by both the design tool and the codebase, ideally via an export pipeline so a token change propagates instead of being hand-copied.

1. 1Define once. Tokens live in a single source - a tokens file or a Figma variables set that exports.
2. 2Consume in both. Figma styles and CSS variables both reference the same names.
3. 3Change in one place. Update the token; Figma and code both move, no per-screen edits.
4. 4Guard drift. A renamed or removed token should break loudly, not silently mismatch.

Be ready to walk through a real translationthe portfolio round will ask

Have one Figma-to-code story rehearsed in detail: the frame you started from, the values you matched, the flaw implementation exposed, the fix you proposed and the polish you added that the mock couldn’t show. That single story demonstrates the whole bridge at once.