Ryan Timpany

Overview

The F1 Drive Vegas operations system was a desktop operations app designed for F1 Drive Vegas, a premium karting venue and part of the F1 family.

The app handled the staff-facing journey behind the guest experience, including booking data, waiver status, driver registration, session scheduling, live race management, kart assignment, timing data, race status, driver lookup and kart reporting.

The aim was to replace an older, unreliable and overly broad system with a tool designed specifically around the operational needs of F1 Drive Vegas. The previous system had been designed for location-based entertainment across different types of attractions, rather than for this specific karting venue and race-day workflow. It had also been added to repeatedly over many years, which made it clunky, difficult to use and poorly matched to how the ground staff actually worked.

The solution was designed to give staff a clearer, more reliable and more focused interface for managing the race-day flow from guest check-in through to live session control and post-race data.

---

Context

F1 Drive Vegas needed a more stable and operationally specific way to the complete guest experience, ticketing integration, managing sessions, drivers, race data and feeding track side displays.

The existing system was broad in scope and not designed around the exact use case of the venue. It supported location-based entertainment in a general sense but did not cleanly map to F1 Drive Vegas’ guest journey, booking flow, waiver process, driver registration, session formats, kart assignment or live race operation.

Because the old system had grown over time, it had become increasingly clunky. Features had been layered onto it over the years, rather than redesigned, leading to bloat. This created poor UX, poor UI, reliability issues, and friction for the ground staff using it during live operation.

The new system needed to support online booking, waiver completion, QR-based check-in, kiosk registration, staff verification, wristbands or tickets, safety briefing, pit lane checks, kart assignment, live racing and post-race results.

The solution was designed to mostly automate, without sacrificing operator control, this full journey. Without forcing staff to manually stitch together separate systems during a busy race day. Which they had been doing up to this point.

---

My Role

I created the wireframes, design document, user guide and finalised the UI.

My work included mapping the guest journey, defining the staff-facing operational flow, structuring the session management interface, designing the desktop wireframes, documenting functional requirements, and specifying how booking, waiver, driver and session data should appear to staff.

I interviewed and consulted ground staff, to understand what was not working with the old system, where the main pain points were, and what they wanted from a replacement.

Working in Figma, I was able to adjust the colours and visual style to bring the interface closer to the desired operational requirements.

A key part of my role was translating a complex venue operations problem into an intuitive, low friction, desktop interface. The app had to expose enough detail for staff to make fast decisions, while keeping the flow clear during live racing conditions.

---

Problem

The core problem was that the existing system was high friction, error prone and did not fit the specific operational needs of F1 Drive Vegas.

It was an off the shelf, broad location-based entertainment system. Designed to support a range of attractions and entertainment formats. That made it poorly suited to the precise flow of a high volume karting venue where staff need to manage bookings, waivers, driver registration, race sessions, kart assignment, live timing and post-race outputs in quick succession.

The system was also old and had been added to over time, while retaining legacy features. This made it clunky, difficult to navigate and unreliable. Staff had to work around the interface rather than being supported by it.

The guest journey itself was also complex. Guests could arrive through online booking, group booking, walk-in booking, corporate booking or venue buy-out. Some guests would complete their waiver online, while others would need to complete it at a kiosk. Some would arrive with a QR code, while others would need to be found by name or booking details. We had to anticipate the various edge cases.

Pit staff needed to know which drivers were valid for a session, whether their waivers had been completed, which karts were available, which session was live, what stage the session was in, and how race data was progressing. They also had to be able to intervene when races didn’t go according to plan.

The design challenge was to create a focused operational tool that matched the real venue workflow, reduced staff friction and improved reliability, clarity and speed during live operation.

---

Constraints

The interface needed to present dense operational data in a way that remained usable during live service. This included schedules, session states, driver lists, waiver status, kart assignment, live timing, session progress and reporting.

The design also needed to account for data coming from external systems. Booking and waiver data was expected to come from the external ticketing platform or related booking and registration flows. With the operations system receiving the driver data after check-in, redemption or waiver completion.

Manual workflows still needed to exist for fallback use, but they had to be clearly separated from normal booking-system-driven operation. The design therefore had to distinguish between live synced sessions and offline or manually created sessions.

The app also needed to reflect real staff behaviour. It could not be designed as a theoretical ideal flow that failed once guests arrived late, lost their QR code, had missing waiver data, or needed to be added or removed from a session.

---

Research and Discovery

I interviewed ground staff to understand the old system from the perspective of the people using it during live operation.

The research focused on three areas:

• What staff struggled with in the existing system
• Which parts of the workflow caused delays or errors
• What staff wanted from a replacement system

This revealed that the problem was not only visual polish. The old system was poorly aligned to the actual race-day workflow. Staff needed faster access to session status, clearer driver visibility, better waiver and check-in information, easier kart assignment, and a more obvious distinction between current live sessions and planning views.

After producing the proposed design, I reviewed it with ground staff for approval and input. This helped verify that the proposed structure matched how they expected to work during a race day. Another factor was anticipating and attempting to limit potential user errors. I constrained potentially harmful user actions, using locked states, confirmation steps and separated workflows to reduce operational errors during live racing.

---

Approach

I structured the app around the operational tasks staff needed to perform during a race day.

The main navigation focused on the core working areas:

• Schedule
• Live session
• Drivers
• Kart status
• Reports

The schedule view allowed staff to see bookings and sessions laid out in a calendar-style format, with session blocks showing time, package type, capacity and status. This was populated by booking data from the ticketing provider. I also designed a fallback system in case of the ticketing provider going down or network failure occurring.

The live session view focused on the current race state. It exposed staging, reset, start and end controls, alongside driver position, kart assignment, lap count, best lap and last lap data.

The drivers area supported lookup, profile review, waiver status, contact details, purchase details, session status and race history.

The kart status and report areas allowed staff to monitor kart usage, uptime, mileage or equivalent operational statistics, and export reporting data where required.

---

Guest Journey

The guest journey began with booking.

A lead booker or individual driver selected a package, time slot and number of drivers through the booking system. They received confirmation with a QR code and waiver link. Drivers could then complete registration online by adding their details, photo and waiver acknowledgement.

On arrival, staff could scan a QR code or use a manual lookup if the guest could not find their code. If the waiver had not been completed, the guest could complete registration at a kiosk.

Once the guest was checked in and their waiver was complete, a wristband or ticket could be printed with driver identity and session information. The operations system would then receive the driver data and make the driver available for session management.

At the pits, staff used the staff-facing desktop app to view the drivers for the session, allocate karts, confirm readiness and start the race session.

---

Staff Workflow

The staff workflow was designed around visibility and control.

Staff needed to see the day’s sessions, identify the current live session, open session details, review assigned drivers, check waiver and check-in status, assign karts, and then run the session through its operational states.

For live operation, the design separated staging, live racing, finishing and completed states. This helped prevent staff from treating all sessions as equal when only one session required immediate attention.

The design also supported driver lookup. Staff could search by name, email, booking code or session time, then inspect the driver’s profile, booking details, waiver state and race history.

This was important because real-world venue operation often involves exceptions: missing QR codes, late arrivals, incomplete waivers, extra guests or a driver needing to be removed from a session.

---

Session Management

Session management was the centre of the app.

The solution needed to support the active F1 Drive Vegas package structure, including Grand Prix, Family Sprint and Fastest Lap formats. These package types could contain different session types, such as practice, qualifying and race sessions.

Each session had operational states, including staging, live, finishing, finished and results.

The session interface needed to show:

• Session type
• Start and end time
• Capacity
• Duration
• Driver list
• Kart assignment
• Available karts
• Waiver and check-in state
• Live race status
• Lap data
• Best lap
• Last lap
• Session controls

This allowed staff to move from planning into live operation without changing tools.

---

Driver Management

The driver area gave staff access to driver-specific data.

A driver profile could include name, photo, date of birth, contact number, email address, booking details, waiver status, check-in status, live session status and race history.

The design also allowed for driver creation or driver editing where permitted, especially for fallback or offline workflows.

A key design decision was to keep driver lookup and session assignment distinct. Looking up a driver is not the same task as assigning them to a live session, so the interface needed to avoid mixing those actions in a confusing way.

---

Waiver and Redemption Logic

The design treated waiver completion and check-in status as critical gates.

Only drivers who had checked in and completed their waiver should appear in live session contexts. This prevented staff from assigning invalid or incomplete drivers to active sessions.

The redemption flow established that wristbands or tickets are printed during check-in and contain basic driver identity and session data but not kart assignments. Kart assignment remains the operations system responsibility.

This separation was important because it kept ticketing and registration aligned with the booking system, while leaving operational race control inside operations system.

---

Offline and Manual Operation

The system needed to support manual sessions when the booking system was unavailable, corrupted or unreliable.

Manual sessions had to be distinguishable from synced booking-system sessions. The design therefore treated offline sessions as a separate operational path, rather than quietly mixing them into the normal booking flow.

Manual session creation included creating a session, adding or selecting drivers, assigning session details and then placing it into the schedule.

This allowed fallback operation without undermining the normal source of truth from the booking system.

---

Key UX / Design Decisions

• Replace a broad location-based entertainment system with a focused F1 Drive Vegas operations tool.
• Base the UX on ground staff interviews and operational pain points.
• Review the proposed wireframes with ground staff for approval and input.
• Structure the interface around Schedule, Live session, Drivers, Kart status and Report.
• Use a calendar-style schedule to make the race day visible at a glance.
• Keep live session control separate from planning views.
• Make the current live session visually obvious.
• Treat waiver completion and check-in as gating conditions for session visibility.
• Pull valid driver data from the booking and redemption flow rather than relying on manual re-entry.
• Keep kart assignment inside the operations system application, rather than printing it onto wristbands or tickets.
• Support manual override workflows without making them the default path.
• Distinguish offline/manual sessions from normal synced sessions.
• Provide driver history and profile detail without overloading the live race interface.

---

Outcome

The F1 Drive Vegas operations system produced a complete staff-facing UX structure for managing the F1 Drive Vegas race-day journey.

The design replaced a high friction, ageing and overly general system, with a focused desktop interface designed around the venue’s actual operational needs.

The design connected booking, waiver completion, check-in, driver visibility, session scheduling, kart assignment, live timing and reporting into one coherent staff-facing tool.

The project also produced supporting documentation, including the design document, wireframes, user flows and user guides.

The solution required understanding a complex real-world venue workflow, interviewing the staff who used the old system, identifying the points where they needed clarity and control, and designing an interface that could support fast decisions during live operations.

The solution is currently in use and has successfully processed a high volume of race sessions. The app is now a product and will be available to other locations.