Two missions at Hoora Games: rebuilding onboarding, then the design system
Hoora Games is a mobile gamification app. I came in for two distinct missions: first to redesign the onboarding, then to build the design system they didn't have. Each mission was its own product engagement; together they fixed both the activation problem and the velocity problem.
Context
Hoora Games builds gamification mechanics for mobile (daily rewards, streaks, missions, progression) designed to make engagement loops feel earned, not manipulative. Two product problems were holding the app back:
- Activation. Too many new users dropped off in the first 60 seconds. The hook of the game wasn't landing fast enough.
- Velocity. The team had no design system. Every screen was built from scratch, design and dev arguing over button corners on every PR.
Onboarding redesign
Diagnosis
The existing onboarding asked users to sign up, set preferences, and complete a tutorial before showing them a single reward. In a gamification product, that ordering is backwards: the dopamine has to come *before* the friction, not after.
- Behavioural audit of the existing flow, mapping every tap and the drop-off at each step.
- Competitive teardown of 8 reference apps (Duolingo, Habitica, Cash App rewards, Yuka) to identify the patterns that actually convert in the first 30 seconds.
- User interviews with new users running the existing app live. What did they expect, what did they get, where did they bounce?
Key insights
- Reward-before-signup converts harder than signup-before-reward. Every reference app that compounded did it that way.
- Tutorials don't teach gamification, playing one round does. The tutorial wasn't a learning surface, it was a friction surface.
- Personalisation should be inferred, not asked. Every question added to onboarding was a chance to lose the user.
Strategy & design decisions
- Reward-first flow. The first thing users see is a winnable reward, not a sign-up wall. Account creation is deferred until the reward needs to be saved.
- No tutorial. Replaced the tutorial sequence with a guided first round where the mechanics teach themselves through play.
- Inferred personalisation. Preferences derived from first-round behaviour, not asked explicitly.
Design system from scratch
The problem
Hoora had no design system: no tokens, no component library, no documentation. Every screen was bespoke. Designers reinvented patterns; developers re-implemented them. PR reviews turned into corner-radius debates. Iteration velocity was the bottleneck, not creativity.
Approach
- Tokens first: colour, spacing, radius, typography, motion. The foundation everything else inherits from. Built in Tokens Studio so design and dev shared the source of truth.
- Component library: buttons, inputs, cards, modals, list cells, reward animations, progression elements. Each component spec'd for states (default / hover / active / disabled / loading), variants, and dark-mode behaviour.
- Patterns and templates: reward screens, mission flows, profile, settings. The composition layer that turns components into screens.
- Documentation written in Figma alongside the components so designers and devs work from the same file. Decisions explained: what each variant is for, when *not* to use it.
Handoff & adoption
- Worked directly with engineering on naming and structure so the design system mapped 1-to-1 with the codebase.
- Set up a contribution model: any new pattern has to be proposed, reviewed and added to the library, never built one-off.
- Trained the team on the library in two working sessions, then let it run.
Outcomes
- Onboarding rebuilt around reward-first. First-session engagement materially improved on the cohort that received it.
- Design system shipped as v1: tokens, components, patterns, documented and adopted across the existing surfaces.
- Design and dev cycle time on new features dropped significantly. The corner-radius debates stopped happening.
Reflection
Two missions, two muscles. The onboarding work was a focused product engagement: diagnose, decide, ship. The design system was a different kind of design: durable infrastructure, no headline. Both matter. Doing them in sequence taught me how to switch between "solve the screen in front of you" and "build the foundation so the next 100 screens cost less." It's the lens I now bring to any team without a design system yet.