OuiRace

A virtual race lets people run the same event from anywhere, on their own route, at their own time. The format grew fast and then hit a credibility problem. A runner on a flat course in mild weather posts a better time than a runner on hills in the wind, and the leaderboard treats them as equals.

I designed OuiRace from the ground up: the mobile app runners use, the web platform organisers use, the public site that sells it, and the brand that ties the three together.

Six problems came out of the research, and they stack. There was no central place to find virtual races. Environmental conditions made results unfair and runners knew it. Charity and corporate organisers had no purpose-built tools, so they ran events out of spreadsheets. Organisers could not reach beyond their own mailing lists. Runners finished a race and had nothing to share. Fundraising, which is why many of these events exist, sat in a separate system entirely.

OuiRace is three connected products. The mobile app tracks a run and applies an AI correction for terrain and weather. The web platform gives organisers branded event pages, registration and analytics. The public site carries discovery and promotion.

The design problem underneath all three is trust in the correction. A runner who does not understand why their time changed will not accept the leaderboard, so the result screen shows the correction as a breakdown and not a single adjusted number.

User Research

I interviewed runners, trainers, charity organisers, corporate wellness leads and race directors. I spoke with people who had participated in large-scale events like Memorun and those who organise local charity runs or team challenges for NGOs and companies. I used AI to synthesise across the transcripts and find where the segments contradicted each other, which is the part that mattered.

Runners and race directors wanted opposite things from fairness. Competitive runners wanted raw times, because a correction felt like someone else’s judgment applied to their effort. Charity organisers wanted heavy correction, because their participants are not athletes and a raw leaderboard discourages them. The product had to hold both, which is why correction is visible and explained.

Competitive Analysis

I benchmarked ten virtual and hybrid race platforms, with JomRun, Myles, Gerak and Strava as the closest comparisons. I used AI to structure and cross-reference findings across all 10 platforms quickly, mapping feature presence, audience focus, and monetisation models into a comparable matrix. None of them corrected for conditions, and none of them had fundraising built in. That gap defined the product.

Brainstorm

I ran co-design sessions in France with the team and with professional runners, working through needs, feature priority and the shape of the flows. Having actual runners in the room changed the priority order many times.

UX Flow

The hard structural question was the branch between runner and organiser. A person can be both, sometimes in the same week. I iterated the flow several times and tested each with beta users.

Wireframe and UX Flow Maps

I created these wireframes through many iterations, testing each flow with runners, trainers and organisers. Their feedback and the development constraints simplified some paths and cut others. The map here is an earlier UX flow version, and it guided the decisions we made before the final UI phase.

Iterations

Runners join a race from anywhere and track it by GPS, or they upload a GPX file afterwards. Both routes land in the same result screen. The correction reads weather, elevation and location data, then adjusts the finishing time. A runner who never watched that calculation happen has no reason to trust the number it returns, and that was the design problem I spent longest on. I built the result screens and the in-race feedback to show which environmental factors were applied and what each one did to the ranking, so the corrected time arrives with its reasoning beside it.

I used AI to rapidly prototype different explanation approaches: numerical breakdowns, visual weather indicators, plain-language summaries. Testing these quickly with beta users helped me find the framing that felt clear without feeling over-engineered, significantly faster than iterating screen by screen alone.

Branding

I built the identity from scratch: logo, palette, typography and the 3D mascot set. I used AI for mood-board variations and colour candidates, which let me put concrete options in front of the team early. The visual language was shaped by the business requirements and refined through close collaboration, ensuring the identity supported the product’s goals while remaining clear, consistent, and distinctive.

Final UI Design, mobile

Throughout the OuiRace design process, I iterated extensively on race discovery, fairness mechanics, and in-race feedback based on user testing with runners and race organisers. Each iteration focused on clarifying complex concepts like time correction and virtual race validation, reducing cognitive load, and making the experience feel motivating and trustworthy for users. The time correction screens were particularly challenging, users needed to trust a result they hadn’t seen calculated.

Web

Alongside the mobile app, I designed and developed a dedicated web platform where users can learn more about the app, its unique features, and the benefits it offers. The website also allows race organisers to create events and runners to register for upcoming races, providing a smooth entry point into the Racing App ecosystem.

The app is live now, and early partnerships are running with Memo Run and an Alzheimer’s support group, which is the charity use case the fundraising work was built for. The team is still refining against user feedback and performance data.