The graveyard of interaction design is not full of bad ideas. It's full of good ideas that lost information at each border crossing — from design tool to spec, from spec to ticket, from ticket to code, from code to QA. Each crossing quietly drops a detail: the easing that "was close enough", the 120-millisecond hold nobody documented, the stagger direction that got flipped. Individually invisible; together they are the difference between choreography and wiggling.
Stage 1 — Storyboard before you design
Immersive sites are shot, not laid out. Before any Figma frame exists, I storyboard the scroll as camera moves on paper: six to ten panels describing what the visitor sees, what travels, where the camera "rests". It takes an afternoon and it does two things no design file can: it exposes sequences that fight each other, and it gives the client something to approve that isn't pixel speculation. When someone later asks "can the hero also rotate?" you answer with panel four, not with a two-day experiment.
Stage 2 — The spec is a contract in milliseconds
The handoff document that survives is not a Figma link. It's a table. Every animation gets a row: trigger, property, from, to, duration, delay, easing, and — the row everyone skips — the landing (the exact scroll position or moment where the effect must resolve and stop). Ambiguous specs produce ambiguous code, and ambiguous code produces the mush that visitors feel but can't name.
hero-title split-chars y:110% → 0 900ms stagger 28ms easeOutExpo land: on load
work-card-02 depth z:-700 → 0 scrub by progress land: mid-viewport
showreel-frame scale 0.68 → 1.0 scrub by progress land: frame centered
cta-word zoomthrough scale:1 → 8 scrub by progress land: exit viewportFour rows, zero interpretation. A developer who reads that table can ship the motion without a single follow-up question — and QA can verify it without a design degree.
Stage 3 — Build the system before the scenes
The code equivalent of the storyboard is the engine: one scroll listener, one rAF loop, one place where progress is computed and written to custom properties. Scenes are then just CSS that consumes those variables. This is unglamorous plumbing, and it is precisely why studios that skip it end up with fourteen competing setIntervals and a main thread in cardiac arrest. Build the plumbing first, wire the storyboard into it second, and every future scene becomes a declaration instead of a hack.
Motion systems fail at the architecture level long before they fail at the animation level.
Stage 4 — The 60fps gate
Every animated page must pass a gate before it's called done: a mid-range phone, throttled CPU, real scroll, and the devtools performance trace open. The numbers I hold: main thread under 8ms per frame, zero layout thrash from animated properties, and compositor-only movement for anything that runs during scroll. If the gate fails, we cut effects before we throttle quality — a smaller film that plays smoothly always beats a bigger film that stutters. Visitors forgive restraint; they never forgive jank.
Stage 5 — Hand over the motion, not just the site
The last border crossing is yours to the client. Sites die in month four when a well-meaning editor adds a section that ignores the system. The cure is documentation as a living artifact: the spec table, the depth budget and the easing vocabulary shipped with the code, plus a forty-minute recorded walkthrough of the engine. Clients who understand the system extend it correctly; clients handed a black box will eventually fight it.
Do it in that order
- Storyboard the scroll as camera moves — get the film approved in an afternoon.
- Write the spec as a millisecond contract with explicit landings.
- Build the engine once; declare scenes against it.
- Gate the release on real-device 60fps, cutting before throttling.
- Ship the documentation with the site and record the walkthrough.
None of this requires talent. It requires refusing to let the idea degrade at each border crossing. That discipline — more than any easing curve — is what award juries are actually scoring when they click "next page" and the whole site moves like it rehearsed.