learn more about me~

Jerry Nguyen

learn more about me~

Raytheon
2 0 2 6

product design

product design

vr product

vr product

2026

2026

Raytheon Enhanced Airspace Visualization

Raytheon Enhanced Airspace Visualization

Rebuilding how investigators see the sky in 3D and VR.

Rebuilding how investigators see the sky in 3D and VR.

role

role

Lead Product Designer

Lead Product Designer

team

team

3 Developers, 2 Designers, 1 PD

3 Developers, 2 Designers, 1 PD

timeline

timeline

Jan 2025 – Jun 2026

Jan 2025 – Jun 2026

skills

skills

Product Design, VR/3D Design, Interaction Design, Systems Thinking, User Research, Unity, Figma, FigJam

Product Design, VR/3D Design, Interaction Design, Systems Thinking, User Research, Unity, Figma, FigJam

impact

Presented to Raytheon stakeholders. Demoed live at the Texas A&M Capstone Design Conference.

Presented to Raytheon stakeholders. Demoed live at the Texas A&M Capstone Design Conference.

I led the product design and key decisions across two quarters from defining the problem space all the way through a live stakeholder demo. This was a 0-to-1 build on a domain I had never touched before. I leaned into curiosity and made hard calls when the team needed direction.

I led the product design and key decisions across two quarters from defining the problem space all the way through a live stakeholder demo. This was a 0-to-1 build on a domain I had never touched before. I leaned into curiosity and made hard calls when the team needed direction.

0 to 1

0 to 1

full platform build

No prior product, no design system. I led design from a blank canvas, defining structure, making decisions, and shipping something real.

No prior product, no design system. I led design from a blank canvas, defining structure, making decisions, and shipping something real.

2 Quarters

2 Quarters

structured design process

Q1 for research, flows, and architecture. Q2 for iteration, testing, and polish. I owned the design timeline across both quarters.

Q1 for research, flows, and architecture. Q2 for iteration, testing, and polish. I owned the design timeline across both quarters.

6 Core

6 Core

design decisions

Don't compete with the scene. Surface data on demand. Trust the data above all. Six principles I defined that guided every feature call.

Don't compete with the scene. Surface data on demand. Trust the data above all. Six principles I defined that guided every feature call.

Live Demo

Live Demo

stakeholder presentation

Presented at the Texas A&M Capstone Design Conference and demoed live to Raytheon engineers and stakeholders.

Presented at the Texas A&M Capstone Design Conference and demoed live to Raytheon engineers and stakeholders.

the problem

Investigators were mentally building a 3D world from a flat screen.

Investigators were mentally building a 3D world from a flat screen.

Current air traffic control systems like STARS and ERAM display aircraft in 2D, altitude is just a number next to a blip on a screen. When something goes wrong, investigators have to mentally reconstruct what happened in three dimensions from flat data. That gap between what they see and what actually occurred in the sky is where mistakes in analysis happen.

Current air traffic control systems like STARS and ERAM display aircraft in 2D, altitude is just a number next to a blip on a screen. When something goes wrong, investigators have to mentally reconstruct what happened in three dimensions from flat data. That gap between what they see and what actually occurred in the sky is where mistakes in analysis happen.

cognitive overload

Investigators had to mentally reconstruct 3D spatial relationships from 2D data which is a process that's slow, error-prone, and exhausting under pressure.

missed vertical separation

2D displays represent altitude as a text label which are easy to miss, hard to reason about spatially. Near mid-air collisions involving vertical proximity are particularly difficult to analyze on a flat screen.

no shared context

Traditional tools are single-user. When multiple investigators or non-technical stakeholders need to understand the same incident, there's no way to share a live, spatial view of what happened.

time-consuming analysis

Calculating vertical separation and closure rates manually is slow and demands expertise that not every stakeholder has. The analysis process needed to become intuitive, not just accurate.

so we asked

so we asked

How might we give investigators a way to see incidents in three dimensions, so they can understand what happened, not just read about it?

How might we give investigators a way to see incidents in three dimensions, so they can understand what happened, not just read about it?

research

I was curious about a domain I knew nothing about, so I researched extensively.

I was curious about a domain I knew nothing about, so I researched extensively.

Aviation incident investigation wasn't something I'd ever worked near. I didn't know what STARS or ERAM were. I didn't know what a squawk code meant. So I read everything I could, talked to our RTX partner Omar, consulted domain experts like Brice, and spent time with flight analysts and incident investigators to understand their world before I tried to design for it.

What I kept hearing from investigators and experts:

playback control

"I need to be able to pause, rewind, and move frame by frame. The moment of the incident is never obvious on first watch."

fewer clicks, faster clarity

"Every extra click to identify an aircraft is a second I lose. In a high-stakes review, that adds up fast."

data on demand

"I don't need all the metadata all the time — I just need it instantly when I do. Clutter is the enemy of analysis."

comfort in VR

"If I get motion sick in the first five minutes, I'm not using it — no matter how accurate it is. Comfort isn't a nice-to-have."

design implication

Every insight pointed to the same thing: the UI should get out of the way of the data. I landed on a core principle early and held it across every feature decision. The airspace is the product and everything else should be invisible until needed.

design process

I made hard calls early so the team didn't have to debate them late.

I made hard calls early so the team didn't have to debate them late.

I started in FigJam where I mapped the full user flow before touching Figma. Storyboarding key investigation scenarios helped me understand the shape of the problem spatially. I ran a competitive analysis across FlightRadar24, OpenSky, and Google Earth 3D Airspace to find the gaps none of them were filling. Then I made a series of decisions that I knew would be uncomfortable but were necessary to ship something coherent.

I started in FigJam where I mapped the full user flow before touching Figma. Storyboarding key investigation scenarios helped me understand the shape of the problem spatially. I ran a competitive analysis across FlightRadar24, OpenSky, and Google Earth 3D Airspace to find the gaps none of them were filling. Then I made a series of decisions that I knew would be uncomfortable but were necessary to ship something coherent.

the hard decision: drop free movement as default

the hard decision: drop free movement as default

Comfort over control even when it felt limiting.

Early prototypes gave users full free-movement navigation in VR. It felt powerful but caused motion sickness within minutes. The 20ms motion-to-photon latency rule in VR means cybersickness isn't just discomfort but ends the session. I made the call to make teleport the default navigation mode and relegate free movement to a secondary option. Some team members pushed back but I held the position because the data was clear: comfort isn't a preference, it's a prerequisite.

Early prototypes gave users full free-movement navigation in VR. It felt powerful but caused motion sickness within minutes. The 20ms motion-to-photon latency rule in VR means cybersickness isn't just discomfort but ends the session. I made the call to make teleport the default navigation mode and relegate free movement to a secondary option. Some team members pushed back but I held the position because the data was clear: comfort isn't a preference, it's a prerequisite.

the hard decision: white UI on a dark scene

the hard decision: white UI on a dark scene

Don't compete with the scene.

There was a strong temptation to make the UI look like aviation software — dark panels, neon labels, the aesthetic of a control room. I understood the instinct, however the 3D airspace is already visually dense. I chose a dark, neutral gray panel with high-contrast white text that included collapsible metadata, and labels that appear only when selected. The UI sits in the scene without fighting it; working in urgent situations means that every pixel of interface is one more thing between the investigator and the incident.

There was a strong temptation to make the UI look like aviation software — dark panels, neon labels, the aesthetic of a control room. I understood the instinct, however the 3D airspace is already visually dense. I chose a dark, neutral gray panel with high-contrast white text that included collapsible metadata, and labels that appear only when selected. The UI sits in the scene without fighting it; working in urgent situations means that every pixel of interface is one more thing between the investigator and the incident.

first iteration

final iteration

first iteration

final iteration

the hard decision: flight trails always on

the hard decision: flight trails always on

Make spatial history visible without asking for it.

The team debated whether flight trails should be a toggle — off by default to reduce visual noise. I disagreed because an investigator shouldn't have to turn on the most important piece of information in the scene. Understanding where an aircraft came from is the entire point. I made flight trails always-on and adjusted the visual weight instead — thin, semi-transparent lines that don't overwhelm but are always present. The path is the story.

The team debated whether flight trails should be a toggle — off by default to reduce visual noise. I disagreed because an investigator shouldn't have to turn on the most important piece of information in the scene. Understanding where an aircraft came from is the entire point. I made flight trails always-on and adjusted the visual weight instead — thin, semi-transparent lines that don't overwhelm but are always present. The path is the story.

first iteration

final iteration

first iteration

final iteration

the hard decision: scrubber over custom controls

the hard decision: scrubber over custom controls

Leverage familiar patterns. Zero learning curve.

Early concepts had custom ATC-style timeline controls that were unique, domain-specific, and impressive-looking. But when I tested comprehension with people unfamiliar with ATC software, they fumbled, so I scrapped it. A bottom-anchored video scrubber maps to muscle memory that everyone already has. Investigators shouldn't spend five seconds figuring out how to rewind — they should just drag left. The interface should feel like something you've used before, even if you haven't.

Early concepts had custom ATC-style timeline controls that were unique, domain-specific, and impressive-looking. But when I tested comprehension with people unfamiliar with ATC software, they fumbled, so I scrapped it. A bottom-anchored video scrubber maps to muscle memory that everyone already has. Investigators shouldn't spend five seconds figuring out how to rewind — they should just drag left. The interface should feel like something you've used before, even if you haven't.

first iteration

final iteration

first iteration

final iteration

design showcase

A system built for the people staring at the sky trying to figure out what went wrong.

A system built for the people staring at the sky trying to figure out what went wrong.

The final product runs in both desktop and Meta Quest 3 VR. Four core features where each feature tied directly to something investigators told us they needed.

001 — Incident Analysis

Data to the Sky

Data to the Sky

Taking ADS-B data from the FlightAware Firehose API and processing it through our Java Spring Boot backend, we reconstruct the sky in a 3D VR space using the Unity game engine. Flight trails render every aircraft's historical path — always on, always visible.

Taking ADS-B data from the FlightAware Firehose API and processing it through our Java Spring Boot backend, we reconstruct the sky in a 3D VR space using the Unity game engine. Flight trails render every aircraft's historical path — always on, always visible.

002 — VR Environment

Inside the Airspace

Inside the Airspace

Built around the Meta XR SDK, users can navigate the airspace through flight locomotion or a teleport mechanic. Collapsible metadata panels surface aircraft information on demand, and flight paths show future and past trajectories at a glance.

Built around the Meta XR SDK, users can navigate the airspace through flight locomotion or a teleport mechanic. Collapsible metadata panels surface aircraft information on demand, and flight paths show future and past trajectories at a glance.

003 — Playback and Investigation

The Sky on Replay

The Sky on Replay

Time can be rewound and manipulated within any incident replay. Using the playback manager, the scrubber can be dragged to any point in time, with controls for pausing, resuming, and changing the speed of playback — 1x, 2x, and beyond.

Time can be rewound and manipulated within any incident replay. Using the playback manager, the scrubber can be dragged to any point in time, with controls for pausing, resuming, and changing the speed of playback — 1x, 2x, and beyond.

what i learned

Designing in a domain you don't know is a feature, not a bug.

Designing in a domain you don't know is a feature, not a bug.

I came into this project knowing nothing about aviation incident investigation. That turned out to be an advantage because I led with curiosity and asked questions that domain experts had stopped asking. I questioned assumptions baked into legacy tools andd I stayed curious long enough to understand the problem before proposing solutions.

I came into this project knowing nothing about aviation incident investigation. That turned out to be an advantage because I led with curiosity and asked questions that domain experts had stopped asking. I questioned assumptions baked into legacy tools andd I stayed curious long enough to understand the problem before proposing solutions.

Some key takeways were:

The UI should get out of the way of the data.

In 3D and VR products, every UI element competes with the environment for attention. I learned to strip back everything that wasn't essential and trust that the data itself such as the the aircraft, the trails, the scene. Less interface meant more clarity.

In 3D and VR products, every UI element competes with the environment for attention. I learned to strip back everything that wasn't essential and trust that the data itself such as the the aircraft, the trails, the scene. Less interface meant more clarity.

Ambiguity is where design decisions actually live.

There were many moments in this project with no clear right answer: should trails be toggleable? Should VR be the primary mode? Should we support multiple incidents? I learned that in those moments, the worst thing I could do was delay. I made a call, articulated the reasoning, and moved. Some of those calls got revised and I had to learn to be okay with that, but some decisions where we kept iterating and testing held.

There were many moments in this project with no clear right answer: should trails be toggleable? Should VR be the primary mode? Should we support multiple incidents? I learned that in those moments, the worst thing I could do was delay. I made a call, articulated the reasoning, and moved. Some of those calls got revised and I had to learn to be okay with that, but some decisions where we kept iterating and testing held.

Comfort is a technical requirement, not a preference.

The motion constraint changed how I thought about VR design. Physical discomfort ends a session faster than any UX failure. I learned to treat physiological constraints with the same rigor as technical ones and to design for the body, not just the eye.

The motion constraint changed how I thought about VR design. Physical discomfort ends a session faster than any UX failure. I learned to treat physiological constraints with the same rigor as technical ones and to design for the body, not just the eye.

Impact

Presented live to Raytheon engineers at the Texas A&M Capstone Design Conference, June 2026.

Presented live to Raytheon engineers at the Texas A&M Capstone Design Conference, June 2026.

What started as a research question — what if investigators could see the incident instead of reading about it — became a working 3D and VR system, built from scratch over two quarters. I led the design, made the hard calls, and shipped something I'm genuinely proud of.

What started as a research question — what if investigators could see the incident instead of reading about it — became a working 3D and VR system, built from scratch over two quarters. I led the design, made the hard calls, and shipped something I'm genuinely proud of.

Glad our paths crossed. Let's keep in touch!

@ Jerry Nguyen 2026

Home
Work
Me
Resume