Case Study
YVR Digital Twin
A real-time digital twin of Vancouver International Airport — one shared source of truth, driven by live operational data.
Vancouver International Airport
A live digital twin of an airport.
One shared source of truth for many teams — common dashboards and a task system tied to a real-time map. Aircraft and ground vehicles stream live from their transponders, so every item on the map reflects the airport moment to moment.
Internal UI is under NDA — shown here is the public system overview.
My Role
Generic UX for every kind of user.
I was the UX designer on the project. My job was to create the interfaces and UX flows that surfaced this system for everyone — generic, wide-usage screens, layouts, and the design assets behind them, built to be picked up by any team across the airport.
Designing for Everyone
One interface every role can use.
The design had to stay generic enough to serve very different clients — and very different jobs. Baggage handlers, operations controllers, and the crews running the snow plows all needed a single common interface they could pick up and use.
The Reality
An airport is a bureaucracy.
It runs on interdepartmental politics — and internal wars over who owns the data. Getting a meeting, let alone alignment, was genuinely difficult.
So the Product Owner effectively became the client: they gathered and filtered input from across the airport, and we iterated to their bar — the fastest path through the politics to shipping.
What I Built
Dashboards built on decades of airport practice.
I created several dashboards and generic interfaces grounded in long-established airport workflows — some dating all the way back to the original Fitz boards. New surfaces, familiar logic, so staff trusted them instantly.
Style guide — placeholder
Drop the dashboard / style-guide image here.
Design System
One style guide. Figma tokens → Unity.
As sole UI/UX designer I owned the Figma style guide — the single source of truth across 10+ developers — and prototyped a pipeline exporting Figma tokens to Unity Scriptable Objects so screens stay themed automatically.
In Summary
What the digital twin was.
At its core: shared dashboards and a task system, joined to a real-time map of the whole airport — updating moment to moment.
The system, in one view
Role
Sole UI/UX Designer
Client
Vancouver Airport (YVR)
Surface
Web · Real-time twin
Note
NDA — process only
Overview
The YVR digital twin provides a real-time reflection of airport operations for multiple teams via a shared source of truth driven by live data. Because access to end users was limited, design decisions were made through data interpretation, system constraints, and operational scenarios.
Due to the sensitivity of the work and NDAs signed during my time at YVR, I'm unable to share internal UI screens. What I can share is how I worked — the process, the thinking, and the decisions that shaped the product.
System overview: https://youtu.be/VZvKgQT1FkU?t=347
Operational Context
Airport operations are always in flux, filled with surprises and interdependencies. The digital twin is an experiment designed to assist staff in managing their diverse responsibilities. It provides cutting-edge technology that alerts them to various challenges, like early arrivals and mechanical issues, helping them navigate the complexities of airport life right from their hands.
The system was fed by:
•Real-time sensors and automated signals
•Staff manually logging operational events
•Complex legacy airport systems (e.g., NAVCAN and other operational sources)
Key constraints:
•Real-time data accuracy and latency
•Conflicting operational needs across teams
•Legacy platform limitations and integrations
•High cost of errors, delays, and missed alerts
Production Approach
Working out a production rhythm came with real challenges. YVR was a factional organization, so direct access to stakeholders wasn't common and priorities often leaned toward shipping functional outcomes over polishing usability. With fixed timelines and quotas, the most iteration we could realistically do happened internally.
In practice, the Product Owner acted as the client: they gathered and filtered input from across the airport, and we iterated primarily to meet the Product Owner's bar — because that was the fastest way to align teams and get work out the door.
Detailed Process
•Product Owner creates a Jira ticket with high-level requirements and attached JSON/data
•I expand the ticket into a design brief (goals, constraints, edge cases)
•Wireframes and concept designs, iterated with the Product Owner (iteration point #1)
•Build fully interactive Figma designs
•Developer handoff and implementation alignment (iteration point #2)
•Scope trimming or plan adjustments to hit delivery deadlines
Style Guide
As the sole UI/UX designer, I owned and maintained a comprehensive Figma style guide — fonts, color system, tokens, components, and accessibility considerations (including contrast and color-blind support). It served as the single source of truth for the team and kept implementation consistent across 10+ developers. Some sections aren't shown here due to proprietary content; I can share the generic framework, but not the airport-specific designs.
Figma Variables to Scriptable Objects
At YVR, one of my main goals was to streamline the Figma to Unity pipeline so layouts could transfer with minimal manual cleanup. I researched and prototyped an export approach where Figma variables/tokens are written to a JSON file, converted into Unity Scriptable Objects, and then applied through lightweight components so UI elements — colors, images, and styling rules — could be automatically themed and kept consistent across screens.
I believe this approach is entirely achievable, and I wish I'd had the time to take it to full production. With today's AI-assisted tooling, this kind of pipeline is more realistic than ever — if I could push it this far within project constraints, a well-supported team can absolutely finish it end-to-end.