Case study / UX Design & Research
Redesigning the cashback experience for Unibet Casino
Turning a manually operated, opaque loyalty reward into a transparent, automated experience — reducing customer support contacts by 42% and rolling out across four markets.
UX Design
User research
Content design
Automation
Multi-market
Casino
01 — Context & problem
A valuable reward that users didn't understand — and couldn't trust.
Unibet's cashback system gives Casino and Live Casino players a percentage of their net losses back each week — a genuinely valuable loyalty mechanic operating across Denmark, Norway, Finland, Italy, and Poland. But the experience around it had never been designed. It had just accumulated.
Users were automatically opted in with no clear explanation of how it worked. The calculation involved understanding the difference between bets and deposits, bonus exclusions, and market-specific minimums — none of which was surfaced clearly anywhere in the product. When users couldn't figure out whether they'd qualified, why their amount looked wrong, or when they'd be paid, they contacted customer support.
✎
Image placeholder — Old transaction history screen: complex, hard to calculate cashback from
The root problems
The CRM Manager manually sent cashback every Monday — a process prone to human error, delays, and occasional missed payments.
Users had no in-product visibility of their cashback status, upcoming payout, or calculation — creating anxiety and confusion.
To check their cashback, users had to navigate to the transaction history and attempt to calculate it themselves — which most wouldn't do.
Community forums and CS queues were full of the same questions: "Did I get cashback this week?", "Why haven't I received it?", "When will it be paid?"
The brief
"Automate the back-end of cashback — and use the opportunity to build a user experience that makes the reward transparent, trustworthy, and easy to understand."
As Product Design Manager, I led a cross-functional team of junior and senior product designers, UX writers, and user researchers across a six-month project — focusing initially on Unibet Denmark and MariaCasino Norway, where users are automatically opted in.
Objective
Replace a manual, opaque cashback process with an automated system and a transparent in-product experience.
Output
A dedicated cashback hub covering 9 use case states, rolled out across 4 markets — reducing CS contacts by 42%.
02 — Research
Three sources of evidence. One consistent signal.
Before designing anything, we ran a multi-strand research programme — combining quantitative signal from CS contact data with qualitative insight from user testing and navigational research. The findings were consistent across all three.
Method 01
CS contact analysis
UX Research Analysts reviewed cashback-related support contacts. The overwhelming majority were about the same three things: how cashback works and is calculated, when it's paid, and reports of missing or delayed payments.
Method 02
Community forum analysis
The Unibet Community showed users openly confused about cashback timing, qualification, and payment. Forum threads confirmed these weren't edge cases — they were universal points of failure in the existing experience.
Method 03
Content testing
We tested whether users understood how cashback works, the T&Cs, and the requirements — and benchmarked our explanations against those of competing online gambling sites. This shaped the language and structure of the new experience.
Method 04
Tree test
A navigational study asking where users expected to find their cashback transaction history. Results directly informed the information architecture — where the cashback hub sat within the account structure, and how to label it.
✎
Image placeholder — Community forum posts showing cashback confusion and CS contact themes
03 — User needs
Seven questions. One place to answer all of them.
In parallel with the research, we synthesised a definitive list of what users needed to know about cashback — in order of importance. This became the content brief for the entire experience. Every component we designed mapped directly to one of these needs.
01
What is the cashback system? — A plain-language explanation for users who don't know they're in it or what it means.
02
How does cashback work and how is it calculated? — Including the difference between bets and deposits, when periods run, and how to qualify.
03
Did I receive cashback this week? — A clear, personalised status — not a calculation users have to do themselves from transaction data.
04
When is my next cashback? — A specific date and time so users aren't anxious about missing a payment.
05
Cashback history — A transparent record of past payments with the calculation visible, so users can verify what they've received.
06
Terms & Conditions — Accessible but not foregrounded. Users want to check T&Cs when something feels wrong — not be confronted with them upfront.
07
How to opt out — A genuine option, clearly available, that builds trust even for users who don't use it.
✎
Image placeholder — Component mapping diagram: each user need mapped to its corresponding UI component
04 — The design
One component per user need. Assembled by research priority.
The design approach was deliberate: we created a dedicated component to address each identified user need, then let the research data determine their order and prominence on the page. Nothing was placed by instinct — every hierarchy decision was grounded in what users most frequently needed to know.
The cashback hub became a single, scrollable destination within the user's account — replacing the journey of navigating to transaction history, manually summing bets and winnings, and trying to reverse-engineer whether a payment was due.
✎
Image placeholder — Final cashback hub: "You've got cashback" confirmation state with breakdown
✎
Latest cashback tab — no cashback this week
✎
Latest cashback tab — cashback received
✎
History tab — past cashback periods
The calculation breakdown — total bets, bonuses excluded, total winnings, net loss, cashback earned — was surfaced directly on the page, removing the need for users to do any mental arithmetic or refer to external documentation.
✎
Image placeholder — Cashback calculation breakdown: bets, bonuses, winnings, net loss, cashback earned
05 — Use case coverage
Nine states. Every scenario a user could encounter.
One of the most demanding parts of the design process was mapping and designing every possible state a user could arrive in. Cashback is conditional — it depends on net loss, minimum thresholds, bonus status, and opt-in — meaning the same page had to work meaningfully across nine distinct use cases, each requiring its own content and hierarchy decisions.
Case 01
No cashback
User played but didn't meet the minimum net loss threshold to qualify.
Case 02
No activity — new user
User has no cashback history yet. First-time explanation of the system.
Case 03
No activity this week & had cashback
User has a history but didn't play in the current period.
Case 04
Opted out & had cashback
User previously received cashback but has since opted out — with a clear path back in.
Case 05
Opted out & no activity
User opted out and hasn't played. Re-engagement prompt without pressure.
Case 06
Maxed out
User has hit the maximum cashback ceiling for the period.
Case 07
Did not bet enough
User is in the system but below the minimum threshold — shown how close they are.
Case 08
Blocked bonus
Cashback unavailable due to an active bonus conflict — explained clearly without jargon.
Case 09
Delayed payment
System delay detected — proactive communication to prevent anxious CS contact.
✎
Image placeholder — Full 9-state use case matrix showing all scenarios side by side
Designing all nine states before any were built meant the engineering team had a complete specification from day one — no edge cases discovered in QA, no last-minute content scrambles for states the product hadn't anticipated.
06 — Key design decisions
Clarity over cleverness. Transparency over simplicity.
| Decision | Rationale | Alternative considered |
|---|
| Show the full cashback calculation on the page |
The single biggest driver of CS contacts was users not understanding why they received what they did. Making the maths visible eliminated the need to contact support to verify it. |
Show only the cashback amount — simpler, but fails users who question the figure and have nowhere to go but CS. |
| Dedicated cashback hub — not embedded in transaction history |
Tree testing showed users expected cashback information in a dedicated place under their account — not buried in transaction history where they'd have to calculate it themselves. |
Cashback section within existing transaction history — familiar location but requires user effort to interpret. |
| Proactive "delayed payment" state rather than silence |
When cashback was delayed under the manual system, users assumed it was missing and contacted CS. A dedicated delayed state — surfaced automatically — turns a support trigger into a reassurance moment. |
No delay state — the previous default, which generated unnecessary CS contact on every delayed payment. |
| Next cashback date shown prominently |
Research showed "when will I be paid?" was one of the most common questions. Displaying a specific date and time removes the anxiety that drives that contact entirely. |
Generic "every Friday" messaging — technically accurate but doesn't answer the user's actual question. |
| T&Cs accessible but not foregrounded |
Content testing showed that leading with T&Cs created distrust and confusion. Users want to understand the reward first — T&Cs are a reference document, not an introduction. |
T&Cs shown upfront before explanation — compliant, but damages comprehension and trust on first encounter. |
| Opt-out clearly available throughout |
Making opt-out easy builds trust — users who know they can leave are more likely to stay. Hiding it creates suspicion and, paradoxically, more opt-out requests via CS. |
Opt-out buried in settings — common pattern, but increases CS contacts from users who can't find it. |
07 — Outcomes & market rollout
Launched in Denmark and Norway. Rolled out to four more markets.
The experience launched first on Unibet Denmark and MariaCasino Norway — the two markets where users are automatically opted in and therefore most affected by the lack of transparency. The results were immediate and clear.
−42%
Reduction in customer support contacts related to cashback after launch
Primary success metric
9
Distinct use case states fully designed and specified before a single line of code was written
Complete edge case coverage
4
Additional markets added post-launch — Netherlands, Germany, and UK followed the initial rollout
Scalable from day one
The modular, component-based design made market rollout straightforward — each new market required only market-specific content and threshold adjustments, not a redesign. The architecture had been built to scale from the start.
🇩🇰
Launch market
Denmark
Unibet
🇳🇴
Launch market
Norway
MariaCasino
🇳🇱
Phase 2
Netherlands
Unibet
🇩🇪
Phase 2
Germany
Unibet
✎
Unibet Denmark — launched cashback hub
✎
MariaCasino Norway — launched cashback hub
08 — Reflection
What I'd do differently.
What worked
Mapping all nine use case states before any design work began. It forced the team to confront every edge case upfront — and meant the engineering spec was complete and unambiguous from day one. It's the single decision I'd replicate on every project of this kind.
What worked
Using CS contact data as a design input, not just a post-launch metric. Knowing which questions users were asking most frequently gave us a ranked content brief that was grounded in real behaviour rather than assumption. The 42% reduction post-launch validated that brief completely.
What I'd change
We focused the initial launch on Denmark and Norway — markets with automatic opt-in. In hindsight, running a lightweight design pass on the opt-in markets in parallel would have allowed us to learn from those users earlier and feed insights back into the phase two rollout rather than treating them as separate workstreams.
What I learned
The best transparency work isn't about adding more information — it's about surfacing the right information at the right moment so users never have to go looking. Every CS contact about cashback was a design failure. Eliminating 42% of them wasn't a metric milestone; it was evidence that the design was finally doing what it should have been doing from the start.
