How to Include Engineers in Your Day-to-Day Research Activities

My personal philosophy about making UX research impactful is simple—UX research is a team sport, and if you’re in it to make an impact, you shouldn’t work alone.

If you started out in academic research, you might disagree with me at first, and that’s completely ok. After a few years in industry, most of us learn that non-researchers need to be brought into the process—and experience at least some of it first-hand to see how beneficial it is for them to make better design and business decisions.

While most conversations in the past years have all been about advocating the benefits of UX research to stakeholders from product, business, and engineering teams, the next expected step is to know how to involve these stakeholders in the practice.

So how do we get engineers involved in UX research?

Step 1: Educate and get educated

Before you jump into the fun part of collaboration with your engineering stakeholders, you have to plan for some education time. Ideally, you should educate your engineering peers about the best ways for them to leverage UX research, and also educate yourself about your engineering peer’s work.

Both steps are essential to build mutual understanding and make the most out of this collaboration. A good foundation will make it easier to build a long-standing relationship with your engineering folks.

Also—in my humble opinion—given the curious nature of those who work in engineering, you'll certainly have some allies and UX advocates in this crowd if you do it right.

✔ Educate peers on UX research

I believe that like in any team sport, in UX people have to learn how to play together like a winning team.

As a first step, I’d focus on teaching engineering peers how to leverage the expertise of a design researcher to make better decisions. This normally changes from one organization to another, but the rule of thumb here is to choose situations where the research findings can lead to a tangible change for the users.

If you have to implement a banking flow in a certain way because of a new regulation, maybe this is not the time to conduct research activities. However, if you’re working on something like a new mobile game, you’re for sure going to have more flexibility.

You can even call “research” more specific names to make it sound less academic and daunting. This can help the research feel more accessible.

Here are a couple examples of less academic names for research:

• “Let’s do a usability review of our current website,” instead of saying, “Let’s do research to understand what are the problems in our website”.
• “Let’s do customer discovery and understand our customers’ pain points” instead of, “Let’s do research on our customers to learn about their pain points”

While it seems like a small change, this wording will help your work sound less opaque and a lot more business-oriented.

Once your peers know when it could be beneficial to conduct research—and not just what research methods are available (like a grocery list of UX methods)—you’ll get a lot more attention from them during these educational sessions.

The second step happens right before you want to involve your engineering peers in UX research. At this point, teach them how to participate in UX research projects either in a passive or active role.

For instance, invite engineers to attend an interview or a usability test to learn about the way research is conducted. If some of your engineering folks want to take a more active role, you can teach them how to take notes effectively in a usability test, or how to participate in a group synthesis using an affinity diagram and invite them to assist you in these activities.

✔ Educate yourself on your engineering peers’ work

It takes two to tango, and you as a UX researcher also need to know your partners’ work to win as a team. Another way to think about it is to treat your stakeholders as if they were your users.

Schedule some face-to-face time to interview your engineering leads and developers, learn about their specific role (e.g. back or front-end developer, full-stack engineers, QA, data engineer, etc.), their jargon and in general, about their world.

Here are a few ideas for questions you can ask:

Live data

Ask your engineering peers about the customer interactions that are currently tagged on your website or app. What data can they provide about real customer behavior, such as clicks, conversions, and more? Front-end developers and data people can teach you more about this area.

You can also ask if your engineering peers currently run live tests. A/B or multivariate tests on certain percentages of your traffic validate different versions of your website or app. It’s relatively easy to start collaborating in these areas and leverage each others’ knowledge, because you both act as researchers in this capacity. Front-end developers can help you with this area.

Software architecture

Another fertile area to ask for more help is software architecture. If you create any products related to service design, you would need to understand—at least conceptually—what powers customer interactions behind the scenes from a technology standpoint. This way, you can suggest much more holistic solutions. A software architect can teach you more about this area.

By educating yourself about all these areas, you can build a strong relationship with your engineering peers that’s based on mutual understanding. Beyond talking to your engineering folks, you can always check out the tech news on websites such as TechCrunch and the CIO.

Step 2: Get involved

Before you start designing any solution, collaborate with your engineering resources to understand where there are potential problems that actually need solutions.

✔ Join forces with your analytics team

The easiest thing to start is with your data analytics resources. Using diagnostic analytics can shed some light on issues such as sales drop and churn. You can also see what flows potentially contain some sort of a usability problem.

Once you identify areas like this, dig further by conducting usability tests and click tests in these areas. This is how you can complement your analytics folks’ numbers.

On the flip side, this could go the other way. If you see that a user has problems completing one of your existing flows, you can ask your analytics folks to check if this is a large-scale problem by looking at their numbers.

As you can see, it goes both ways, and sometimes you’ll need the big numbers to validate scales.

✔ Involve everyone in visioning workshops

One of the best ways to align on a vision as a multidisciplinary team is to conduct a vision alignment workshop at the beginning of it. Ideally, they would include designers, engineers, and product people. One good example is the business model canvas workshop, as well as workshops to define CX metrics.

I find that one of the biggest contributions engineering people bring to the table is in the form of helping you define CX metrics. You need to define what success means in the case of your new solution, and CX metrics can tell you whether you’re on the right track. The Google HEART framework is a well known one that you can leverage for this purpose.

Oftentimes, a good way to know if you can define success metrics is by talking to your engineering folks. See if they can use Google or Adobe Analytics tags to track some of the interactions that signal whether an initiative is a success or a failure, such as clicks or conversion rates.

With the current transition between Google Analytics 3 and 4, it’s important to bring knowledgeable engineering stakeholders to the process so that they can help you make the most of this process.

Step 3: Co-design and learn together

Once you start getting into the solution space, there are a few interesting ways to collaborate with your engineering folks.

✔ Let engineers take notes during tests

Note-taking during usability tests is the easiest way to create empathy among engineering folks. This gives them an understanding of how your users could get frustrated (or not) using your solution.

Engineers will also get a chance to observe a few sessions of tests and see how users interact with a prototype (either coded or just mocked in a prototyping tool). I’d personally recommend letting them take notes during sessions.

This is a great way for them to externalize their thoughts, and to take an active part in the testing and the bigger research and design efforts. If you do it right, you can also involve them later in the discussions to synthesize and leverage their point of view among other stakeholders.

✔ Use backend knowledge to create better data presentation

Think of that page that gives you information about your last order from an e-commerce website (e.g. order date, shipping date, etc.), or the page that shows you the details of your latest banking transactions (e.g. merchant, amount, etc.).

Every digital product that involves the presentation of data (aka “data products”) calls this “data from a backend database.”

Oftentimes, designers rush to put this information on a page and only then ask a small group of users during a usability test if the order of information makes sense.

By leveraging your engineering folks’ knowledge about the information that can be found in your database, you can get ahead of the game. Take a group of the fields that you believe you need to include in your design, then run a card-sorting exercise with your users. This will help you determine the rough order of priority to them, at least conceptually.

Should the purchase date be presented before the amount? Which data field is the least important? All of this can be answered by conducting a card-sorting exercise.

By collaborating with engineers, you’ll make the life of your fellow designers much easier. Designers will receive the order of information that makes the most sense to the biggest group of users.

Nowadays, it’s easy to run this type of exercise with 100 clients or even more online, get a better sense of what’s the desired order of information, and better understand clients’ mental models.

✔ Leverage their knowledge to look at the big picture

Most UX design projects still tackle primarily the front-end of the experience (e.g. user flows, the visual design of the UI, etc.). This is just the tip of the iceberg.

A growing discipline called service design is now starting to use design thinking skills to look at the bigger picture, including the layer that is not visible to the client. Service designers create products that help multidisciplinary teams understand how to optimize a service.

One of these products is the service blueprint. You can involve your engineering resources in a service blueprint by interviewing them. Include their knowledge of the backend systems that enable front-end customer interactions, and essentially, the entire service.

In this area, the more you know about the backend, the better you will become at understanding the system holistically. Your team will also be better at suggesting creative solutions that take not only the customer perspective into account, but also the technical limitations of your organizational systems.

Build and nurture relationships with your engineering peers

I believe that by creating a good foundation from the get-go (educate and get educated), you can quickly develop mutual understanding and identify allies within your engineering teams.

Depending on the type of project you’re working on, there are multiple points where you can involve your engineering resources, both in the problem and the solution phases.

The more you involve your engineering peers in the UX research process, the better your relationship will be. In turn, this improves the quality of your deliverables due to the synergies created in this process.