In my teens, I was involved in many extra-curricular activities in high school. I was president of the art club for all 4 years and lead for the school’s robotics team. While I wasn’t officially part of the class counsel, due to my volunteer work especially with the homecoming floats, I was given a new title by my peers over 20 years ago; Design Engineer.
I didn’t think much of it then but after being fully immersed in both design and engineering, I resonate with that title. Not only do I consider how an experience could be constructed; I actually construct it. That’s something that’s always been important to me. Just having the idea wasn’t good enough, I needed to show people the concept and it wouldn’t be complete unless it was the real deal.
Getting paid
It’s one thing to find your passion, it’s another thing for that passion to put bread on the table. My passion didn’t start doing that until after graduating college. My first engineering job was officially as the sole frontend engineer for a finacial tech company but they also didn’t have a designer. My co-workers saw how quickly I could prototype a design in CodePen and made it easy to collaborate, so they gave me the responsibility for the design of the platform too. That’s where I took on both roles but also had both titles; Product Designer & Frontend Engineer.
After that role, I was hired at a real estate startup as a Frontend Engineer. The codebase was massive, they were using a framework I’ve never seen, and my onboarding buddy was assigned to a totally different team working on the launch of what would become the most successful product on the platform. It was a sea of anxiety and I had a metric ton of imposter syndrome. However, as timing would have it, they also hired a new Director of UX and we were in many of the same onboarding groups. I raised the idea of joining their team to help with prototyping and better integration of design into code and after some formalities, that’s how I became their first UX Engineer.
I felt really relieved. Design was straightforward for me and I could ease my way into the codebase with small changes instead of feeling responsibility for the entire repository of code at once. Like many places, onboarding is not often crafted well because it’s done once and the business has other higher priorities. More on that later.
Rainbows & roses
Most of my first responsibilities were to prototype experiences to hand off for research studies. I quickly found that I was reusing the same assets over and over so I started making my own little library of components in CodePen. I could import files across pens by appending the file type to the end of the url. While there was an existing component library; these designs were often new and experimental. I needed my own collection of components that I could iterate on in isolation for these prototypes.
Eventually, I became more comfortable with the codebase and found areas of improvement; especially when it came to CSS. I found out then that most engineers have difficulty with CSS. For me, CSS came naturally and I was able to do things that didn’t seem possible for others. As one example, there was an ask from design to pin the footer to the bottom of our listing results. The listing results component was using a collection of CSS overrides on AG Grid, and the architecture of those overrides were outlined in a multi-page document. It was a big deal to even look at the project, let alone change it. The lead engineer for the frontend team told management a change like this would take 6 weeks.
I made the changes over 6 days.
Eventually, I was responsible for all CSS found on the platform. While I wasn’t looking at every PR, I was always called into the room for large projects or complex experiences. The listing details page was one of my last large influences; which was one of the first places where I was able to use display: grid; and position: sticky; on a production site. I became responsible for the component library, as it eventually matured into a design system. By the end of my time, I was putting together the Design System team and looking into how we could support all the various frameworks being used with a singular source of truth.
Managing expectations
While I loved all the work I was involved in, there was one thing that made me leave; lack of recognition. Many people were promoted during my tenure; I’ve seen some people promoted 3 times during my 2+ years there. I was promoted only once and it was title change with a cost of living pay increase. A few months later we’d have a new CTO and start new tech hubs around the world. What happened? Why was I left in the cold when everyone else was shining?
When I first became a UX Engineer, I was reporting under the design organization. The trouble here was that our Director of UX didn’t have experience managing an engineer before. While this autonomy felt good to me, there was no career ladder. It wasn’t clear what steps I needed to take to be promoted. After the director left, I was reporting to the principle designer who really didn’t want to manage people.
It was around this time the most senior frontend engineers were convincing me to come back into the engineering organization; right on the heels of the AG Grid work mentioned earlier. With some help from a new engineering manager willing to take me on, I moved back into the engineering organization. That manager was a huge help for my career because he understood my skills and influence and was able to be my voice in rooms I couldn’t be in. He was the person who fought for my promotion, just before he was pushed out by management.
I was reporting under a new manager then; someone who previously identified as a backend engineer. It felt like I was reporting under the design team again. For our mandatory 1:1, he’d ask how I was doing and I’d just telling what I was working on. He really couldn’t give me much feedback because he didn’t know my world. It wasn’t really his fault; we were just paired poorly.
When the new CTO came, we had a large restructuring which included new VPs of Engineering and other managers. After stating a case that I was a leader in the engineering organization, instead of receiving a promotion, I was restructured to report under one of the new VPs of Engineering. He really didn’t have any time for me; trying to get up to speed on larger problems that were happening with hyper growth. After having 6 managers and the company removing the only one that really helped me; I decided if I was going to grow, it couldn’t be here.
Picking a side
After I left, I joined the company I currently work for. Here, the management understands my value and every person I’ve reported to can hold in-depth conversations about my areas of interest and provides meaningful feedback. It’s really what I’ve been looking for all along. There’s only one problem:
My role is Software Engineer.
What’s the difference? As a Software Engineer, you’re expected to just live in the code. You rarely get a glimpse into the experience design side of feature development and instead need to be responsible for lots of different engineered systems; databasing, CI/CD, bundling configurations, along with feature development. All the problems you solve have to do with getting the computer to do what you want with commands. As a UX Engineer, you are responsible for the user experience. The problems you are solving are user needs and (in my opinion) much more interesting and impactful.
I don’t associate with being a Software Engineer. I associate with being a UX Engineer. However, because UX Engineering doesn’t have the career support that Software Engineering does; I need to masquerade as something I’m not just to succeed in a field and have a possibility of promotion.
This isn’t only where I work. The industry has a clear problem supporting UX Engineering. Often a company has a UX Engineering role but reports under either design or engineering. This will often lead to the problems I’ve personally experienced shown above; lack of understanding about the role for existing management. On the other hand, folks picking a side can struggle because they don’t have all the knowledge or experience as other folks with roles aligned to the larger organization. In other words, a designer probably knows all the hidden gems in Figma; while a UX Engineer might only know some intermediate techniques. Without clear responsibilities; the UX Engineer will look subpar to the Designer. In my case, I’m not able to effortlessly debug workflow problems for CI/CD and unfortunately that sounds like something a Software Engineer should do.
This is all assuming you were hired. The interview process can be especially disappointing for a UX Engineer. We’re often met with teams of Full Stack engineers who gang up on us to determine how much we don’t know about the stack. What good does knowing how to use Auto Layout in Figma do if you can’t even query a database?
Outlook
As an industry we should provide more support in UX Engineering. Even if there aren’t defined management positions leading UX Engineering in an organization; existing leadership should recognize this role and help define a path with folks that have these specialized skills; highlighting their abilities. These are the folks who translate design into code without looking at the inspect panel. If you don’t see the benefit of that; I’m afraid you really don’t know how the web works.
For my fellow UX Engineers out there, my heart goes out to you. I hope you’re being recognized for the work you’re doing; either by compensation, role, or fulfilling work. I wish I knew how to take the mask off. If you find out, please let me know.