YVR Digital Twin — Adam Van Dyck

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.