Who's this for?
”Wait, so are you in Design or Engineering?”
There is a peculiar ritual that happens whenever someone introduces themselves as a UX Engineer (UXE).
The first response is usually curiosity.
“So… you’re a frontend engineer?” 🤔
The second response is some version of fathoming.
“Oh, like a designer who codes?” 🤠
None of these questions have a universally accepted answer.
That’s the problem I’m noodling on today.
What is a UXE?
UX Engineering is one of those disciplines where the title, interview process, and success metrics often disagree with one another. Two companies can post identical “UX Engineer” roles and mean entirely different jobs.
There’s an old parable about blind men describing an elephant. One feels the trunk and says it’s a snake. Another touches the leg and insists it’s a tree. UX Engineering inspires similar debates. Depending on the company, a UXE might focus on frontend, design systems, or integration. Each view captures something true, but only part of the picture.
This ambiguity has consequences.
Questions like “Are you code leaning or design leaning?” assume UX Engineering exists somewhere on a spectrum between two established roles when it doesn’t.
A UX Engineer is a steward of the goobly-woobly between design and code.
When organizations don’t understand UX Engineering, they shape the role around whatever problem hurts most right now.
One company needs design QA. Another needs overflow frontend capacity. A third needs someone to maintain the component library.
All useful work. None sufficient.
UX Engineering is a distinct discipline.
It exists at the intersection of design systems, frontend platform, and product development.
Treating it as a lesser version of adjacent roles distorts the field and leaves significant organizational value on the table.
UX Engineers are not “designers who learned React”.
UX Engineering emerged because modern product development created problems that neither traditional design nor frontend engineering fully owned.
Those seams are where products succeed or fail.
And as products become more complex, those seams become critical.
UX Engineers influence:
- system evolution
- adoption strategy
- interaction standards
- tooling
- accessibility practices
- prototyping workflows
- product architecture decisions
Yes, maintenance is part of the work. It should not define the work.
Those are my strong opinions, I’ll post case-studies soon. Or you should bug me about it.