What Developers Need from UX Research
Taylor Palmer ·
Research & Testing
Insights from interviews with software engineers about how user research helps them create better experiences.
User research isn’t only for designers. Research insights make teams and companies successful by helping them focus and deliver real value.
Software developers and engineers, for example, are often a group who is overlooked when considering user research. I interviewed several software engineers to learn about their preferences, workflows, and habits regarding user research.
Opinions and working styles vary from person to person! Use these ideas as a starting point to improve collaboration on your team.
- How should engineers be involved in user research?
- Benefits of engineering involvement
- Building a culture of “why”
- Making research accessible to engineers
- Conclusion
How should engineers be involved in user research?
Most engineers I interviewed didn’t have any interest in participating in user research at all. Some felt they “would probably hinder the process more than [they] would be able to contribute.” This isn’t surprising their skills and specialties.
Other engineers were more interested in “physically going to user studies.” They also recognized that “time and bandwidth don’t usually allow for this.” If you’re unsure about your own teammates, it’s probably best to ask. Here are some of the other answers I got:
- “I prefer to not partake in actual sessions and just read notes before.”
- “I like to observe some user research [studies]. I don’t prefer to lead those though.”
- “I like to be informed about user research in 3 ways [quick presentations, shared documents, or raw interview notes].” “Picking one is usually fine, but if I have all 3, I’m a happy camper.”
Engineering involvement can clearly range from passive information to fully participating in research studies. Is it worth the time to invest in this kind of collaboration?
Benefits of engineering involvement
Is engineering involvement in research another task to check off the list? Is it unnecessary work? Here are just a few of the benefits I observed from my discussions.
Finding better solutions
Whose job is it to find solutions to user problems? If you answered “designer” you may be at odds with your engineering counterparts. Many engineers I spoke to recognized the value of deeply understanding research. This empowers them to explore alternative—and better—technical solutions.
“[When an engineer understands the user, they] may be able to find ways to optimize their time and provide an equal or better outcome to achieve the same goal the user is seeking.”
Creating user advocates
Some designers make themselves martyrs believing they are the only user advocate. They may see others on the team as driven by speed and greed.
I won’t lie, I have occasionally come across team members like that. But as I mentioned, the engineers I spoke to expressed interest (and even excitement) in consuming research.
Sharing research helps the team to think beyond themselves:
“Sometimes, there’s a gut reaction of ‘I wouldn’t like this as a user,’ where I have to step back and consider other types of users vs how I use apps.”
I’ve seen engineers who get close to user research often champion what they learn to the rest of the team. They feel the impact of what they’re building.
Emotional connection
Anyone who builds something deserves to feel the rush of watching someone use it. This creates an emotional connection with the experience. One engineer mentioned how much she enjoys tying decisions and work “back to a specific learning (directly related to something someone said).”
It’s a well-known secret to success that “No matter what level the employee is at, [they] should be able to articulate exactly how [their] efforts feed into the broader company strategy.” (HBR) In the context of building products, I would add that employees should be able to articulate exactly how their work solves someone’s needs.
Research insights are the glue that connects code and architecture back to the people it impacts.
Building a culture of “why”
Related to emotional connection, a common theme in all my discussions was a desire to understand the root of the problem. What is the core of the current project?
I believe in a team culture where any team member can slow down, ask “why”, and get an answer backed by research.
To build this culture you may need to think more deeply than before. It requires showing how a specific design or decision fits into a broader vision to solve customer needs. Consider how these engineers’ perspectives change when they have research insights in hand:
- “It’s easier to get behind something when I understand what the long game is.”
- “If you can share the full context, data, and research behind a design decision, developers will understand and help you make things happen”
- “I just want to understand and make sure we’re building the right thing”
- “I like to build [something] that’s useful to [the] end-user rather than simply shipping the feature”
I find that questions from teammates often expose gaps and flaws in my thinking. If I can’t answer them, I probably missed something in my research. If I can answer it but someone else can’t, I have an opportunity to share what I know and create a research ally.
If research is transparent, accessible, and well-communicated the whole team can unify to solve the same goal.
Making research accessible to engineers
Engineers shared with me how valuable research is to them. It’s fundamental to ensuring high-quality work. One engineer mentioned that “a design should include the user research and any data that can help an engineer understand the customer during implementation.”
How might a design “include” the research necessary to propel an engineer forward?
After these conversations, I kind of view research consumption preferences like learning styles. Some prefer to read, others prefer to listen, and some like to get their hands dirty by trying it on their own. Based on my discussions, the right answer likely relies heavily on your team dynamic (or on the individual). As one engineer said:
“Typically I’m happy with just reading a high-level summary of learnings, reading through interview notes, or watching recorded interviews. Really, consuming anything that gives me the customer perspective is always helpful.”
What should this look like on your team? Here are some ideas based on my interviews and a few of my own experiences:
- Using team meetings (kickoffs, weekly meetings, all hands, etc.) to share research projects and insights
- Linking to research summaries, data dashboards, feedback tickets, and other documents within design files (using a “table of contents” method or in context with the screens)
- Having an open-door policy on all interviews and user studies. Allow engineers (or marketers, or whoever) to observe whenever they have time. You might want to create a shared team calendar or notification system for this.
- Sharing an internal research repository to make research insights easier to find.
- For fully distributed teams like mine, sharing daily Check-ins (like a virtual stand-up) with links to notes, recordings, and summaries.
- Sending out a weekly or monthly “research newsletter” from your team.
What if an engineer on your team wants to be fully present in studies? Should they? Others have given polarizing and absolute answers to this question. I see it more as a question of tradeoffs. What do you gain and what do you lose by having engineers spend time on research efforts? What does the team need right now?
If you or your team are interested in experimenting with more engineering involvement, it might be worth trying something simple. Engineers could take turns rotating through research studies, or the team could set a goal (e.g. attend one study per month).
What makes your team or company unique? How can you leverage that culture to make research more accessible?
Conclusion
How would your rate your own team’s involvement in research? What could you gain by increasing involvement?
Involving engineers in research may require significant cultural changes, such as being research-driven or transparent with information. I’ve found the benefits to be well worth the small effort of sharing my insights with team members. Hopefully, these interviews give you some ideas to do the same on your team!
If this was helpful, consider giving the Twitter thread some love:
