Credit: phototechno

Sometimes called a design technologist or creative technologist, the user experience engineer is a developer that plays in the space between creative and development. Adding a UXE to a team that is developing an app or site can unlock new methods of product innovation and enable design teams to fully validate an idea before handing it off to engineering.

I’m a senior UXE at Google and will explain how I enable new and faster-paced methods of innovation on the product teams I work on. I will also outline exactly what a UXE is, what that person’s responsibilities should be, and how their presence enables a more effective and impactful UX team. Their ability to quickly produce functional prototypes will allow your team to get critical stakeholders and user feedback early in the design phase at a time where it can be properly dealt with and tested. Also, I will highlight a real example of how the UXEs on the Google Maps team applied this process to great effect.

This is my personal take on an emerging role. Like any new discipline, there is a lot of healthy debate at Google about what UXEs should and shouldn’t be doing. This article is my contribution to that debate. Also, the role at Google I’m describing in this article is technically called a design lens UXE which is a different role from the Engineering Lens UXE.

The steady increase of UXE job postings and hiring both within Google and externally tells me product teams are learning how valuable these types of developers are.

The UX Team

In order to understand what a UXE does you first need to understand what a UX team is. I know not all companies use the same org setup so here’s how it works for Google: Each product team, which is dedicated to a feature or application, is structured into three distinct groups. There’s the UX team which consists of roles like UX designers, UX managers, UX researchers, UX writers, and occasionally a UX engineer. Then there’s product management who’s responsible for the priorities and strategy of the product. And lastly, there’s engineering who are responsible for building and supporting the applications. This triad is meant to work together to produce the best possible product.

So… What is a UXE?

Simply put a User Experience Engineer is a developer on a UX team that applies engineering to support UX efforts. They build functional prototypes for a limited audience. Code is a UXE’s tool to design something. They can build something functional quickly in any language, platform, or API required for the project. They are a proper member of a UX team and they are managed by a UX lead (not an Eng lead). They build functional prototypes, proofs of concept, and internal design tools. They work closely with UX research to test those prototypes and iterate on them. They serve as technical consultants to UX teams as the voice of engineering in all UX meetings. UX projects should still be overseen and ultimately approved by engineering, but having this constant tech presence helps a lot. Conversely, they serve as UX consultants to the eng team and help the team think through eng decisions that can affect the UX. They are the mediator between eng and UX and they thrive in the messy, always changing space of developing new ideas.

What a UXE is not

UXEs are often conflated with a front-end engineer. Those are two completely different roles with different jobs. A UXE is writing code in a prototyping environment to support a design effort. A front-end engineer is writing secure, scalable, reusable code in a production environment. See my chart at the bottom of this article for a breakdown in what the different responsibilities are.

Design Lens UXE vs Engineering Lens UXE

At Google there are two distinct UXE roles: the Design Lens, which is what I am and I have a lot of experience with and the Engineering Lens which I am not. What the eng lens UXE is and what their responsibilities are are out of scope for this article. Everything I’m stating here pertains to the Design Lens UXE specifically.

UXE Responsibilities

Functional Prototypes

There are a lot of reasons why being able to use a part of a new idea early is critical to the design process. Prototypes bring an idea to life in a way that design mocks cannot. They make an idea go from theoretical to achievable and they are great to demo to higher-ups for project approval.

One of the most valuable uses of the prototype is for user research. The higher fidelity the experience is you put in front of users, the more valuable and accurate the feedback will be. A UX Researcher will be able to help define the success metrics and ways to test them using a prototype. So the UX team and UXE builds a prototype, the UXR tests it and you then know how effective the experience is in solving the problem. As a team, you can then tweak the prototype to account for the issues you saw and test again. If the testing data is conclusive you can hand off the design to Eng or walk away from it entirely. Through prototyping, the risk for trying things decreases dramatically, therefore as a product team you’re better positioned to innovate.

When presented with an experience, a good UXE will be able to quickly tell you what should be a functional prototype and what should not. For instance, if you’re building a multi-screen form where you are asking the user some questions, a click-through prototype will probably get you all the feedback you need. However, if you’re building something more novel or involved like the Google Maps example I highlight later in this article, you won’t be able to properly express the idea with just mocks. A more senior UXE will be able to properly scope and plan out the project and make sure everyone is aligned on the deliverables.

Platform Validation

Sometimes UX teams are building for a platform (e.g. iOS, Android, web) they are unfamiliar with. These platforms have restrictions/limitations that will affect the UX. Having a UXE allows the UX team to explore these and iterate on them independently from engineering. Then when the experience is ready, they can present it to eng knowing the experience is right for the platform. A frequent example of this these days is Progressive Web Applications. As a team that’s used to building for the web you may not know how PWAs work or what they can do. A UXE can work closely with the UX team, try things out and report back how it works and how it’ll affect the user experience.

Proofs of concept

When discussing a user experience and the systems involved a UXE will sometimes need to build a proof of concept to determine if an idea is even feasible to pursue. A UXE can quickly build a POC, then report back to the UX team how/if an experience could work.

Internal UX tools

UX teams need to occasionally build internal tools to improve their UX process. Usually this is not something the eng team is going to prioritize so the UXE is there to build plugins or integrations for Photoshop, Figma or Framer that are specific to your needs. Or maybe net-new applications that solve a specific design process problem. At Google, a lot of these efforts involve getting actual search or map data into designs or prototypes to see how the design functions with real-world data.

Tech representation in all UX efforts

During all UX design meetings, the UXE is there to remind the UX team how the systems they are designing for generally work. This constant technical feedback and nudging are helpful in creating designs that adhere to the technical limits of the browser, mobile phone, or whatever you are developing the experience on. It allows the UX team to deal with these limits internally and not have to waste Eng’s time presenting designs that won’t work.

Technical Handoff

At some point, the UX team needs to hand off designs to the Eng team for the Eng team to build. If the thing that is being handed off also includes a fully designed and tested functional prototype everyone involved is much better off. A lot of debate about how something should work, look and feel has already happened. The Eng team is a lot less likely to have to deal with these issues as they productionize the design. Also if the prototype has been used for user research there’s actual data that proves the experience effectiveness which can help stem arguments about what Eng does and doesn’t want to build.

Ah yes, the negotiator

There is always a normal, healthy tension between the UX team and the Eng team. They are each going to have their own priorities and goals. Most of the time these teams are aligned but occasionally things come up like “The Eng team doesn’t want to build this part of the experience because of X” or “The UX team doesn’t think this Eng idea is good for users because of Y” this usually falls on the Product Manager to mediate. The UXE, being an engineer on the UX team is in a unique position of understanding both sides and coming up with novel solutions that will fulfill the needs of both parties.

A Note about Throwaway Code

A lot of times there’s pressure to build prototypes in a way that it could easily be added to production code without rewriting it. Prototypes need to be fast and agile and a lot of the time the production stack just doesn’t support that. The role of the prototype is to get to the best possible designed experience quickly. That means building things in a quick, messy way using popular 3rd party libraries that may not be supported in the Eng production stack. So yes the prototyping code will not be usable directly by the engineering team but that’s how it’s supposed to work. The Eng team can use it as a code reference and they will benefit from hearing about the UXEs development of the prototype.

A Real-World Example — Google Maps AR

Because almost all UXE work has to do with products and ideas in development I can’t talk publicly about any of the projects I’ve been on. So I’m going to use an already approved-for-public Google Maps example. This work was led by a colleague of mine named Sam Keene and is one of my favorite examples of how UXEs can bring value to the product development process.

The problem

The Maps mobile team had identified a major user problem where the blue dot indicating the user’s location was not accurate when people came out of a building or subway in a city. Users who were getting walking directions were confused and couldn’t tell which direction to go. The Maps team thought that using AR would be a good solution to this. The UX team needed to design an AR experience that would properly guide the user in the correct direction towards their destination.

The problem the UX team was trying to solve

The process

The UX team got to work and started brainstorming and designing some experiences that could solve this. Those brainstorm ideas turned into visual mocks/designs. The UXEs then built functional prototypes from those designs which were used in user research sessions. The test users were given one of the functional prototypes and told to open it and follow the directions. The UX team would see if the user was able to get to their destination and if there was any confusion along the way. After testing all the prototypes the team would regroup and discuss the results. They’d make changes to the experience based on the test, the UXEs would update the prototypes and they’d test them again. After a few of these iterations they landed on the experience with the best results.

A few of the different prototypes UXEs built to design the best user experience.

An important thing to note here was that these prototypes were not built in the normal application stack of Google Maps. They were built entirely in Unity. Choosing Unity allowed the UXEs to build functional experiences fast. By being fast they were allowed to experiment, making functional versions of multiple designs. Also they could change the experience very quickly based on the testing results. This empowered the whole UX team to quickly get to the best possible experience for this user journey. The prototypes didn’t need to be fully integrated with Google Maps because the user tests were very controlled and always in a known location.

The Final design of the Google Maps AR Experience

The result

The final prototype was shown to the Eng team as well as a run down of all the user testing data. The eng team could proceed confident that the design they are being handed is an experience that has already been proven to solve the problem. They could use the prototype as a reference to see how animations/buttons should look. The eng team could spend their time properly building the feature for production and weren’t delayed by experience problems that came up as they built it. The feature was then launched in all mobile versions of Google Maps.

Conclusion

So that’s what my job is.

I work in Corporate Engineering on new ideas and features empowering Googlers. I spend my time developing to support UX design, research and technical efforts much like the Google maps example. It’s a relatively new role and people are unaccustomed to working with UXEs and setting up projects in a way where UXEs can help. So a lot of my job is also advocating for UXE work and teaching both directly and by example. But it’s an exciting new UX discipline to be in and it’s growing fast. So if you haven’t worked with a UXE you probably will soon.

Appendix

UXE vs Front End Engineer

Just to clearly demonstrate the difference between a UXE and a Front-end Engineer, here’s a list of each role’s responsibilities.

The UX Collective donates US$1 for each article published on our platform. This story contributed to Bay Area Black Designers: a professional development community for Black people who are digital designers and researchers in the San Francisco Bay Area. By joining together in community, members share inspiration, connection, peer mentorship, professional development, resources, feedback, support, and resilience. Silence against systemic racism is not an option. Build the design community you believe in.