One interface for four kinds of campaign

Freedx needed a rewards product. That decision came from the CPO and marketing, not from me, and it came with a deadline.

I researched how the major exchanges handle rewards. Most of what these hubs do is common across the category: campaigns, tasks, progress, claims. Roughly the same shape everywhere. The differentiation sits in the remaining fraction, the mechanics specific to one platform, and we agreed to build the common version first and add ours after launch.

So this wasn’t a case of inventing a category. It was a case of organising one properly.

Campaigns vary on two axes.

How you claim. A by campaign campaign unlocks tasks in order, one at a time, and pays out once at the end. A task by task campaign lets you do tasks in any order and claim each one as you finish it.

How you join. Some campaigns you opt into. Others enroll you automatically.

Two axes, four combinations, one page. A user never sees the matrix. They just see a campaign that behaves a particular way.

The task list was the hard part.

Holding Period needs a duration and a countdown. Trading Streak runs up to seven consecutive days. Login Streak runs up to thirty. Eligible Pairs needs a list of qualifying trading pairs. First Deposit and App Login are binary, done or not done. And a general task type covers whatever marketing wants to run: verify your identity, refer a friend, complete ten trades.

Four different shapes of information across seven types. A progress bar suits a streak and is meaningless for App Login. A list of pairs suits one type and nothing else. Designed as separate layouts, the campaign page would have looked like several products stacked on top of each other.

The answer was one expandable card. Collapsed, every task is the same row: title, reward, status. The list scans. Expanded, each type shows whatever it actually needs.

The variation lives inside the card instead of fragmenting the page.

I designed every type at its maximum, a thirty-day login streak rather than a comfortable five, so engineering was building against the worst case rather than discovering it later.

Users don’t read campaign mechanics. The interface has to tell them which rules they’re playing by.

In a task by task campaign, each finished task shows a green Claim Now on the task itself. In a by campaign campaign, finished tasks show Completed, the next one unlocks, and only when everything is done does the banner’s reward display swap to Claim Your Reward.

Same card, different affordance. The button tells you when the money arrives, so nobody has to explain the difference.

Unclaimed rewards expire seven days after completion, so both types carry a countdown. It sits beside the banner CTA in a by campaign campaign, and as a chip on the task in a task by task one. Same rule, placed where the claim happens.

Some campaigns enroll users without asking. That was a business and marketing decision.

What I owned was the consequence: a user who never opted in still needs to understand what they’re in and why. Enrollment surfaces through the notification centre, and the campaign appears under Joined Campaigns on the hub home page, alongside campaigns they chose themselves.

Freedx-specific mechanics were deferred. The MVP shipped as a solid version of what the category already does, with the platform-specific features planned for after launch.

That was the right order. A rewards hub that works is more useful than a differentiated one that isn’t finished, and the differentiation is easier to design once there are real campaigns running.

When we were working through the task list, the three of us landed on a different model: clicking a task opens its own page. More room to present the task, cleaner information, nothing competing for space. I said I’d build it so we could compare.

What the build showed was that there wasn’t enough to fill it. A holding period is a duration and two progress bars. A streak is a grid. Even the most complex task types didn’t need a page. So I argued for keeping everything on the campaign page: a campaign is a set of tasks you’re working through, and the useful thing is seeing all of them at once, what’s done, what’s next, what’s still locked. The expandable card kept it in one place.

That holds as long as tasks stay this size. If a future type needs genuinely more room, the inner page comes back.

Built, shipped, and now live on the exchange.

I left Freedx shortly after launch, so I don’t have usage data to point to. What I can say is that the structure held: seven task types, two campaign types, and two ways of joining, running in one interface.