Skip to main content
ChicoFolio
Contact
Back to projects
Spillr icon

Case Study

Spillr

View repository

Spillr is a mobile conversation card game that turns choosing a deck, playing a timed round, and seeing the result into one connected experience.

TypeScriptReact NativeExpo
Role
Product design + mobile development
Outcome
A connected deck-to-result play loop with local progress.
Stack
TypeScript · React Native · Expo
01

Project Overview

Spillr banner
Project Overview
Spillr is a mobile conversation card game. This case study covers the completed journey from choosing a deck to playing a timed round, seeing the result, and returning to personal progress. The implemented flow includes deck selection, preparation, card play, results, streak feedback, saved statistics, play history, sound, and local notifications. It is a local-first experience, so the core round does not depend on a server or an online account. The product is designed to make a casual group activity feel quick to start, expressive while playing, and rewarding after each round.

Tech Stack

TypeScriptReact NativeExpo
02

Problem and Solution

Problem
More than a card list
Players need a clear topic, ready state, card action, and meaningful result
A round should connect to progress
Streaks, statistics, and history should carry the session forward
The core activity should stay local
A server or online account should not be required to play
Solution
Deck-to-result journey
Choose a deck, prepare, play cards, and receive a distinct outcome
Clear card choices
Answer, pass, or end the round from each card
Two-minute pace
Unanswered cards become passed when the timer expires
Progress after play
Completed sessions update streaks, statistics, and history
Local feedback
Sound, motion, and optional reminders support future sessions
03

Role & Responsibilities

  • Translating the supplied mobile screen direction into a connected play journey.
  • Building the interaction states for preparation, card flipping, answering, passing, timing out, ending a round, and leaving safely.
  • Connecting gameplay outcomes to streaks, statistics, and play history stored on the device.
  • Coordinating background music, sound effects, animated feedback, and local notification behavior across screens.
  • Handling incomplete states such as an empty deck, expired streak, denied notification permission, or a player leaving before finishing.
04

Design Process

Design Process
6 Principles
01
Principle
Start with the full user journey
Supplied visual references and a journey audit shaped consistent play, game, result, profile, and history screens
Consistency
02
Principle
Record every completion path
The last card, an early end, and a timed-out card all use one completion path
Flow
03
Principle
Keep outcomes consistent
The result screen and history timeline use the same outcome rule and story
Clarity
04
Principle
Coordinate sound with screen focus
Music follows the active screen and one-time guards prevent repeated result sounds
Media
05
Principle
Protect incomplete journeys
Exit confirmations and empty-deck feedback provide a safe way through interruptions
Resilience
06
Principle
Prefer predictable, emotionally coherent feedback
The round stays focused instead of adding more modes or settings than it needs
Experience
05

Key Features

01
Deck selection
A snapping carousel presents available decks and keeps the selected deck visually prominent.
02
Animated preparation
The chosen deck is introduced with progressive text, a themed animation, and a clear start action.
03
Timed card play
Players reveal one card at a time, answer it, pass it, or end the round. A two-minute countdown automatically treats an unanswered card as passed when time expires.
04
Protected navigation
Back actions are handled deliberately. Leaving an active round asks for confirmation, while the play screen offers an exit confirmation before closing the app.
05
Outcome feedback
Results distinguish an all-passed round, a round with no answers, a partial round, and a fully answered round. Each state has its own message and animation.
06
Daily streaks
A completed round updates the current streak, identifies the first play of the day, and shows a dedicated streak celebration when appropriate.
07
Progress memory
Cards played, cards answered, cards passed, and session history remain available on the profile and history screens.
08
Sound and motion
Lobby music, in-game music, result sounds, button feedback, Lottie animations, and confetti reinforce important moments.
09
Local reminders
Optional notifications are scheduled on the device, including reminders tied to the streak’s warning and expiry window.
06

Tech Stack

TypeScriptDefines the app behavior and data rules.
React and React NativeBuild the component-based mobile interface.
Expo SDK 54Provides the mobile runtime and native integrations.
Expo RouterHandles the screen-to-screen journey.
React Native ReanimatedDrives responsive motion and transitions.
Lottie and React Native Confetti CannonProvide animated preparation, result, streak, and celebration feedback.
Expo AVLoads and controls music and sound effects.
Expo NotificationsSchedules and cancels local device reminders.
AsyncStorage and Expo SecureStoreKeep gameplay data and the player name on the device.
React Native SVG and HugeIconsSupport custom visual elements and interface icons.
Figma referencesGuide the visual treatment of the mobile screens.
Android and Expo build toolingPackage the app for Android builds.
Groq APISupports question generation elsewhere in the app; it is not part of the gameplay and results flow.

The gameplay and results flow has no gameplay server, remote database, cloud backup, account system, or multiplayer service. Question generation is a separate online capability and is not required to play existing decks.

07

Challenges & Solutions

Keeping outcomes consistent

The result screen and the history timeline need to describe the same round in the same way. A shared outcome rule keeps the title, supporting message, animation choice, and timeline marker aligned.

Preserving progress without a backend

The app combines device storage for profile data, statistics, history, audio preferences, and streak state with secure device storage for the player name. Missing or partial saved data falls back to safe defaults.

Managing media across navigation

Music starts or lowers according to the current screen, and in-game music is stopped before result feedback begins. Sound effects use the saved volume levels and are guarded against accidental repetition.

Handling real-world interruptions

The flow covers timeouts, empty decks, hardware back actions, early exits, notification permission denial, and stale streaks instead of assuming every round reaches the ideal path.

08

Final Product

  1. 01

    The completed experience lets a player open Spillr, choose a deck, move through a short preparation moment, play cards at a steady pace, and receive a result that reflects what happened.

  2. 02

    The same round then becomes part of the player’s streak, statistics, and history, with optional audio and reminders supporting future sessions.

  3. 03

    The gameplay flow has no gameplay server, remote database, cloud backup, account system, or multiplayer service.

    Question generation is a separate online capability and is not required to play existing decks.

  4. 04

    Verification note: the available Android preview build targets ARM architectures and could not launch on the connected x86_64 emulator.

    The journey was therefore not physically verified in this environment. iOS, physical Android hardware, notification delivery timing, and every alternate result branch remain unverified.

09

Results / Outcome

Delivered outcomes
What the feature supports in practice
  • Confirmed: the implementation delivers a complete local play loop with clear player actions, a fixed round time, distinct result states, streak handling, saved progress, history, audio feedback, and optional device reminders.
  • The repository does not provide adoption, usability, performance, or business metrics, so no numerical outcome is claimed.
  • As a product interpretation, the connected feedback loop should make each round feel more complete and give players a reason to return, but that effect still needs user testing.
  • Verification note: the available Android preview build targets ARM architectures and could not launch on the connected x86_64 emulator.
  • Known limitation: the history screen’s “Passed” and “No Spilled” filters use the same incomplete-session category, so they do not yet distinguish those outcomes in the saved view.
10

Lessons Learned

Lessons learned
5 takeaways
Lessons learned
Lessons learned5
  • A short game benefits from one clear journey more than many disconnected screens.
  • Shared outcome rules prevent the result screen and saved history from telling different stories.
  • Local-first storage can support a meaningful personal experience without requiring an account, but it also limits recovery and sharing.
  • Audio and animation need the same lifecycle planning as navigation and data.
  • Build architecture must match the device used for verification; a successful package build is not proof of runtime behavior on every platform.