We increased registration-to-traffic ratio by 48% for STS, Poland's leading sports betting platform, by rebuilding a two-year-old sign-up flow that hadn't kept pace with the business.
We increased registration-to-traffic ratio by 48% for STS, Poland's leading sports betting platform, by rebuilding a two-year-old sign-up flow that hadn't kept pace with the business.
Platform
Android
iOS
Web
Team
Listing all 50+ people involved in the process is a challenge. The team included members of the legal, AML, marketing, brand, support and SEO teams, and of course web developers.
Team
Listing all 50+ people involved in the process is a challenge. The team included members of the legal, AML, marketing, brand, support and SEO teams, and of course web developers.
Team
Listing all 50+ people involved in the process is a challenge. The team included members of the legal, AML, marketing, brand, support and SEO teams, and of course web developers.
Timeline
September 2020 – May 2021
Timeline
September 2020 – May 2021
My role
As the Product Designer, I was the sole person responsible for making sure the final solution was a success.
Context
Context
I still remember what my manager said when he assigned me that project: „Please, don't screw it up."
We only had two designers at the time. This was our chance to show the company that UX was worth investing in - and the stakes were personal, not just professional. Most registrations happened on mobile - not the app, but a web view shared across platforms. Whatever I designed would eventually roll out everywhere. The scope was as big as the pressure.
The current registration process had remained unchanged for two years. At first glance, everything seemed to be in order. But it looked like it was built in 2012. With 1000+ daily sign-ups and a growing paid acquisition budget, the registration flow was the leakiest part of the funnel - and nobody had touched it in two years. It was time to fix that.
I still remember what my manager said when he assigned me that project: „Please, don't screw it up."
We only had two designers at the time. This was our chance to show the company that UX was worth investing in - and the stakes were personal, not just professional. Most registrations happened on mobile - not the app, but a web view shared across platforms. Whatever I designed would eventually roll out everywhere. The scope was as big as the pressure.
The current registration process had remained unchanged for two years. At first glance, everything seemed to be in order. But it looked like it was built in 2012. With 1000+ daily sign-ups and a growing paid acquisition budget, the registration flow was the leakiest part of the funnel - and nobody had touched it in two years. It was time to fix that.
Original version of the registration process
Original version of the registration process
Goals
Goals
We agreed on the main goals upfront, so we'd know exactly what to measure and whether the project was a success.
Some were obvious: increase conversion by 5-10%, reduce abandonment. Others were less expected - reduce fake data at sign-up (blocked promo codes, fake names), let users continue registration after leaving mid-session, and rebuild the whole thing in Angular so it could actually be maintained going forward.
The goal wasn't just a better-looking form. It was a system that could evolve.
We agreed on the main goals upfront, so we'd know exactly what to measure and whether the project was a success.
Some were obvious: increase conversion by 5-10%, reduce abandonment. Others were less expected - reduce fake data at sign-up (blocked promo codes, fake names), let users continue registration after leaving mid-session, and rebuild the whole thing in Angular so it could actually be maintained going forward.
The goal wasn't just a better-looking form. It was a system that could evolve.
Goals of the new registration
Research
Research
Any experienced designer would have spotted at least a dozen obvious issues immediately. It was that bad.
I started by interviewing every department that touched the registration flow. It surfaced problems I wouldn't have found in analytics alone.
Any experienced designer would have spotted at least a dozen obvious issues immediately. It was that bad.
I started by interviewing every department that touched the registration flow. It surfaced problems I wouldn't have found in analytics alone.
We also looked into some key stages of the process and found out some surprising information
We also looked into some key stages of the process and found out some surprising information
Some of what I found were pain points the company had quietly lived with for years - nobody's fault, just nobody's priority. I combined this with competitor analysis, local, international, and outside the industry, plus HotJar recordings and heatmaps of the existing form.
Some of what I found were pain points the company had quietly lived with for years - nobody's fault, just nobody's priority. I combined this with competitor analysis, local, international, and outside the industry, plus HotJar recordings and heatmaps of the existing form.
Solutions
Solutions
One thing per page
While I was looking into this, I had the idea of splitting the complicated form into a simple, multi-step flow - one thing per page. On mobile, where most registrations happened, cramming multiple fields onto one screen was part of the problem. Asking for one piece of information at a time meant less to process, less to abandon.
Making the rules easier to follow, not weaker
One idea I pushed early was lowering the password requirements - they felt outdated and unnecessarily strict. But after a few rounds with our new security officer, we didn't lower them. Instead, we made meeting them easier: live validation, clear feedback on which requirement was still missing, no more guessing why a password got rejected.
Not every good idea survives contact with security requirements. But the user experience didn't have to suffer because of it.
Bulletproofing the flow against errors
Users registering before a game starts are under time pressure. A cryptic error at that moment doesn't just frustrate - it loses the conversion entirely.
I mapped every possible error state by working directly with the support team - they knew exactly where users were getting stuck. Cross-referencing that with backend error codes meant no edge case was left unhandled. Every step had a clear, human recovery path.
How to ask users about the source of their money
Nobody wants to share their income source on the internet. But legally, we had to ask. My approach was to be fully transparent - explaining exactly why we needed it, what we'd do with it, and how it affected the user. No legal jargon, no hiding it in small print.
I also pulled analytics on all 12 answer options and sorted them by real-world popularity. Showing only the top 3 by default, with the full list expandable, meant fewer decisions, less friction, and users almost always chose one of the suggested options without needing to scroll further.
A step that could have killed the flow became one of the smoothest in the process.
Results
Results
A month after launch, the A/B test results came in - and they were better than I expected.
Results of the new registration
This is still my favourite project. Not because it went smoothly - it didn't. Legal requirements, technical debt, a skeptical marketing team, and a tight timeline all pushed back. But the solution outlasted every one of those constraints. Years later, the registration is still live with barely any changes. That's the measure I'm most proud of.
This is still my favourite project. Not because it went smoothly - it didn't. Legal requirements, technical debt, a skeptical marketing team, and a tight timeline all pushed back. But the solution outlasted every one of those constraints. Years later, the registration is still live with barely any changes. That's the measure I'm most proud of.
Learnings
This project taught me that the best solution isn't always the one you originally pitched. The password requirements were a good example - I was sure lowering them was the right call. I was wrong, and the security officer was right. Learning to let go of an idea when someone with better context pushes back was as important as any design decision I made.
It also taught me that compliance and good UX aren't opposites. The source-of-money step could have been the worst part of the flow - instead, being transparent about why we were asking turned a legal requirement into one of the smoothest steps in the process.
This project taught me that the best solution isn't always the one you originally pitched. The password requirements were a good example - I was sure lowering them was the right call. I was wrong, and the security officer was right. Learning to let go of an idea when someone with better context pushes back was as important as any design decision I made.
It also taught me that compliance and good UX aren't opposites. The source-of-money step could have been the worst part of the flow - instead, being transparent about why we were asking turned a legal requirement into one of the smoothest steps in the process.