What this was, and what it wasn't
This wasn't a formal role change. Boeing doesn't add UX Engineering titles because there was a researcher who pushed for it. The discipline didn't exist. That was the point. In addition to my core engineering work, I spent roughly two years building the case that it should.
At large enterprises, the gap between design intent and implementation isn't a skills problem; it's a structural one; designers hand off specs, engineers interpret them under deadline pressure, and the resulting product reflects the translation loss. Everyone has seen this. The question is whether anyone is positioned to close it systematically.
The role of a UX Engineer isn't to do both jobs. It's to make the handoff unnecessary: to sit in the space where design decisions become technical ones, and own that translation.
The research
The case started with documentation: mapping where friction entered the design-to-engineering pipeline, what it cost, and what existing role structures couldn't address. I interviewed designers and engineers, reviewed handoff artifacts, and traced the gap between Figma specs and shipped components.
The pattern was consistent: not a skills gap, not a tooling gap. A structural gap. The people doing design and the people doing implementation were operating from different mental models of what "done" meant, with no shared accountability for the translation layer between them.
The pitch
Turning research into organizational change at a company like Boeing requires building a case that executives can act on, which means connecting the friction to business cost, and the proposed solution to something defensible within Boeing's existing org structures.
The C-suite presentation made the case for a UX Engineering discipline: what it would do, where it would sit, what success looked like, and why now. Not a request for headcount, but a proposal for a structured pilot that would let the concept prove itself under real conditions.
The pilot
The pilot ran for approximately one year. My job was to operate as the model: to demonstrate what a UX Engineer actually does in practice at Boeing's scale. That meant sitting in the design-engineering seam on real product work: reviewing handoff quality, identifying component gaps, translating design intent into technical specs, and building the documentation infrastructure that let engineers make better decisions without needing to escalate every ambiguity.
The pilot produced the evidence base needed to formalize the role. When the Boeing Design System team was stood up, UX Engineering was part of the founding model.
Why this matters as a portfolio piece
Most portfolio work shows what someone can make. This shows what someone can change. The ability to identify a structural problem, build a credible case for addressing it, and operate as the proof-of-concept inside a large organization is a different kind of signal, one that's hard to demonstrate without having actually done it.
At Boeing's scale, with Boeing's org structure, this took longer and required more deliberate effort than it would at a startup. That's the point. The skills that make this possible aren't just technical or design skills; they're the ability to see organizational systems clearly and work within them without losing sight of the underlying problem.
01 · Research
DOCUMENTING THE GAP
Two years mapping design-engineering friction across product teams. Where it enters. What it costs. Why existing roles don't catch it.
02 · Pitch
C-SUITE PROPOSAL
A business case for UX Engineering as a recognized discipline: connected to cost, feasible within org structure, scoped for a defensible pilot.
03 · Pilot
ONE YEAR OF PROOF
A structured pilot program to demonstrate the model under real conditions before any formal expansion decisions were made.