The onboarding was the drop-off, so I made the feature teach itself
LiveOps Campaign: a 1.5 month test that lifted new user engagement by 214% and opened a new revenue line
Role
Product Design Team Manager, sole designer
Industry
Health & Fitness / Growth and monetisation
Timeline
August 2024, 1.5 months from idea to shipped test
Scope
Feature concept, UX and UI, onboarding model, prototype
Platform
iOS, Android
Status
Shipped as a live test. Revenue hypothesis confirmed
In 60 seconds
Sweatcoin paid people to walk. Daily Boost was one of its core features, and around 30 million people were active in the app.
The company had a hypothesis worth money: that a partner would pay to sponsor an in-app activity, and that sponsoring it would push daily active users up rather than annoying them. Nobody had tested it.
I had 1.5 months, one PM, one front-end engineer and borrowed QA time to find out.
The design problem underneath was older than the project. Every feature launch at Sweatcoin opened with two or three full-screen onboarding modals, and every launch lost users to them. I proposed the opposite: no blocking screens, and a feature that teaches itself while you use it, borrowed from how RPG and MMO games hand out quests.
New user engagement rose 214% and returning user engagement 75%, both on iOS. Daily active users rose 7% month on month, and Nike saw 20% more leads than in the same sales period without the campaign.
The problem: a revenue hypothesis with 1.5 months to prove it
Sweatcoin made money from partners, but partners could only appear in the Marketplace, on a subpage, next to other offers. Reach was limited by the fact that people had to go looking.
The idea was to let a partner sponsor something on the home screen instead, attached to a behaviour people already had. If it worked, it created a new revenue line and lifted daily active users at the same time. If it didn't, we would have spent 1.5 months finding out cheaply.
Four goals, set with the PM:
Increase engagement with Daily Boost, for new and returning users
Increase daily active users by giving people a reason to come back
Validate that a LiveOps campaign could run inside the app infrastructure we already had
Test whether campaigns like this could be sold to partners later
The constraints were the interesting part. One developer. No dedicated QA, which I had to secure from another team as a manager, two weeks before the deadline, or the test would not ship. And we were not a formed team, we were three people who had not built anything together before.
What I decided, and why
Every launch was losing users to its own onboarding
This was the oldest problem in the product, and it had nothing to do with LiveOps.
Every new feature shipped with two or three full-screen modals explaining how it worked, blocking the user until they clicked through. We measured a meaningful drop rate on those screens, launch after launch. People were leaving before they saw the thing we had built for them.
I play RPGs and MMOs, and those games have solved this. They do not open with a manual. They put a quest marker in front of you and let you work it out by doing it.
So I proposed replacing the onboarding entirely with a learn-by-doing approach, and using LiveOps as the test case for it. No blocking screens. The user finds the campaign at their own pace, and the product leads them by the hand through action instead of explanation.
The work was less glamorous than the idea. It came down to placing the right starting points in the right places across the app, so that wherever someone encountered the campaign, they were pointed at the same next step. Consistency is what makes discovery feel like guidance rather than confusion.
What I gave up: certainty. A modal guarantees the user has at least seen the explanation. Learn-by-doing does not, and if the entry points are wrong, people simply never find the feature.
The people who want instructions still get them
Usability testing changed the shape of this decision.
I built a clickable prototype and ran tests, and the feedback pushed me away from an absolute position. Some people want to be told how something works before they touch it, and removing every explanation punishes them for that.
So the onboarding survived, as an optional page reachable from the progress tracker. It is there if you want it and invisible if you don't. That is the version that shipped, and it is a better decision than the one I started with.
Progress had to look like a quest, not a form
The tracker borrows directly from RPG quest logs. You can see where you are in the streak, what remains, and what waits at the end.
Two details carried more weight than their size suggests. The Boost Burst icon was animated and deliberately eye-catching, because the campaign had to be noticeable enough to be discovered without a modal announcing it. And a dedicated touchpoint let users check the campaign details and their own progress whenever they wanted, rather than only when the app chose to tell them.
Build it in the new design language, not the old one
We were mid-redesign. The new visual language existed but was missing many components, and the old one was complete and ready to use.
With 1.5 months on the clock, the safe answer was to build on the old system and ship. I chose the new one.
The reasoning was about what happens after the test succeeds. Building in the old language meant redesigning this feature again later, on top of every other screen already queued for the redesign. Choosing the new one meant I had to build missing components along the way, and it meant the test shipped in the direction the product was already heading.
What I gave up: speed, on a project where speed was the entire constraint.
Dark theme version of the app and liveops campaign feature
What shipped
The campaign mechanic
While a LiveOps campaign is live, completing five Daily Boosts in a row unlocks a partner reward. For the first test, Nike offered 30% off everything in their online store.
The home screen placement
Partners moved from a Marketplace subpage to the surface people open every day.
The progress tracker
RPG-style, showing position in the streak and what comes next, with campaign details on demand.
The optional onboarding
Available from the tracker, never blocking.
The Boost Burst icon
Animated, designed to be found rather than announced.
The results
In the product
New user engagement rose 214% and returning user engagement 75%, both measured on iOS.
For the partner
Nike recorded a 20% increase in key leads, comparing the same sales period with the campaign running against one without it.
For the business
Daily active users rose 7% month on month, comparing a month with a LiveOps campaign against a month without one.
The revenue hypothesis held. Nike got new customers and paid for reach into an app with around 30 million active users. Sweatcoin got partnership revenue, a measurable lift in daily actives, and evidence that these campaigns were worth selling.
And the user got something better than the usual reward. Daily Boost normally returns double sweatcoins. Here, finishing a five-day streak returned a real discount from a brand they recognised, which is why nobody inside the company or outside it read this as advertising. It was the core feature, branded, with a better prize at the end.
What I took from it
Test the idea before you can afford to be precious about it. We had 1.5 months, so the design had to be an argument that could be settled by shipping. Reusing Daily Boost instead of building something new is what made that possible.
Onboarding is usually a symptom. If a feature needs three screens of explanation before anyone can touch it, the problem is rarely that users are slow. It is that the entry points are wrong. Fixing the entry points is harder than writing the modals, which is why most teams write the modals.
Absolutes lose to usability tests. I went in wanting to delete onboarding entirely. Testing told me some people genuinely want it, and the version that shipped, optional and out of the way, is better than the one I argued for at the start.
Borrowed resources need a calendar, not a favour. The QA I needed belonged to another team. Securing it two weeks before the deadline was as much a part of delivering this as any screen I drew, and it is the part that would have sunk the test if I had left it late.