Rebuilding iRacing’s Sim UI

When we started this project in May 2022, the goal sounded relatively straightforward: modernize iRacing’s in-sim interface.

It quickly became clear that the problem went much deeper than visual design.

The existing UI had evolved alongside the simulation for roughly 15 years. It was powerful, deeply familiar to longtime users, and packed with functionality — but it was built on legacy technology that made even small interface improvements expensive.

UI work depended heavily on one of the company’s most specialized simulation engineers, which meant interface development competed directly with hardware integration other core simulation work.

What looked like a redesign became a multi-year migration of one of iRacing’s most mature product surfaces.

Role: UX & Visual Design Lead
Timeline: May 2022 – September 2025 for the initial release, with continued development afterward

The real problem wasn’t how the UI looked

The legacy interface showed its age visually, but replacing its appearance wouldn’t solve the underlying problem.

Years of functionality had accumulated inside a framework built around manually positioned controls, specialized implementation knowledge, and workflows that users had learned over more than a decade.

That familiarity had real value.

iRacing has an unusually experienced user base. Many drivers had years of muscle memory, deeply customized setups, and strong expectations around hundreds of small behaviors.

A dramatically different interface might have looked more modern, but it also risked making the product harder to use for the people who depended on it most.

So the broader strategy became migration before reinvention.

The initial migration strategy wasn’t something I originated. But as a design team, we had to decide where familiarity needed to be protected and where the legacy experience was actively holding users back.

For much of the product, that meant aiming for functional parity first.

Preserve what users depend on. Improve what genuinely needs to change.

That principle shaped most of the work that followed.

Building a new system underneath a mature product

The migration touched nearly every surface inside the simulation.

I helped establish the visual and interaction language for the new UI: typography, spacing, input patterns, hierarchy, panels, dialogs, component states, dense data presentation, and the hundreds of smaller decisions required to make the product feel cohesive.

iRacing presented an unusual design-system problem.

This wasn’t a conventional consumer app where generous spacing and large controls were always desirable. The simulation frequently needs to expose a large amount of information in very limited screen space — sometimes while the user is actively driving.

The system had to balance:

• clarity with information density

• consistency with highly specialized workflows

• modern interaction patterns with years of muscle memory

• ordinary users with extremely sophisticated power users
  
  

Early in the project, much of that work was intentionally conservative.

We were replacing the foundation first.

But as the new UI matured and reached real users, the migration started revealing places where parity was no longer enough.

When parity made the Camera Tool worse

One of the clearest examples was iRacing’s Camera Tool.

The underlying feature was incredibly powerful.

It was used for screenshots, filmmaking, replays, and professional broadcasts. Over the years, it had gained support for things like camera groups, automatic tracking, start and end points, microphones, damping, focus, exposure, field of view, and specialized camera behaviors.

But the interface reflected the way the system had been engineered rather than the way someone naturally thinks about operating a camera.

Controls used language like positional offsets, pitch, yaw, roll, and near-plane bias.

New functionality had been placed wherever space was available.

And the entire tool was effectively hidden behind a Ctrl+F12 keyboard shortcut.

Even some people inside the company didn’t know it existed.

I had unusually deep context for this part of the product.

Before moving onto the product team, I spent two years using the Camera Tool almost daily to create photography and video for marketing. Photography was also a longtime personal interest.

I understood both the system’s power and the pain of actually using it.

Our first pass was too faithful

Early in the migration, I recreated the Camera Tool inside the new design system with relatively minor organizational improvements.

Technically, we achieved parity.

In practice, we made the experience worse.

The legacy interface had fit a huge number of tiny controls onto one panel. Our new design system used more reasonable control sizes and spacing, which meant the same structure now required scrolling.

When the new UI reached Alpha testers late in development, their feedback was immediate:

The new Camera Tool was harder to use than the old one.

At a point when we expected to be polishing finished work, I pushed to reopen the entire surface.

That was a risky decision.

The Camera Tool was considered essentially complete, we were already in Alpha, and the project still had major stability and performance work ahead of it.

But shipping a more modern version of a worse experience didn’t feel acceptable.

Reframing the Camera Tool around the user

I redesigned the interface around the tasks someone was actually trying to perform rather than the underlying parameters used to implement them.

Technical coordinate systems became understandable actions.

Position X/Y/Z became directional movement.

Pitch, yaw, and roll became more familiar camera-aiming language.

Near Plane Bias became Clip Distance.

A hidden field-of-view interaction became explicit manual and automatic zoom modes.

I used photography terminology selectively. Terms like Aperture and Exposure already had strong real-world meaning, so we kept them. But where the camera metaphor made the simulation harder to understand, we broke it.

The simulation has a control that behaves somewhat like shutter speed, for example, but it isn’t actually modeling a physical shutter. Calling it Motion Blur made the outcome much easier to predict for an audience already familiar with that concept from prior gaming experience.

The goal wasn’t to make the software sound more like a camera.

It was to use whichever mental model made the behavior easiest to understand.

Keeping the power without exposing all of it at once

The legacy Camera Tool displayed almost everything simultaneously.

Instead, I reorganized the interface into meaningful sections and used progressive disclosure based on frequency and importance.

Position, aim, zoom, focus, exposure, aperture, and other common controls remained immediately accessible.

Professional broadcast features — microphone configuration, damping, specialized blimp behavior, and other advanced settings — remained fully available but no longer competed with the controls most people needed first.

We weren’t simplifying the product by removing capability.

We were separating complexity from confusion.

The final redesign shipped with the initial Sim UI release.

Since launch, new designers and broadcast-team members with little or no previous Camera Tool experience have been able to get productive with it quickly — a task that previously depended much more heavily on tribal knowledge.

Alpha testing changed what we thought “working” meant

Some of the most important feedback arrived when the project moved into Alpha.

Until then, much of our testing had been performed by the people building the product.

Engineering would finish implementing a feature, we would launch a test session, and we would confirm that it worked and matched the design.

That was useful implementation QA.

It wasn’t the same thing as using the product.

iRacing’s Alpha testers regularly run real races while simultaneously testing cars, tracks, damage, performance, and other simulation systems.

When the new UI became part of that environment, they were suddenly evaluating our work under the actual conditions it needed to survive.

And they pushed back hard.

One complaint came up repeatedly:

The driving UI was harder to read.

A racing HUD isn’t read. It’s glanced at.

Our first response was to simplify the visual hierarchy.

Several early widgets used borders, nested containers, surfaces, and decorative separation that looked completely reasonable while stationary.

At speed, those elements competed with the information itself.

We progressively flattened the drive UI, removed unnecessary containers, simplified grouping, and made the data carry more of the visual hierarchy.

That changed the way I thought about information density in the product.

A driver may only have a fraction of a second to understand a relative gap, fuel number, position, or warning before their attention needs to return to the track.

Styling that would be harmless in most applications can become a usability problem in that environment.

But even after simplifying the widgets, Alpha testers kept telling us something still felt wrong.

Finding a problem that was almost invisible

I compared the legacy UI, the new implementation, and the original Figma designs side by side.

The typography was extremely similar.

• Font sizes matched

• Weights were comparable

• We were using Inter

• Contrast looked correct

Nothing obvious explained the feedback.

Eventually, I zoomed into screenshots at the pixel level and noticed a subtle difference in how the new UI framework was rendering text.

The legacy interface and our design tools used grayscale anti-aliasing around the letterforms.

The new implementation introduced colored subpixel artifacts around light text on dark backgrounds.

At normal scale, the difference was barely perceptible.

But users were consistently telling us that the new interface required slightly more effort to parse.

When I first raised the issue, there was understandable skepticism that something so subtle could have a meaningful impact.

So I built a controlled visual comparison, isolating equivalent text treatments against matching backgrounds, and used that to demonstrate that the rendering difference was real.

That gave engineering enough evidence to investigate deeper in the stack.

The rendering fix was obviously well out of my depth, but my contribution of identifying the problem, demonstrating it clearly, and getting it in front of the engineers who could solve it meant we were able to quell many vague "it feels worse" comments.

After the fix shipped, the recurring readability complaints largely disappeared.

Legibility at 150 mph is a whole different ballgame.

That became one of the most important lessons from the project.

A design isn’t finished because it works in Figma.

It isn’t even finished because the implementation matches Figma.

The environment of use is part of the interface. With this being a new product surface design had never previously been allowed to touch, this lesson had to be learned in real time.

Collaboration at scale

Not every part of the project was an individual design effort and settings was probably the clearest example.

My teammate Jack led a substantial research initiative across the hundreds of settings inside the simulation.

He audited the existing structure, ran research, conducted card-sorting exercises, and developed a much stronger information architecture.

I then took that IA and designed the interface system around it.

That meant creating consistent patterns for hundreds of inputs, descriptions, states, dependencies, dense technical information, and workflows while keeping the overall experience understandable.

One smaller example was the control-calibration wizard.

The existing process worked, but it exposed too much of the system’s internal engineering model.

The redesigned flow focused each step on the physical action the driver needed to perform rather than the raw data being collected behind the scenes.

Turn the wheel.

Hold it at a specific position.

Press a pedal.

Confirm.

The simulation still collected the same information.

The user no longer needed to think like the software.

Settings was representative of the larger project: different people led different parts of the problem, and the quality of the final system depended on research, interaction design, visual design, engineering, domain knowledge, and constant collaboration.

The migration created an opportunity to think beyond parity

The decision to replace the legacy framework was a long term organizational goal. But as the new system matured, I started to realize how much more capable it could become.

We were no longer just asking:

How do we recreate what already exists?

We could start asking:

What could this interface become now that the old constraints are gone?

One of the clearest examples was UI customization.

The old interface had an edit-layout mode that allowed users to reposition elements on screen.

That worked when position was the only thing being customized.

But as the new system matured, users started asking for more.

• Per-widget opacity.

• Per-widget scale.

• More visibility controls.

• More individualized behavior.

The obvious solution was to keep adding controls directly to the existing edit mode. But I pushed back on that.

Every locally solved customization request would add more clutter and create another one-off interaction.

I used a metaphor internally:

Don’t build the houses before you build the road.

If we knew customization was going to grow, we needed a coherent place for those features to live before we started scattering them throughout the UI.

That thinking became the Widget Editor.

Building the road before the houses

The Widget Editor created a dedicated environment for configuring individual interface elements.

Instead of layering more controls directly onto the HUD, users could manage properties like size, opacity, visibility, and position in a system designed to scale as more options were added.

The concept was collaborative.

A game designer on the team brought useful knowledge of third-party tools like RaceLab and iOverlay, which had become popular specifically because some users preferred their overlays to parts of iRacing’s built-in UI.

Those tools helped us understand the level of customization power users had come to expect.

My focus was turning that need into something that could scale inside the product rather than becoming another collection of one-off controls.

The Widget Editor shipped in December 2025, only a few months after the initial Sim UI launch.

And it led naturally to the next question:

What if users didn’t just want to customize widgets?

What if they wanted completely different interfaces for different situations?

From widget customization to complete UI profiles

I looked to workspace systems in professional creative software, particularly Adobe tools.

Those products assume that different tasks need different arrangements of the same underlying interface.

That model mapped naturally to racing.

A driver might want one layout for an endurance race, another for rain, another for a specific car, and another for a completely different discipline.

That thinking became HUD Profiles.

Users could create named layouts, assign them globally or to specific cars, save them, share them, and switch between them depending on context.

The original migration gave us the technical foundation.

My contribution increasingly became recognizing where that foundation gave us permission to go beyond the product we had inherited.

Shipping the migration was only the beginning

The new Sim UI shipped in September 2025, more than three years after the project began.

For many projects, that would be the ending.

For this one, the most important outcome became visible afterward.

The migration had created a foundation the team could finally build on.

Within months, meaningful new UI capabilities began shipping regularly:

December 2025 — Widget Editor
Per-widget customization and new standalone widgets.

March 2026 — HUD Profiles
Complete interface configurations that could be saved, shared, assigned, and switched based on context.

June 2026 — Control Profiles and Fuel Calculator
A native solution to a longstanding power-user workaround alongside entirely new race-strategy tooling.

September 2026 — Continued expansion
New widgets and capabilities continued building on the same system.

That pace of development became one of the clearest measures of the project’s value.

Turning workarounds into product features

Control Profiles is one of my favorite examples.

Drivers frequently use multiple steering wheels.

A Formula-style wheel may have completely different buttons from a NASCAR-style round rim.

Under the old system, changing hardware could mean losing all of your useful control bindings.

Power users had already invented their own solution.

They manually copied, renamed, and swapped configuration files on their hard drives before launching the simulation.

In other words, the behavior users wanted already existed.

They were just implementing the feature themselves with the filesystem.

Once the new UI foundation existed, the product could finally make that behavior first-class.

That became Control Profiles.

It’s a small example, but it captures what the migration ultimately unlocked:

We could spend less time working around the limitations of the old interface and more time solving the problems users were already showing us.

From bottleneck to platform

The most visible outcome of this project is a modern Sim UI.

I don’t think that is the most important one.

We replaced a system that had accumulated over roughly 15 years while preserving the workflows that mattered to an unusually experienced user base.

Along the way, we learned where parity was valuable, where it actively made the product worse, and where real-world usage contradicted assumptions that looked perfectly reasonable in design tools.

My role evolved throughout that process.

I helped establish the visual and interaction system.

I owned major feature redesigns like the Camera Tool.

I collaborated on large research-led efforts like Settings.

I diagnosed implementation problems that crossed the boundary between design and engineering.

And once the new framework started proving what it could do, I pushed the product beyond parity toward a more customizable and extensible interface.

The migration strategy gave us the foundation.

The work that followed showed what that foundation could become.

We did so much more than modernize iRacing’s interface.

We helped turn the Sim UI from a product bottleneck into a platform the team could keep building on.