Why I Was Wrong About Scrollytelling Landing Pages
I spent years advocating for minimal static landing pages. One clear offer, clean layout, optimised for conversion. Every interactive scroll-driven page I saw felt like designers showing off rather than solving a business problem. Then the posts started appearing — someone building a 3D scrolling experience with Fable in five minutes, a prompt engineering setup that spits out a full scrollytelling demo overnight. My clients noticed too. They started asking for the same thing.
I pushed back. I lost the argument. I built a few.
Here's what I learned from those hands-on experiments.
The Viral Demos Don't Survive Contact with a Client
The first thing that caught me off guard was how fragile those viral demos really are. I tested every circulating prompt-and-skill setup I could find — the ones that dominate threads on every AI platform. One-shot output looks spectacular in a tweet or a Hacker News comment. Nobody in those threads ever has to revise the thing. The moment a client asks to change a single animation timing, swap out a section, or adjust the scroll trigger, the output falls apart. You're re-prompting, re-generating, re-editing blobs of code that were never designed to be touched. The impressive demos are impressive precisely because they were never asked to do real work. That's the gap between a proof of concept and a deployment-ready asset.
The Data Nudged Me
The second surprise hit closer to home. Dwell time and conversion rates on the scrollytelling pages I shipped actually outperformed the minimal static pages I would have argued for. I know the sample size is small — I've been burned
All Replies (3)
Complex features are a nightmare to explain. Did the undefinedB requests actually turn into qualified leads?
I'm terrified of tanking my Core Web Vitals. Which frameworks actually keep the page speed fast?