Interview

Why Google Needs UXEs

User Experience Engineers are creative all-rounders who bridge the divide between engineering and design

Black and white illustration of various shapes and scribbles

User experience engineers, or UXEs, occupy an ever-evolving niche at Google. As creative all-rounders, they bring a balance of design savvy and technical design expertise to their roles; as thoughtful problem solvers, they apply their unique crossover skill-sets to projects across all stages of development, from intent to implementation. Prototyping is one of their superpowers. They have a knack for getting things done. We spoke with nine UXEs about their versatility as tinkerers, makers, dreamers, and builders, and why their work is so valuable.

Meet the UXEs

What is a UXE, anyway?

Well, it’s complicated—there is no “average” UXE.

Shana Goldman: It’s a difficult position to describe because UXEs wear so many different hats and have a variety of backgrounds and expertise—but we sit at the intersection of design and engineering and speak the language of both. Need a new tool built to support a Figma integration? Ask a UXE. Need to research some new technology and determine feasibility? Ask a UXE. Need a functional prototype for user testing? Ask a UXE. Need to build a front-end using the latest technologies and platform best-practices? Ask a UXE.

Yerusha Nuh: UXEs are amorphous unicorns. Being hard to define is part of our superpower.

Aaron Zemach: The process of creating a new feature can sometimes feel like a negotiation between sides: designers are trying to pitch the best version of a feature based on what they've learned about users, and engineers have to adjust that to fit within the way the existing product code has been written. UXEs act as a communication bridge—a translator—who can often see and propose solutions to problems that realize all the user benefits while avoiding major engineering challenges.

Black and white illustration of various shapes and scribbles about user experience design and process.

Alex Finlayson: UXEs need to have creative problem-solving skills.

Caroline Hermans: I'm constantly switching between “engineer” and “designer” brain, which involves bringing technical understanding into design discussions, and writing code with an eye towards usability. But we all write code with the goal of making things that are beautiful and user friendly.

Bridging disciplines

UXEs at Google operate within two focus areas, or “lenses,” and solve problems in the (often amorphous) space between.

Design lens

Ian Li: The design lens requires a lot of collaboration with UX designers and researchers within my team: figuring out what questions to explore with prototypes; advising the team on what interactive features are feasible and demonstrating them with prototypes; and creating prototypes that can be used to explore designs and to conduct user studies.

Aaron: I'm [always] trying to answer two questions: How can I help my team learn as much as possible? And how can we do this as fast as possible? A UX Engineer learns by building. I want to be able to take what I learn from people’s reactions to a prototype and apply it to our finished product.

Caroline: I'm an active part of our design process, including brainstorms and UX discussions.

Min-Zhong Lu: I advise what’s prototyped, and how, and predict what design problems might arise in the future—which is when my design intuition and knowledge comes into play. I have to fill in a designer’s shoes, know what features are more “risky,” craft initial experiences on my own, and rendezvous with designers when they get more detailed requirements from various stakeholders. There’s a lot of “translating ambiguous design problems into technical execution” in my role, and it’s only by regularly keeping in-sync with others can I be confident that I don’t have blind spots.

Engineering lens

Shana: UXEs are in a great position to bring engineering feedback early to a design process and conversely, provide UX feedback and guidance to engineering. My main focus is writing production code, but I build and iterate on prototypes when needed for a project. I may also be responsible for “production-izing” a prototype [writing production code], rather than handing off to a larger product team.

Caroline: I write UI code, learn relevant tools and APIs, and work with engineers to get data.

Rahul Gaba: We collaborate with backend software engineers, or find backend optimizations which will help improve the product; tackle on-call issues; improve load time; and make sure that our product matches the Google standard of core web vitals. A strong library of UX components is critical, and we’ll maintain our team’s UX library. In addition, every piece of code which goes to production needs to be reviewed for security vulnerabilities and needs to have a proper suite of test-cases.

Min-Zhong: “Engineer” is in the job title for a reason, even for people who only write prototype code. I need to minimize tech debt, architect reasonably, and reduce development overhead, applying all sorts of “real-world” software engineering best practices.

Black and white illustration of various shapes and scribbles about user experience design and process.

Harnessing the power of prototypes

While there may be no “typical” UXE, there is a throughline; prototyping plays a critical role for UXEs on nearly every team.

Bonnie Zhou: Prototyping is where design ideas come to life! It’s hard to fully understand the nuances of interactions or patterns with static design files, so it’s hard to communicate the value of these ideas to someone else. Prototypes fill that gap—they’re essentially a higher fidelity version of these ideas that you can use to gather feedback, validate or invalidate assumptions, and pitch to leadership, etc.

Aaron: I've heard UXEs describe being a prototyper like being a time traveller. Any time you release a new product or feature, you learn a lot based on real-world usage that isn't obvious until it's out there. When you build a prototype, you capture a bit of that future and bring it back to the present where you can learn things much faster, and with lower risk. The “secret sauce” of being a UXE is learning how to use code to fake and shortcut the hard parts.

Caroline: With a prototype, everyone can quickly try out a new idea without committing a full production engineering team to it. This allows UX to move quickly, solidify our thinking, and explore multiple possibilities.

Alex: Building a prototype can help focus people with different roles and backgrounds on one vision and evaluate different iterations rapidly; once everyone is on the same page we can build a more robust product.

Ian: I’m able to explore multiple designs and iterate on designs quickly; create prototypes with real data for use in studies; and help the UX team validate designs, so when we pass them to engineering for implementation, they’re properly tested and vetted. This reduces churn and saves development time.

Yerusha: As a UXE, I can use my engineering skills to build solutions to UX problems. Many UX problems don't have a definitive answer and the ability to unlock creative explorations is crucial.

Min-Zhong: For my team, prototyping is the design process. It starts as the designer places the very first rectangle on the canvas, and evolves along with the design, so designers can play with and feel their design—and uncover design questions—as they go. And then there’s the oft-repeated proverb: “A prototype is worth a thousand meetings.”

Tools of the trade What UXEs use to get the job done.

Figma Sketch Visual Studio Code ProtoPie iPads Custom 3d printed solutions Code

Black and white illustration of various shapes and scribbles about user experience design and process.

Where process meets product: UXEs in action

Every team has its own unique workflows, objectives, and output, so specific UXE responsibilities vary. Here’s how their critical contributions help bring a range of Google products to life.

Min-Zhong: It’s really about illustrating design problems—and their solutions—at scale. There are 80+ product offerings across Google Cloud Platform (GCP); one change in the GCP UI in one place often has unintended consequences in another. We rely heavily on UXEs to produce scalable design artifacts and design tools, so designers don’t have to duplicate design changes across the product offerings.

Shana: My primary work consists of designing and building reusable components through a standardized design system. I work closely with the designers, researchers and other engineers on my team as we design and iterate on experiences to support users across cloud.google.com. I also help maintain the end-to-end process of launching experiences.

Ian: My role as a UXE in Google Health is to help the UX team explore interactive features for software that allow clinicians to quickly search through complex patient information, and provides a comprehensive view of a patient’s records. This requires building prototypes of new user interfaces and visualizations—and since we test these features with clinicians, the prototypes often need to have real and synthetic data, it is critical that we design, research, and test our products in a rigorous way.

Alex: I’ve built custom hardware; built simulated hardware using iOS devices; built webapps to develop experiences; built prototypes to help iterate on designs; come up with new features and product ideas; and tried to connect dots that might not generally happen until the final stages of development. I’m often the first person to run into strange edge cases, so bringing these to design early helps engineering avoid those pitfalls.

Caroline: I work with maps and data to prototype new designs.

Black and white illustration of various shapes and scribbles about user experience design and process.

Lessons from the field

Beyond the myriad technical smarts required to do their job, being a UXE requires a thoughtful—and flexible—approach to work.

Aaron: Be biased towards action. You can debate, you can write-up proposals and pitches, or you can just build an idea and see for yourself whether it works or not.

Min-Zhong: Be adaptive and think out of the box. This is instrumental to keep up with the rapid design processes and paradigm shifts; we constantly learn new tricks to serve the production process better.

Bonnie: Be an empathetic communicator. As a UXE you’ll be working closely with designers, researchers and engineers, and it’ll be your job to understand all those viewpoints and be the “bridge” across disciplines.

Aaron: Tune into emotions. Often with prototypes, what we're looking for is emotional reactions. Are people excited when they play with something? Frustrated? Confused? Do they think it's funny? Are they pleading to make it real? Any one of these is going to reveal crucial information that we can use to make better products and features, but you need to be attuned to be able to receive and understand it.

Min-Zhong: Be inquisitive***.*** UXEs need to be curious both about design problems and solutions plus engineering/implementation problems and solutions.

Caroline: Be an active learner. There are frequently new tools and processes that can help us and our teammates be more efficient.

Min-Zhong: Recognize what’s perfect without being perfectionistic. Getting the product into real users’ hands is the ultimate goal—overpolishing doesn’t help with that.