Referral & Bonus Tracking
product design
interaction design
product strategy
Overview
Redesigned an underperforming referral program by reframing a delayed, conditional reward as a trackable lifecycle, pitching and iterating the concept with stakeholders, validating it through bilingual moderated testing, and shipping a phased rollout across three environments.
Tools
Figma, FigJam, Linear.app, Miro, pen and paper
Duration
~5 months
Outcomes at a glance
From hidden reward logic to visible progress
Turned referral from a copy-link action into a trackable reward lifecycle with visible states, progress, conditions, next steps.
From static page to dashboard
Designed the referral experience across web, mobile web, and app, including dashboard states, invite logic, bonus tracking, and inline conditions.
From unclear bonus ownership to explicit status
Made it visible who was invited, where each friend stands in the twelve-month earning period, and what still needs to happen before a bonus is paid.
From feature concept to shipped product
Scoped a live first version that delivered the core visibility layer while keeping nudge and advocate mechanics separate until backend, legal, and business questions were resolved.
From assumptions to tested refinements
Used moderated comprehension testing to confirm the lifecycle concept and simplify the areas that created friction: tab labels, payout states, sharing, and metric-card context.
From business risk to product rules
Translated stakeholder concerns into product constraints, including clearer tooltip logic and anti-spam safeguards for future reminder nudges.
Context
The referral program rewards existing users for bringing in new cashback users. The reward is conditional: a referred friend must collect 20 EUR in confirmed cashback within twelve months before either side receives the bonus.
Internal analytics and CRM feedback pointed to underperformance, but exact figures are confidential.
Challenge
The referral invite link already worked. The problem started after sharing.
Users had no way to see who had joined, whether cashback was progressing, who triggered a bonus, or when a referral would expire. Referred friends lacked guidance, while referrers contacted support to understand states the product itself did not explain.
This was not a visual refresh. It was a status, trust, and incentive-system problem.
Objective
Make a delayed, conditional reward understandable and worth acting on across twelve months, coherently across web, mobile web, and app, in a form engineering could ship without rebuilding what already worked.
Role
I owned product design and acted as interim Product Owner until February 2026, after which PO responsibilities were handed back while design and implementation support continued.
This covered the audit, problem framing, stakeholder pitching and alignment, process design, visual design from paper sketch to high fidelity, user research planning and moderation, iteration on findings, and implementation handoff.
Understand
Auditing the Legacy Program
Purpose
Before proposing anything, understand what was actually failing and why, from evidence rather than assumption.
Approach
I audited the legacy referral page and journey and combined it with support insight into the questions users were actually asking.
The pattern was consistent: confusion about status, uncertainty about whether anything was progressing, and contact with support to fill the gap the product left.
I modeled these findings into two journey maps, one for the referrer and one for the referred friend. This shifted the problem from a broad performance issue to specific breakdowns in trust, visibility, motivation, and status clarity.
Mapping the lifecycle
Invite → Accept → Earn → Motivate → Earn → Unlock Rewards Together
Support insight and the legacy audit, modeled into two journey maps.
The journey maps located the specific failure points: link suspicion, unclear conditions, no visibility after sharing, and a twelve-month silence with nothing to hold onto.
Simplified versions are shown.
Insight
The solution could not be another invite page. It needed to make the year-long referral lifecycle observable.
After sharing, users had no evidence of who joined, who was progressing, what still needed to happen, or when a referral would expire. The twelve-month delay turned the reward into a black box.
Define
From Journey Pains to User Stories to Flows
Purpose
Translate the journey map insights into a concrete definition of what each user needs the system to do.
Approach
The journey-map informed the creation of user stories across three roles: Visitors, Referrers, and Referred Friends.
Each story addressed a specific insight from the maps to be translated into user flows:
The Share flow with leave-intent handling, the dashboard flow with reminder and cool-down logic, and the two referred-friend flows through landing, sign-up, and bonus received.
User Flows
Share flow showing decision points for user and system.
Flow to complete the task of receiving a bonus.
Result
The user stories and flows translated the journey maps into concrete product behavior.
The system needed to:
preserve a visible record of every invitation
show friend's status, e.g.: registration, progress, success
explain the bonus conditions before the user shares
trackable 20 EUR threshold and twelve-month deadline
support reminders without creating spam pressure
give referred friends enough context to trust the invitation
This created the shared model for design, product, and engineering:
referral was no longer a single share action, but a set of states, decisions, and system responses that had to remain understandable across touchpoints.
Ideate
Iterating the Concept
Purpose
Build stakeholder alignment on direction before committing to high-fidelity design.
Approach
With the flows defining the required system behavior, I sketched the dashboard backbone: progress summary, bonus states, friend table, and entry-point placement.
I used the sketches to align stakeholders before high fidelity. The review confirmed the direction and surfaced two business-critical requirements: tooltips had to reduce support ambiguity, and reminder nudges needed safeguards against misuse.
I folded both into the concept before moving into detailed screens.
Rapid structering
The dashboard structure was established within the first concept sessions.
Sketched dashboard structure showing progress bar, summary metrics, and a friend table with end date, progress, and bonus columns, including the decision renaming the entry point to "Bonus & Friends.
Result
The sketch review confirmed the dashboard direction, but also surfaced two business-critical requirements before high fidelity: tooltips had to reduce support ambiguity, and the nudge mechanic needed safeguards against misuse.
I folded both into the concept before moving into detailed screens.
Decision
Pitch in low fidelity and iterate on business-risk feedback before investing in high fidelity.
Trade-off
An extra pitch-and-revision loop in exchange for stakeholder alignment and de-risked direction before expensive detail work.
Output
An iterated dashboard concept with stakeholder go-ahead, tooltip clarity and nudge safety addressed up front.
Design
High Fidelity, and a Mechanic That Emerged
Purpose
Turn the agreed concept into high-fidelity mockups that engineering could implement swiftly, is ready for testing and open for iterations.
Approach
I designed directly in high fidelity.
A deliberate choice, since the required patterns already existed in the live product, so working with them avoided designing something new that would force developers into more effort than reusing what was already in production.
The revision was not about reinventing the interface.
It was about making the program easier to understand, more actionable for users, more valuable for the business, and easier for engineering to implement and maintain.
Advocate tier mechanic
Their tension produced the advocate tier :
A progress-based mechanic that gives high-intent referrers a reason to keep going across the twelve-month earning period, instead of letting the relationship go silent after the invite.
High-fidelity mockups
The reviewed dashboard with summary metrics, history tab, progress tab and advocate section ready for user testing.
Result
Decision
Design in high fidelity using existing live patterns; let the advocate tier emerge from the user stories rather than forcing a motivation feature.
Trade-off
Less visual novelty in exchange for direct implementability and a motivation mechanic grounded in motivational user needs.
Output
Test-ready high-fidelity mockups, including the advocate tier, with a go-ahead to test.
Validate
What Users Understood, and What Changed
Purpose
Validate the lifecycle concept and identify friction before handoff.
Approach
I conducted and analyzed a moderated comprehension test with six platform users across German and English sessions, using think-aloud and semi-structured interview prompts.
The design was directionally validated.
Page purpose, the primary invite action, the in-progress-to-earned transition, the nudge mechanic, and the advocate tier were all understood, and no major trust concerns surfaced in the test.
However, the test also surfaced friction points that led to changes.
Results and iteration
Finding
Tab naming ambiguous; 4 of 6 expected the wrong tab
Share flow felt too complex; 4 of 6 expected the invite action to copy a link directly
"Partial Payout" read correctly in cashback context but not referral context
Top metric cards lacked context; 1 of 6 clear without scrolling
Design decision
Renamed to "Earned bonuses / Active bonuses"; reclassified buttons for affordance
Renamed to "Earned bonuses / Active bonuses"; reclassified buttons for affordance
Cut editable message flow; kept personalized link + generic referrer message
Added tooltip microcopy with explicit definitions to each card
Comparison of changes before (left) and after test (right).
Result
The test confirmed the core direction: users understood the referral lifecycle, the primary invite action, the bonus progression, the nudge mechanic, and the advocate tier.
The remaining issues were not conceptual; they were about wording, hierarchy, and interaction load.
Refinements from testing
Tabs
History / Progress
→ Earned bonuses / Active bonuses
States
cashback payout labels
→ specific referral states
Sharing
editable message flow
→ personalized link + generic referrer message
Metrics
unclear summary cards
→ improved labels + tooltip definitions
The test confirmed the direction and helped make the design clearer, lighter, and more specific to the referral context.
Deliver
Handoff, and a Phased Live Rollout
Purpose
Finish design for mobile and app. Prepare and present handoff to align management and engineering before supporting implementation.
Approach
At handoff, the full concept was aligned, but two mechanics were not yet ready to ship: the advocate tier needed business validation, and the nudge mechanic required backend and legal work.
To avoid blocking the release, I proposed a first-release version focused on the core user value: referral visibility.
This version kept the dashboard, inline conditions, friend progress, and bonus states, while deferring the mechanics that still depended on business, backend, and terms-and-conditions decisions.
Results and iteration
The shippable version is a deliberate reduction proposed at handoff, single table, no tabs, no advocate tier, conditions inline, shipped live so value lands while the in-question mechanics are resolved separately.
Before
Static link-copy page
No status or progress visibility
Conditions buried, encountered too late
Buried sidebar entry point
One generic environment treatment
No motivation across the earning period
Single undefined release
After
Three-state referral lifecycle dashboard
Defined states with badges, microcopy, progress bar
Conditions inline, directly above the invite action
Surfaced as "Bonus & Friends" in the user profile
Coherent web, mobile web, and app, now live
Advocate tier and nudge mechanic with anti-spam safeguard
Full design handed off; first-release version shipped live
Result
A static, status-blind invite page is now a live referral lifecycle. Users can see who they invited, where each friend is in the twelve-month earning period, and what to do next.
The full version, including the advocate tier and the full nudge mechanic, continues in backend and legal work.
Decision
Propose and design a shippable live version at handoff, deferring the functions still under business and engineering review.
Trade-off
Fewer features in the first live version in exchange for value shipping now and the full design preserved intact.
Output
Full design handed off; core version live across web, mobile web, and app as of May 2026.
Learning
Discovery needs sequence
The value was not in any single artifact. The audit, journey maps, user stories, and flows built a shared model of the problem before interface work began. Without that sequence, the redesign could not have improved, leaving the lifecycle invisible.
Stakeholder alignment shaped the product
The sketch review surfaced business risks early: tooltip clarity, support ambiguity, and reminder misuse. Addressing those before high fidelity made the design more shippable.
Mechanics should emerge from user needs
The advocate tier worked because it answered a specific gap: keeping referrers motivated across a twelve-month delay. It was not added as gamification decoration.
Shipping is part of design
The full concept was preserved, but the live release focused on the core visibility layer. Deferring unresolved mechanics allowed the product to ship without turning the roadmap into a blocker.
More works
Let’s talk.
Prefer a quick conversation? We can align on expectations, product context, and whether there is a good fit.
15 minutes