WebinsaneUX design
The reader holds the playhead.
In scroll storytelling the reader is also the editor. Every frame has to survive that.
The new webinsane.com is one long scroll that builds itself. A headline collapses into a white hole. Client names rise through the frame. A machine is assembled in pieces, a camera pulls back to reveal the hangar it stands in, and a frame is cut open down the middle. Most of it is rendered imagery, sequences of around a hundred frames per scene, driven by the scroll wheel.
Building it meant a month of UX decisions that rarely come up on an ordinary site. These are the ones I would make again, and the reasoning behind them.
Scroll changes who is editing.
In a film, the director decides when you see each frame. In scroll-driven storytelling, the reader does. They can stop anywhere, scroll back, or flick through five scenes in a second. That single fact rewrites the craft. A transition that only looks right in motion will be seen frozen halfway, so every frame has to survive being paused on. Every animation has to run backwards as cleanly as it runs forwards; a morph that cannot be scrubbed in reverse is a bug, not a style.
And the wheel needs smoothing more than the story does. We put the same small scrub weight between the wheel and every animation on the page, so the site has one feel throughout, rather than each section inventing its own idea of easing. Consistency of touch turns out to matter more than any individual effect.
The scenes are easy. The seams are the work.
Individual scenes are the straightforward part. The difficult part is the moment one scene hands the screen to the next. If the outgoing scene is still moving while the next one arrives, the reader sees a slide being pulled away, and the illusion is gone.
We solved it in two ways. Most sections are laid back over the previous one by exactly one screen, so each takes over on the precise frame the last one lets go and nothing visibly moves at the join. Where that is impossible, we cover the change with a single curved edge. It is the same shape, at the same rate, every time, so the reader learns it as the site’s own gesture rather than seeing five different effects. Even this journal arrives that way, and holds still while the next section rises over it.
Choreography is for looking, never for doing.
The contact section is the one screen on the site that is not a picture, and the one place we refused to pin. A pinned form is a form whose fields walk away from the caret: you click into an input, scroll slightly, and it slides out from under you. So the last section sits in the ordinary flow, and the transition into it is a clip on its own frame. The curve uncovers the page; once it fills the window, it is simply a page.
The general rule is the most useful thing I can pass on. Anything the reader has to operate stays still: a form, a menu, a link they need to hit. Motion is for the parts of the page that are being looked at.
A phone is a different film, not a smaller one.
A camera pulling back along the width of a landscape frame does not exist on a portrait phone. Rather than squeezing it, the narrow build was designed on its own terms: some scenes combine into a single portrait take, others become flat, readable pages. With reduced motion requested, nothing is pinned anywhere and the site becomes a document.
Treating these as first-class builds, each authored against its own reference frame, was considerably more work than scaling the desktop down. It is also the only reason the phone version feels decided rather than broken.
Loading is part of the choreography.
Five scenes of a hundred frames each make up most of the site’s weight. Load everything up front and the first visit is slow; load lazily and scenes stutter. The answer was to treat loading as another layer of direction. The preloader weighs assets by importance rather than counting files. Each heavy scene starts fetching two screens before it arrives, not when it is mounted. Narrow screens receive a lighter cut of the same footage, chosen once at load so the picture never changes mid-scroll. And the sequences are cached for a month, so a second visit costs nothing.
When it is worth it.
Scroll-driven storytelling earns its cost when the impression is the product: a studio’s own site, a launch, a flagship story, a brand that sells craft. It rarely earns it on a site people visit every day to get something done. There, the best motion is the motion you do not notice. And whatever you build, make sure the words can be read without it. That is the subject of Most readers never run your JavaScript.
The reader holds the playhead. Design every frame as if they are about to press pause.
Asked often.
What is scroll-driven storytelling?
A web design technique in which the scroll position drives animation, often through pinned scenes, frame sequences or 3D, so the reader advances the story by scrolling.
Is scroll-jacking bad for UX?
Overriding scroll speed or direction usually is. Scroll-driven animation that follows the reader’s own scroll, runs backwards, never pins interactive elements and respects reduced-motion settings can work well.
How do you make a scroll animation site work on mobile?
Design a separate narrow build against its own reference frame instead of scaling the desktop version, combine or flatten scenes that need a landscape frame, and serve lighter media.