Designing Streaks and Goals for Online Communities

Overview

I designed Daily Streak and Goal modules for Bettermode communities and built a working prototype with Cursor for internal testing. Daily Streak made repeat participation visible; Goal let members contribute toward a shared target. I worked with CX and Customer Success to define the rules, admin setup and member experience.

Status: Designed, prototyped and tested internally. Public release was deferred because platform integration did not fit the roadmap. The evidence in this case concerns usability and an internal simulation; it does not demonstrate a live retention improvement.

Daily Streak and Goal concepts for community members and administrators.

Understanding participation beyond power users

I reviewed activity in 12 communities across SaaS, fitness, gaming and professional networks. In that sample, fewer than 15% of registered members generated more than 80% of posted content, with a marked drop-off in weeks three and four. These patterns gave us a problem to investigate; they did not establish why individual members stopped participating.

I also reviewed 23 CX tickets and client feedback reports from the previous quarter. Owners wanted ways to encourage repeated activity. Leaderboards and badges helped them recognize active contributors, but competitive ranking was a less comfortable fit for members who rarely posted.

Client requests and participation needs used to frame the modules.

Patterns we considered

I compared daily progress, public reputation and cumulative rewards. The useful question was which pattern could fit a community’s participation rules without making competition the default. The examples below were design references, not evidence of how our modules would perform.

Choosing two mechanics with different jobs

I compared six directions: spin wheels, daily challenges, member tiers, leaderboards, streaks and goals. Streaks addressed a member’s repeat activity; goals made collective progress visible. We selected those two for the first iteration and left the other mechanics outside its scope.

With the CX Director and Customer Success Manager, I worked through fitness, SaaS and gaming client scenarios. One risk cut across them: requiring a post every day could turn participation into a chore. Another was making quieter members feel that they were failing a competition.

The candidate mechanics and trade-offs considered during discovery.

Three decisions that shaped the design

Configurable qualifying activity. A daily login and a daily post ask different things of a member. Administrators could choose which actions counted, with “any activity” as the starting default. That made setup easier while leaving the rule open to the community’s purpose.

Shared goals before individual ranking. Customer Success requested a leaderboard for Goal. I proposed starting with a shared total so that members could contribute without being publicly ranked. We deferred individual competition until we could evaluate the simpler version.

We prioritized shared progress over public ranking so members could contribute without being placed in competition.

Progress visible during normal use. Members needed to know what counted and how far they had progressed without repeatedly opening a separate panel. Internal testing led me to move the streak indicator into the header.

Connecting admin rules to member feedback

The flow began with an administrator enabling a module in a community space, choosing qualifying activity, setting a target or timeframe, and selecting a reward. The proposed member flow showed progress as qualifying activity accumulated, followed by the configured reward and the next progress cycle on completion. The working prototype simulated this experience for internal testing; live event tracking and reward delivery still depended on platform integration.

I designed the interfaces in Figma using the shared component system, then built a Cursor prototype deployed on Vercel for internal review. The prototype let us evaluate configuration and member feedback before committing to platform integration.

The working prototype let us test admin rules and member feedback before committing to platform integration.

Admin setup and the member progress flow.

Interface exploration and prototype development using shared components.

What internal testing changed

Two usability rounds involved six colleagues: three from CX and three from design. In the first round, five of six configured Daily Streak without assistance. Three stalled when choosing a Goal contribution type. I added inline examples and a default of “any activity,” then reviewed the revised experience in the second round.

The second round also asked the same participants to use the member experience. The streak was easy to miss inside a separate panel, which prompted the header indicator. These were internal role simulations, so the findings guided usability changes rather than validating customer demand.

In a separate two-week simulation with eight colleagues, six maintained a daily streak. Two broke theirs and disengaged. That raised a recovery question: should a single missed day reset all progress? We scoped a configurable grace period for a later iteration, including a proposed default of one missed day per seven-day window. It was not part of a public release.

Outcome and next validation

The project produced two designed modules, a working prototype and revised setup defaults. Product leadership deferred release because the engineering effort required for live integration exceeded the available roadmap capacity.

The next step would be a customer pilot that tests qualifying actions, missed-day recovery and shared goals in real communities. Repeat participation, contribution quality and continued use after a broken streak would matter more than prototype completion alone. Until that pilot, retention impact remains an open question.

Internal testing informed usability decisions. Retention impact still needed a customer pilot.

The gallery below shows the module interfaces.