How to describe scroll-driven animation in a prompt

Triggered or driven

There are two different things people mean by scroll animation. A triggered animation starts when an element enters the screen and then plays on its own clock. A driven animation has no clock: its position is the scroll position, so stopping the scroll stops the motion and scrolling back runs it backwards. The second is what makes a page feel like one scene.

Say which you want for each moment. A page can use both: the scene is driven, and a caption inside a chapter can be triggered.

Pinning

Pinning holds an element in place while the page scrolls underneath it. The usual build is a tall wrapper with a sticky child that fills the screen; the wrapper's height is how long the pin lasts. Give that height in viewport units: 300vh pins for about two screens of scrolling beyond the first.

State what is pinned and what moves over it. In an immersive page the canvas is pinned and the text scrolls or fades across it. On phones, the browser's address bar changes the viewport height as it hides, so ask for the pinned element to use the small or dynamic viewport units and not to jump when that happens.

Progress from 0 to 1

Progress is how far through the pinned stretch the visitor has scrolled, as a number from 0 at the start to 1 at the end. Every moment is a slice of it: the lid opens from 0.3 to 0.5. Inside its slice a moment has its own local progress from 0 to 1, which is what drives the value.

Writing moments as ranges has two benefits. Overlaps and gaps are visible at a glance, and you can ask the tool to show the current progress on screen while you check each one against the list.

Easing and smoothing

Two different things soften scroll motion. Easing shapes a moment inside its range: ease-in-out so a turn starts and ends gently, linear for anything that should track the finger exactly. Smoothing is applied to the scroll value itself: the scene follows a number that chases the real scroll position and catches up over a fraction of a second, which hides the steps of a mouse wheel.

Ask for a little smoothing and name the amount. Too much and the scene keeps moving after the hand has stopped, which feels disconnected. Leave the page's native scrolling alone; smooth the value you read, not the scrollbar.

Reversibility

A driven scene must be a pure function of progress: the same scroll position always gives the same picture, whichever direction the visitor came from. That is the instruction to give. It rules out the common bug where a moment that was triggered on the way down does not undo on the way up, or where jumping to the middle of the page with a link leaves the scene in its opening state.

Ask the tool to test it: load the page at the bottom, scroll to the top, and compare with a fresh load.

How it is built

You do not have to choose the mechanism, but it helps to know the options. A scene can read the scroll position in its render loop and compute progress itself, which needs no library. An animation library with a scroll plugin can do the bookkeeping; GSAP's ScrollTrigger is a widely used one. CSS also has scroll-driven animations for simple cases, though browser support varies, so check current support before relying on it.

For a WebGL scene, the first option is usually enough and adds nothing to the download. Under reduced motion, a driven scene should be replaced, not slowed: see fallbacks for phones and reduced motion.

A moment sheet to fill in

Scroll behaviour for this page. One pinned stage, driven by scroll progress.

Stage
- A wrapper 500vh tall containing a sticky element that fills the screen (use 100svh so it does not jump when a phone's address bar hides).
- progress = how far the wrapper has scrolled past the top of the screen, from 0 to 1, clamped.
- Smooth it: each frame, move the value used for animation 12% of the way toward the real progress.
- Everything on the stage is a pure function of that smoothed number. No timers, no one-way triggers. Loading the page at any scroll position must show the correct state.

Moments (each uses its own local progress, 0–1 inside its range)
1. 0.00–0.18 [what changes, from → to], ease-out. Copy: "[line]".
2. 0.18–0.42 [what changes, from → to], ease-in-out. Copy: "[line]".
3. 0.42–0.70 [what changes, from → to], linear. Copy: "[line]".
4. 0.70–0.92 [what changes, from → to], ease-in-out. Copy: "[line]".
5. 0.92–1.00 hold. Button: "[label]".

Copy
- Each line is HTML, [typeface] 22px desktop / 17px phone, colour [#hex], fixed lower left with a 32px margin.
- A line fades in over the first 15% of its range and out over the last 15%, moving 12px upward as it does.

After the stage, the page continues as normal sections.

Phones: wrapper 400vh; merge moments 3 and 4.
prefers-reduced-motion: no pin. Show the five moments as five still panels, each 80vh tall, with the same copy.

Debug: with ?debug in the URL, show the progress value to two decimals in the top-right corner, 12px mono, #ffffff on #000000.

Stack: Vite + React + TypeScript, plain CSS, no scroll library unless you need one; say so if you add it.

Run it, then load the page scrolled to the bottom and scroll up, and confirm each moment matches a fresh load.

Written for this page as a starting point; swap the parts in [brackets] for your own. The full prompt of each uberdesigner template is longer and specific to one finished design, and it is tested by rebuilding the template from the prompt alone.

Keep reading

• What makes a website immersiveDepth, continuity and response to input are what make a website immersive. What each means in a prompt, and the cases where you should not do it.
• A performance budget for 3D websites, written into the promptWhat to write into a prompt so a 3D or WebGL site runs: pixel ratio cap, draw calls, texture sizes, one render loop, and pausing when off screen.
• Fallbacks for phones and reduced motionWhat to ask for when there is no cursor, a weak graphics chip or prefers-reduced-motion: the three fallback tiers and a block to add to any prompt.

• Scroll storytelling
• 3D products
• Particles