Introduction

Long story short

Gamtog is a Nantes-based startup born from a straightforward observation: for board game enthusiasts, finding other players and organizing a game night is surprisingly difficult. In 2021, Lonestone partnered with the project founder to turn that idea into a mobile application, from defining the value proposition through to deployment on the App Store and Google Play. My involvement covered the discovery and UX scoping phase: user interviews, needs analysis, product backlog definition, and wireframe design. The UI phase was then handled by Florent, before Lonestone's development team took over to build and ship the application.

Objective

How might we design a mobile application that makes it easy for board game enthusiasts to find other players and organize sessions, in order to build an active and engaged community around the game?

Roles
01 UX RESEARCH

UX Research (interviews, benchmark, proto-personas)

02 PRODUCT DESIGN (UX)

UX Product Design (backlog, prioritization, wireframes)

Problem Definition

Market research

The benchmark of existing applications revealed a poorly structured market in the board game segment: available solutions were either too generic (mainstream event apps) or too niche (community forums with poor usability). None offered a fluid experience covering player discovery, session organization, and profile-based personalization in one place. Analyzing user journeys on competing apps also revealed significant friction at onboarding and during event creation, two moments that are critical to adoption.

User research

I conducted six interviews across a range of profiles: casual players, regular players, frequent game night organizers, and a board game shop owner, with whom I spent an hour and a half exploring game categorization mechanics and the different ways of addressing player profiles. These conversations produced proto-personas and concrete use cases that directly fed into the backlog prioritization. Three insights shaped the work most significantly: the importance of qualifying the expected player level when creating a game night, a strong demand for private sessions among friends or family alongside public events, and genuine interest in features gravitating around the game experience more broadly, recommendations, shop discovery, alerts for new releases and local competitions.

Opportunities
01

Qualify game nights to better match players

A beginner and an experienced player don't share the same expectations or the same tolerance for a rough evening with strangers. Letting organizers specify the expected level was a prerequisite for good experiences and for users coming back.

02

Balance public and private use cases

Betting everything on open community features would have been a mistake. A significant share of usage happens among friends, family, or established groups. Treating private sessions as a first-class use case rather than a secondary feature was a key product decision.

03

Build the conditions for long-term engagement

Beyond session organization, interviews surfaced a desire for lasting connections between players: groups built around shared game preferences or location, friend leaderboards, participation in publisher-organized playtesting sessions. These engagement levers were as many reasons to return to the app beyond the first use.

Solution Design

Scope & prioritisation

Backlog prioritization was built around two distinct target profiles, beginner players and experienced players, with features designed to serve each without sacrificing the overall coherence of the experience. The priority features covered player and group search, creation and joining of both public and private sessions, in-app messaging to build connections before and after IRL meetups, support for long-format sessions like tabletop RPGs, and personalized alerts for new releases, conventions, and local competitions. Several appealing ideas were deliberately left out of the MVP to avoid overloading an already ambitious first scope.

Gamtog backlog prioritization diagram for beginner and experienced player profiles
UX — Flows, wireframes

Two flows concentrated the bulk of the design effort: onboarding and session creation. Onboarding was the moment where the app learned about the player, their favorite games, skill level, and preferences, to serve relevant content from the very first session. Getting it wrong would have meant a generic, low-engagement experience from the start. Session creation, on the other hand, needed to be reducible to a handful of taps: it is the engine of the application, and every point of friction in that flow translated directly into fewer game nights created and less activity on the platform. The nature of relationships between players, reciprocal friendships or one-sided follows, also received significant attention, as that structural choice determines both the social dynamics and the full feature set that flows from it.

Gamtog wireframes for onboarding and session creation flows
Visual Design & UI

The UI phase, which followed my involvement, was led by Florent in collaboration with the Lonestone team. It covered the full art direction for both the application and the Gamtog brand: logo, visual identity, typography, and illustrations, before being applied across all wireframes to produce the final app screens.

Gamtog app art direction and final UI screens
Implementation, QA & handoff

Development ran in two-week sprints, with demos at the end of each cycle to validate progress and catch issues early. Integration of the Board Game Geek API simplified game search and association with events, removing the need to build a proprietary database from scratch. Lonestone then supported Gamtog through functional testing and deployment on both the App Store and Google Play.

Results & Learnings

Results

The Gamtog app is now live on both the App Store and Google Play, which represents the tangible outcome of a project that started from an idea and an untested assumption. The discovery phase provided solid foundations for iterative development, avoiding the trap of building features on unvalidated hypotheses.

Learnings

This project brought me face to face with the full complexity of socially-driven applications. A seemingly simple question, like whether two players become mutual friends or one follows the other, carries deep implications for community dynamics, associated features, and the behaviors you are trying to encourage. That is not a design decision, it is a product decision with consequences that ripple across everything else. Working on engagement and retention levers, particularly around building groups and communities based on shared game preferences or location, also sharpened my understanding of what makes a community come alive versus staying empty. Moderation, finally, is a topic I would have addressed earlier in the project: the moment a platform is open to the public, the quality and safety of content exchanged between users cannot be treated as a secondary constraint.