Valeo Racer

Overview

Valeo Racer ↗ is the first extended reality (XR) gaming experience designed to run inside a moving vehicle. Passengers (particularly kids on long trips) play on a phone or tablet connected to the car’s wifi, with the game overlaid onto a live video feed of the real road ahead. For Valeo, it was also a proof of concept: a way to show automotive and gaming partners what its AR software development kit could actually do.

My job was to go from a sketch on a Post-it to a working, playable prototype in two weeks.

The Starting Point

Most design projects begin with a user problem but this one didn’t.

Valeo’s innovation labs (the Carlabs ↗) sometimes operate on a techno-push model: the question isn’t “what do users need?” but “what can we do with what we have?” The group had built significant XR, AR, and VR capabilities, along with a rich array of vehicle sensor data (front and rear cameras, radar, lidar) and was looking for products that could put those technologies to work and generate revenue.

It was the first time in my career I’d worked under this kind of brief. As a designer, starting without a user problem to anchor to is disorienting. But it also opens up a different kind of creative space: one closer to innovation than iteration.

The Design Sprint

Everything started with a design sprint I organised and facilitated at the Créteil Carlab: four and a half days, 25 participants drawn from across Valeo’s teams. The goal was to explore what XR could look like in an automotive context and to generate concepts that made meaningful use of the vehicle’s sensor data.

I handled the full logistics: planning, materials, activities, pacing. Participants split into three teams, each pursuing a different concept direction. One of those teams landed on the idea that would become Valeo Racer.

To test the concept quickly, the team did something simple and effective: they got in a car, drove a short route near the Carlab, and filmed it. The footage went into Figma, and within hours they had layered on a game avatar and some basic game elements — enough to sketch the feeling of a Temple Run or Subway Surfers experience set against real road footage. Rough, but the idea was immediately legible.

At the end of the sprint, the team pitched to management. The concept was selected and greenlit as a real project.

Two Weeks to Make It Real

After the sprint, I took ownership of the concept and was given two weeks to build a functional prototype for user testing. No Figma mock, no clickable flow. Something people could actually play.

I’d never designed a video game experience before. I explored several prototyping options like Figma, ProtoPie, an After Effects video, but settled on Unity. I’d used it a little, some of the Carlab developers knew it, and it was the only tool that gave me real-time interactivity within the timeline I had. My credo for those two weeks: fake it until you make it.

The gameplay direction also needed a decision. I briefly explored other formats (puzzle games, platformers) but came back to the Temple Run model. It was intuitive, worked in portrait orientation, required only one hand, and translated naturally to a passenger context.

One constraint was non-negotiable throughout: the experience couldn’t distract or endanger the driver. Every design decision ran through that filter.

Building the Prototype

The core technique was straightforward in concept, fiddly in execution. I took footage captured by the vehicle’s front-facing camera and imported it into Unity, projecting it like a cinema screen in the game environment. Then I built the 3D elements (avatar, collectible coins, the path) and positioned the game camera low enough that the video read as the horizon. When it worked, the avatar appeared to run along the actual road in the footage.

The full experience ran to about a minute.

Worth noting: I wrote all the C# scripts by hand, the old-fashioned way getting help from forums, Stack Overflow and trial and error. No AI assistance. Two stressful, exhilarating weeks that taught me more about real-time development than I’d expected to learn.

The Testing Setup

Testing in an actual moving vehicle wasn’t feasible given the timeline. So I built a simulation. We set up a large screen and four chairs arranged like a car interior. I sat in the driver’s seat. The participant sat in the front passenger seat, controller in hand. We ran the game, observed, filmed reactions, and debriefed.

Filming the tests was a deliberate choice: the emotional reactions were as informative as the verbal feedback, and you can’t always catch them in notes.

Results

The prototype landed well, actually better than expected. Testers enjoyed it, but the clearest signal came from the corridor outside: colleagues were lining up at my desk to try it and post their score. A leaderboard appeared. Competitive energy emerged around something that had been a Unity file two weeks earlier.

My manager, who had been quietly skeptical about the Unity approach from the start, told me afterward that it had taken guts. I’ll take that.

The project went further than the prototype. I contributed to the patent filing for the technology, and Valeo Racer went on to be selected for key automotive markets in Asia.

Key Learnings

A few things stayed with me from this project.

The most important: technology and innovation matter, but they’re not what makes a game worth playing. Fun is. Gameplay is. The XR concept was technically impressive, but what got people lining up was the score chasing, the one-more-try feeling, the competitive instinct. That’s not a design artifact, it’s something you have to earn through iteration and play-testing, and it deserves as much attention as the technical architecture.

The second thing: functional prototypes are categorically different from clickable ones. A Figma prototype tells you whether a flow makes sense. A playable Unity build tells you whether something is actually enjoyable — whether it generates an emotional response. The quality of feedback you get is in a different league, and for innovation work especially, that gap matters enormously.