Gamification Modules to Increase Engagement

Discovery

After completing the research and benchmarking phase, I ran a prioritization exercise to map potential gamification mechanics by two dimensions: motivational depth (how much would this change behavior long-term?) and implementation complexity (how much dev work and admin configuration would this require?).

I mapped six candidate mechanics: spin wheels, daily challenges, member tiers, leaderboards, streaks, and goal-based progress.

The findings:

Spin wheels and daily challenges scored high on novelty but low on motivational depth, they create excitement once but don't build habits. Member tiers were compelling but required significant backend work and created the same 'intimidating to new members' problem as leaderboards.

Streaks and goal-based progress scored highest on motivational depth for both active and passive member types. Streaks work because they leverage loss aversion, breaking a streak feels worse than not starting one, which creates daily pull. Goals work because they give communities a shared direction, turning individual actions into collective progress.

Critically, both mechanics are non-competitive by design. A member's streak doesn't depend on anyone else's streak. A community goal includes everyone's contributions. This was a deliberate response to the research finding that competitive mechanics were alienating passive members rather than activating them.

One early question I couldn't resolve through research alone: should streaks reset completely after one missed day, or should there be a grace period? This became a key decision point during user testing.

Design Goals

1. Encourage daily and long-term participation through positive reinforcement.

2. Enable community admins to easily configure and customize gamification settings.

3. Maintain a simple, consistent interface aligned with Bettermode’s design system.

4. Ensure flexibility for future expansion (e.g., challenges, seasonal events).

Business Needs

• Increase overall community engagement metrics (daily active users, post frequency).

• Expand Bettermode’s product offering to attract and retain enterprise clients seeking gamification.

• Provide modular tools adaptable to various community types.

• Support Bettermode’s brand positioning as a flexible, all-in-one community platform.

Working with Stakeholders

This project had two distinct stakeholder groups with different needs and different relationships to the outcome.

The CX Director and Customer Success Manager were my primary internal stakeholders. Both came to this project with a strong point of view based on direct client conversations, they had been fielding requests for better engagement tools for months. Their input during the research phase was critical: Disha in particular flagged that several enterprise clients had mentioned Duolingo's streak mechanic by name in client calls, which validated the direction before design began.

I shared design progress through bi-weekly async Loom updates, with a structured review session at three milestones: after the UX flow was defined, after mid-fidelity designs were complete, and after the internal testing phase. This prevented the 'big reveal' dynamic where stakeholders see a finished design for the first time and immediately want changes.

One tension that emerged during the mid-fidelity review: the Customer Success Manager wanted to add a competitive leaderboard view alongside the Goal module, to satisfy enterprise clients who had specifically requested it. My research suggested this would undermine the non-competitive positioning of the module and potentially discourage passive members from participating. Rather than blocking the idea, I proposed a two-phase approach: launch without leaderboard to establish baseline behavior, then evaluate whether adding it improved or hurt overall participation. The PM agreed. The leaderboard was not included in the design.

The decision not to ship the product publicly came later in the process and is addressed in the Outcome section.

User Personas

• Community Manager: Seeks tools to keep members active and measure engagement.

• Active Member: Enjoys progress tracking and recognition for consistent participation.

• New Member: Needs motivation to stay engaged and feel part of the community early on.

Ideation

With the two mechanics confirmed, Daily Streak (rewarding consecutive daily activity with streaks and milestones) and Goal (allowing admins or members to set collective objectives visualized through dynamic progress bars), ideation shifted to how each mechanic would actually work at the interaction level.

For Daily Streak, the key design question was: what counts as 'activity'? Logging in? Posting? Commenting? Reacting? Setting this too narrowly (posting only) would create anxiety for passive members. Setting it too broadly (any login) would make the streak meaningless. Early designs explored a configurable threshold, letting admins define what 'counts' per community context, which later became a core feature of the admin setup.

For Goal, the central tension was individual vs. collective progress. Should a Goal track each member's personal contribution, or the community's total? We explored both and landed on collective progress as the default, it reinforces the community-as-team dynamic rather than turning Goal into a secondary leaderboard.

The one unresolved question from this phase: streak grace periods. Should missing one day reset everything? This couldn't be answered through design logic alone and was flagged as a user testing priority.

Facilitation

Before finalizing the two module concepts, I facilitated a 60-minute prioritization session with the CX Director and Customer Success Manager. The goal was to pressure-test the streak and goal concepts against real client scenarios before committing to the design direction.

I structured the session around three real client cases: a fitness community struggling with weekly engagement drops, a SaaS community trying to drive product adoption through peer discussion, and a gaming community with high initial sign-ups but rapid churn after two weeks. For each case, we asked: would Daily Streak solve this? Would Goal solve this? Would either make it worse?

The session produced two important outputs. First, we confirmed that both modules addressed at least two of the three client scenarios meaningfully, giving us confidence the solution was broadly applicable, not a niche fix. Second, we identified a configuration risk: if admins set streak requirements too aggressively (e.g., requiring daily posting rather than daily login), the mechanic could burn out active members rather than activate passive ones. This led to adding configurable activity thresholds in the admin setup, a design decision that came directly from the facilitated session, not from individual design judgment.

User Flow

1. Admin enables the module (Daily Streak or Goal) in a chosen space.

2. Module configuration: define rules, rewards, and timeframes.

3. Members engage in daily activities or community challenges.

4. Progress and rewards update automatically, visualized in real time.

5. Completion triggers a reward or badge and resets for the next cycle.

Designing Process

Using Bettermode’s design system, I created UI layouts for each module’s configuration and display states.
Once the UX flow was finalized, I used Cursor AI for rapid prototyping and Vercel for deployment and internal testing.
Throughout the process, I collaborated closely with the CX team to validate functionality and ensure alignment with client needs.
The design balanced clarity, motivation, and modularity, allowing both modules to integrate seamlessly into existing spaces.

User Testing Process

I conducted two rounds of internal usability testing.

Round 1, Admin configuration flow: 6 internal testers (3 from CX, 3 from Design) were asked to set up each module from scratch without guidance. The Daily Streak setup was completed without assistance by 5 of 6 on the first attempt. The Goal module was more problematic, 3 testers stalled at the 'contribution type' definition step because the options (post, comment, reaction, login) weren't clearly differentiated. This led to adding inline descriptions for each option and setting 'any activity' as the recommended default.

Round 2, Member experience: The same 6 testers switched roles and interacted with the modules as community members in a simulated environment. Streak progress visibility was the main feedback point, testers wanted to see their current streak count more prominently, not just in a profile section. This led to adding a persistent streak indicator in the community header for members who had an active streak.

One specific question carried over from the Discovery phase: the grace period decision. During the 2-week internal simulation, we tested a version with hard resets (one missed day breaks the streak completely). Two participants broke their streak mid-simulation and immediately disengaged for the remainder of the two weeks, they stopped checking in even on days they would have otherwise contributed. This was a small sample, but the behavioral signal was clear enough to act on. A configurable grace period (defaulting to one missed day allowed per 7-day window) was added to the admin setup and scoped for the next iteration. We didn't want to ship the hard reset version as the default.

Success Metrics

Because the modules were not publicly released, all measurement was conducted during internal testing rather than with live community members. This is an important caveat: internal testing can validate UX clarity and usability, but it cannot replicate the behavioral dynamics of a real community over time. Our metrics reflect what we could validly measure, not what we projected.

Usability clarity: Both modules passed internal usability testing with no critical failures. Setup completion rates and the specific improvements made are documented in the User Testing section above. The key outcome: both modules reached a state where they could be handed to a community admin without a guided walkthrough.

Simulated engagement behavior: We ran a 2-week internal simulation where 8 team members used the modules in a test community environment. Streak retention within the simulation was high, 6 of 8 participants maintained their streak for the full 2 weeks. However, we were cautious about extrapolating this to real communities: participants knew they were being observed, and the stakes of breaking a streak were essentially zero compared to a real community member.

The one metric that surprised us: During the simulation, two participants voluntarily checked the Goal progress bar multiple times per day, even on days when they had already contributed. This suggested the progress visualization itself was creating engagement independent of the reward, a finding we hadn't designed for explicitly, but that reinforced the importance of making progress visible in real time.

Key Insights

Non-competitive mechanics require deliberate design, not just the absence of competition. Removing a leaderboard isn't enough, the visual language, copy, and reward framing all need to reinforce that a member's progress is independent of others'. Early designs that used percentage-based goal progress ('you contributed 3% of the community goal') inadvertently created comparison pressure. Switching to absolute contribution counts ('you've made 12 contributions') removed this dynamic entirely.

Progress visualization drives behavior independent of rewards. The most unexpected finding from the internal simulation: two participants were checking the Goal progress bar multiple times per day even after they had already contributed. The bar itself was motivating, not just the reward at the end. This suggested that in a live community, making progress visible in real time might matter more than the reward structure.

Configurable defaults matter more than maximum flexibility. Giving admins full control over streak thresholds, goal types, and reward triggers sounds like the right approach. In practice, the admin configuration flow was the biggest usability hurdle in testing, 3 of 6 testers needed a second walkthrough because of too many options. The lesson: strong, well-reasoned defaults with optional customization would serve most community owners better than open-ended configuration.

Iteration and Improvement

The most significant iteration wasn't a visual change, it was a defaults change. After Round 1 usability testing revealed that too many open-ended configuration options were causing admin confusion, I audited every setting in both modules and assigned each one a research-backed default. Streak activity threshold defaulted to 'any activity.' Goal contribution type defaulted to 'any activity.' Reward type defaulted to 'badge.' The result in Round 2: admins who didn't touch the defaults still got a fully functional, sensibly configured module. Those who wanted customization still had it. This principle, opinionated defaults with optional depth, became a reference point I applied to subsequent design decisions on the platform.

Outcome and What Happened

The modules were designed, prototyped, and tested internally over the course of one month. The decision not to publicly ship them was not based on design failure, usability testing was positive and the internal simulation showed the mechanics working as intended.

The reason was prioritization. During the final review, the PM and product leadership determined that the engineering effort required to fully integrate the modules into the live platform exceeded what the current sprint roadmap could accommodate. The decision was to defer the public release to a future cycle, pending roadmap rebalancing.

This was a frustrating outcome at the time, but it reinforced something important: good design can be blocked by factors entirely outside the design process. The work was sound. The timing wasn't right. The designs and documentation are complete and ready to be picked up when the roadmap allows.

Planned features for the next iteration include team-based goals, seasonal challenges, and a configurable grace period for missed streak days.

Below are screenshots of these two gamification modules: