Because you took away the one control they were sure of. Scrolling is the most practised gesture on the web. When a page changes what a scroll does, people do not read it as craft. They read it as the page being broken, and their first instinct is to try again, then leave.
We have this conversation with clients regularly. A competitor has a scroll-driven product story that looks extraordinary in a screen recording, and the ask is to do something similar. The recording is not the experience, though. The recording is one person scrolling at exactly the right speed with nothing else to do.
Our position is straightforward. Scrolljacking is usually a mistake, there is usability research behind that view, and the narrow cases where it works are narrower than most teams want to hear.
Scrolljacking is when a page overrides the browser normal scrolling behaviour. Nielsen Norman Group defines it as "a design pattern that changes the speed and, sometimes, the direction of scrolling on a web page". Scrolling one notch might advance a slide, pin a section, or move content sideways instead of down.
The key word is overrides. A page that animates something while scrolling normally is not scrolljacking. A page where your scroll produces a different amount or direction of movement than you asked for is. That distinction gets blurred in a lot of design discussions, usually in favour of whatever the team already wants to build.
It shows up most often on product launch pages, agency sites, and annual reports. It is nearly always introduced for a good reason, which is that someone wants to control the pace of a story. The problem is that the pace was never the designer to control.
It is unusually blunt. NN/g reports that "websites with scrolljacking exhibit significant threats to user control and freedom, discoverability, attention, efficiency, and task success". That is five separate dimensions of the experience, and the finding comes from usability testing rather than opinion.
The specific harms NN/g documents are worth knowing individually. Disorientation across most test participants. Excessive cognitive load when people try to read text inside a scrolljacked section. Severe frustration among goal-oriented users. Worse performance on mobile. Users interpreting the behaviour as a technical bug. And difficulty getting back to the top of the page.
That last one is the quiet killer. If someone cannot easily return to where they started, they have lost their bearings on your site, and the usual response to feeling lost on a website is to close it.
Notice who suffers most in that list. Goal-oriented users. The people who arrived knowing what they wanted, which on a commercial site is the segment most likely to buy. Scrolljacking taxes your best visitors hardest.
Occasionally, and NN/g is fairer about this than most critics. Their research finds it works best when it progressively reveals genuinely relevant information, has real functional value, uses a faster scroll rate so fewer interactions are needed, sits below the fold, and is balanced by normal scrolling elsewhere on the page.
Read that list as a set of conditions rather than a menu. All of them have to hold. A scrolljack that reveals real information but sits in the hero fails. One that sits below the fold but exists purely for atmosphere fails. Most implementations we see satisfy one or two conditions and none of the rest.
The strongest case is a genuine step-by-step explanation, where each scroll advances one step of a process or one feature of a physical product. There the motion carries meaning. The visitor learns something at each stage that they could not have got from a static image.
The weakest case, and by far the most common, is atmosphere. A hero that pins for three screens while type fades in and out is buying a feeling at the cost of everyone who wanted the pricing page. We say no to this one a lot, and we would rather lose that argument in a kickoff than in an analytics review six months later.
Because touch scrolling is direct manipulation. Your finger is on the content. When the content does not follow your finger, it feels less like a design choice and more like the device has stopped responding. NN/g found worse performance on mobile and recommends skipping scrolljacking on mobile entirely.
There is a mechanical reason as well. Momentum scrolling on phones means a flick produces a long, decelerating movement that the operating system controls. Intercepting that fights the platform itself, and the result on mid range devices is often visible stutter on top of the confusion.
Mobile also removes your escape hatches. On desktop a frustrated visitor can grab the scrollbar and drag. On a phone there is no scrollbar to grab, so a person who wants to skip your five screen story has no way to skip it. They only have the back button.
If your answer is to build the effect for desktop and disable it on mobile, that is a reasonable position, and it is what NN/g recommends. Just be honest that you are now maintaining two experiences and that most of your traffic is probably seeing the simpler one.
It can be, and there is a specific WCAG criterion about it. Success Criterion 2.3.3, Animation from Interactions, states that "motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed". It is a Level AAA criterion.
The reason it exists is not aesthetic. Motion of this kind can trigger real symptoms for people with vestibular disorders, including dizziness, nausea, migraines, and difficulty concentrating. The W3C guidance names parallax scrolling explicitly as a type of motion this criterion covers.
The escape route is a media query that has been well supported for years. MDN describes prefers-reduced-motion as detecting whether "a user has enabled a setting on their device to minimize the amount of non-essential motion", with the value reduce meaning they have. MDN lists it as Baseline widely available and notes it has worked across browsers since January 2020.
So there is no excuse for shipping a heavy scroll effect without honouring that preference. It is a handful of CSS, it has been available for years, and skipping it means a visitor who has told their operating system they get sick from motion gets your full experience anyway. Our wider guide to making a website WCAG accessible covers where this sits among the other requirements.
Build the same story with normal scrolling. Almost every effect a scrolljack delivers can be achieved with elements that animate as they enter the viewport while the page scrolls at the speed the visitor chose. You keep the choreography and give back the control.
CSS scroll-snap is the other honest tool. It nudges the page to settle on section boundaries without overriding how far a scroll travels, so a fast scroller still moves fast. It feels deliberate rather than restrictive, and it degrades to ordinary scrolling in anything that does not support it.
For the entrance animations themselves, CSS can now handle this natively without a scroll listener, which also means it runs off the main thread and stays smooth under load. We went through what is possible and where support currently sits in our article on scroll-driven animations and whether you can use them yet.
The design discipline is the same either way. Ask what each moment of motion tells the visitor. If the answer is nothing, the motion is decoration, and decoration should never cost someone control of the page.
Smooth scrolling libraries sit in a grey area, and we treat them with suspicion. Anything that adds easing or lag between your input and the page movement is altering the pace of scrolling, which is half of the NN/g definition. It is milder than pinning a section, but it is the same category of change.
The usual argument is that it feels more premium. In our experience it mostly feels premium to the person who installed it. Visitors who scroll quickly find the page lagging behind them, and people using a trackpad often notice a floaty disconnect they cannot name but do not like.
There is also a cost. Most smooth scroll libraries hijack scrolling in JavaScript on the main thread, which is exactly the work you want to avoid on lower powered devices. You are paying performance for a feeling.
Native CSS smooth scrolling for anchor links is a different matter and perfectly fine. Animating the jump to a section the visitor deliberately clicked is not overriding anything. They asked to go there.
Watch five people use the page with a real task. Not a demo, not a design review. Give someone a job, like finding what the product costs, and see what happens when they hit the effect. The findings NN/g documents will either show up in the first two sessions or they will not.
The specific things to watch for are scrolling that stops and starts, repeated scroll attempts, and any comment suggesting the page is broken. Users interpreting a scrolljack as a bug is one of the documented harms, and once you have seen it happen in a session it is very hard to argue the effect is worth it.
Analytics gives you the coarser signal. Compare scroll depth and time to first meaningful click before and after. If people are spending longer on the page and clicking less, that is not engagement. That is friction wearing a nice outfit. We wrote about that tradeoff more broadly in our piece on whether website animations help or hurt conversions.
If it is in the hero, yes, today. If it is below the fold, carries real information, and moves quickly, keep it but honour reduced motion and turn it off on mobile. If it exists because it looked good in a pitch deck, it is costing you your most motivated visitors.
The middle path is worth naming, because removing an expensive build is a hard sell internally. Keep the visual story and drop the interception. Let the page scroll normally and let the elements animate as they arrive. You will usually find the story survives intact and the complaints stop.
If you have a scroll experience you are proud of and a conversion rate that does not match, we are happy to look at it honestly with you. Send it over at phoenix.studio and we will tell you what we think is costing you, even if the answer is the part you like most.
Tell us where you want to go. We'll tell you how we'd get you there.