Rebuilding Rewards During Platform Integration

Early in my time at the company, I was handed one of the more complex design challenges of my career: unifying the rewards systems of two simultaneous acquisitions, Redbrick and Simply Well, into a single core platform. The work went beyond reconciling technical differences in incentive models. Members were genuinely confused by caps, deadlines, and grouped win conditions, so clarity became just as important as consistency. Four rounds of user testing shaped an experience built around transparency, motivation, and trust.

I led the member-facing rewards experience as the primary designer, while also working with our internal Gen-Admin team to build and configure the programs for clients. That dual perspective, seeing both the member and admin side, informed how I approached the work throughout. Cross-functional partnership with product, engineering, and my design manager kept strategy and execution aligned across every round of testing and iteration.

The complexity here wasn't just integrating one new system, it was reconciling three: our core platform, Redbrick, and Simply Well. They shared similar reward groupings but diverged significantly in cap limits, campaign structures, default logic, prerequisite sequencing, and how progress was shown to members.Clients expected continuity. Engineering needed consistency. Leadership had scope constraints. Designing a unified framework that satisfied all three without fragmenting the member experience was the real design problem.

I partnered with a researcher to develop two personas that became the team's north star throughout the project. Rather than chasing a one-size-fits-all solution, Alex and Rebecca kept us grounded in the real spectrum of members we were designing for. From someone who just wants frictionless reward tracking to someone who resents being on the platform entirely.

We ran moderated usability sessions with five to eight newer platform users to understand:

• What was working
• Where confusion occurred
• How users interpreted reward rules

Early concepts explored different ways of communicating reward eligibility, deadlines, and completion thresholds. I focused on balancing clarity with a lightweight interface that wouldn’t overwhelm users with system rules.

Rounds 2 - 4 We followed the same structure: moderated usability sessions with five to eight participants, each round building directly on what the previous one exposed. We introduced different task completion flows, tested variations in how progress was surfaced, iterated on gating messaging, and refined how win conditions were communicated to members.

Some changes landed immediately and were carried forward unchanged. Others needed all four rounds to get right, each iteration revealing a new layer of friction that only became visible once the more obvious problems were resolved.

By the final round the experience had been tightened significantly, not through a single breakthrough but through the cumulative pressure of putting real users in front of the work again and again.

Problem: Users didn’t always understand what they were earning.

Solution: Clear reward labeling, Dedicated reward detail surfaces, More explicit incentive descriptions

Problem: Users didn’t understand how many actions within a group were required to earn a reward.

Solution: Explicit “win condition” messaging, Progress indicators tied to grouped actions, Clear threshold communication

Problem: Users who completed gated actions without finishing prerequisites were confused about why rewards weren’t issued.

Solution: Introduced a “Completed but Locked” state to acknowledge effort while clearly communicating remaining eligibility requirements.