User Experience Engineering

I’ve just passed 6 months as a “User Experience Engineer” at Google and I’d like to share some things I’ve come to understand about the role and where it puts me in the design process. My hope is that sharing my perspective will facilitate a discussion around inter-disciplinary product development and connect people excited about this kind of work.

I should note that at Google, the UXE role has two lenses. Everything in this post concerns the “design lens” which is focused on prototyping as opposed to the “engineering lens” which is more focused on production code. It is possible to move fluidly between the two, and it is not uncommon for UXE’s to lead design work as well.

First we should establish some context around the role. If we break up the product development process into three major categories we’d get Research, Design and Engineering. Each of these categories can have dedicated professionals (like Google does) or skilled generalists who can wear multiple hats (most startups).

The focus of each of these domains is to answer a different fundamental question about the product. The aim of Research is to answer why. Why do people have the problems we are trying to solve? Why would they or wouldn’t they use our solutions? Design is all about figuring out what we should build. It’s also about what we shouldn’t include, what the solution looks like and what the product does. Finally, Engineering is concerned with how we build the product.

You may be tempted to string these disciplines together with a linear narrative, that we first research to understand why, then design to figure out what and then let the engineers figure out how to do it.

In reality there are feedback loops that connect each discipline and discussions that dig deeper into each of these questions. The answers to each question we ask about why brings up new questions about what to build. While trying to figure out how we can build our product we come up with new questions for what it should be and sometimes this makes us rethink why we are pursuing a particular solution in the first place.

Trying to map out all the possible ways we can tie together Research, Design and Engineering would wear us out worse than that traveling salesman. Instead, lets look at the two main opportunities I see for a UX Engineer: connecting why to what and connecting what to how.

Why to What

One of my favorite parts of the product development process is helping to get from why to what, it usually means creative applications of all my technical skills to quickly produce something that resembles a solution just enough so that we can get new information. It’s a delicate balance between achieving quality that isn’t distracting and avoiding waste on ideas that are dead on arrival. Before I joined Google I drew this diagram to illustrate where I like to spend my time:

What I’ve since realized is how much of a two-way street the why-to-what process really is. We don’t just ask why once and get the answer, most of the time we have to try several ideas, refine how we ask the questions to get better answers. Often we get to something we think is what we need to build and need to confirm that it actually answers the user’s why.

The output of this process is typically a combination of static mocks and interactive prototypes built from any variety of tools. Personally I’m doing a lot of raw HMTL/JS/CSS with some d3.js and throwing in the occasional Material polymer component. That being said, the result of this process is a better understanding communicated between any number of people involved in this phase of the product development.

What to How

Another key opportunity for those of us that straddle design and engineering is aiding in the communication between what and how. In many places Designers and Engineers are separated along this boundary, with designers describing what they want and engineers figuring out how to build that. I find this a limiting perspective because it can place people on opposite sides of an adversarial relationship. The ideal situation would see everyone trying to reach a deep and wholistic understanding of all the questions.

This is where a UXE can help the most, by increasing the bandwidth of communication between the two groups you reduce the amount of miscommunication and friction that occurs. Examples of this include building out high-fidelity interaction and motion prototypes that express a designers intentions more truthfully. It can also mean getting access to real data to surface edge cases and realistic scenarios before a design gets fully baked. My personal focus has been on working with data to facilitate the why-what-how loop around data visualization problems, which deserves a post of its own!

Gifts that keep on giving

From what I’ve seen, the above activities can be incredibly effective in speeding up and raising the quality of the product development process. There is another area I believe UX Engineers can focus on that can have a disproportionate impact and it is a side-effect of our process. I’m talking about building tools for those around you. I framed this as a perspective to adopt rather than a specific initiative or responsibility because from what I can tell it works best when you spot an opportunity. These opportunities arise in discussions with various coworkers who experience painful processes that could be alleviated via automation.

We build our prototypes with a ruthless focus on efficiency and effectiveness, balancing between fast turnaround and successful communication. If we take the same approach to building internal tools it can be surprising how helpful we can be. It just requires to look at internal development processes we encounter with the same mindset we approach our prototypes.

Let me know what you think about my perspective of the process and the role, it’s a relatively new one in the space. I’m also excited to continue my journey into the design side of product development, coming from a math and software engineering background. I certainly feel fortunate to be learning from extremely skilled practitioners in all 3 disciplines on top of being valued for doing inter-disciplinary work.