How a VOD platform cut its sign-up drop-off by 22%
Florent Dabernat
February 23, 2026
3 min read
In this article
A 68% drop-off rate at sign-up is a painful thing to see in a dashboard. Here's how a simple UX hypothesis, tested with concrete actions, brought that drop-off down within a few weeks.
The problem: a 68% drop-off
The context: a streaming platform where more than two-thirds of visitors who start the sign-up form abandon it before finishing. Yet the form wasn't particularly long. So the question wasn't "how do we shorten it," but "what's making people hesitate."
A high drop-off rate on a short form is rarely a length problem. It's almost always a trust or clarity problem about what happens next.
The hypothesis and the actions
The hypothesis: friction was coming from a lack of clarity around the free trial and data privacy. Users didn't fully understand what they were about to agree to, and that alone was enough to make them give up before the end.
Three actions were put in place:
- Cut the number of fields: the form went from four fields down to two (email and password only), with the rest of sign-up completed afterward.
- Rephrase the promise: the headline copy became "Cancel anytime," replacing a vaguer statement about the trial period.
- Add a reassurance block: a "What you get" panel was added next to the form, clearly listing the benefits included in the trial.
Don't make me think.
Steve Krug, summing up the goal of any sign-up interface in one sentence
Why these three actions specifically
Each action targeted a specific doubt identified beforehand: the field count targeted perceived effort, the rephrasing targeted fear of commitment, the panel targeted doubt about the value received. Fixing all three at once made it possible to address the problem from several angles without multiplying iterations.
The results
After launch, sign-ups grew by 18% and support tickets related to understanding the free trial dropped by 22%. Two metrics confirming that the problem was never the form's length, but the clarity of what it committed users to.
That logic, hypothesis first, action second, measurement last, is what structures most of the redesigns I run: you don't change a screen because it "doesn't feel right," you change it because you've pinpointed exactly what's blocking, and afterward you verify that the change actually solved the problem.
Frequently asked questions
-
How do you land on the right hypothesis before acting?
- By cross-referencing several signals: support tickets, session recordings, short user interviews. A solid hypothesis rests on at least two different sources, not a single hunch.
-
Should these changes have been tested before launch?
- Ideally yes, via an A/B test or a quick five-person user test. In this specific case, the strength of the hypothesis and the post-launch measurement were enough to validate the direction.
-
Is this kind of result reproducible on other forms?
- The principle is reproducible: reduce perceived effort, clarify the promise, reassure on value. The numbers themselves always depend on context and the initial level of friction.