4 Reasons to Get Your Whole Team Involved in User Research

February 10, 2022 Wal Gedeon

As a product designer at VMware Tanzu Labs, I’m often having conversations on the value of design in product development. I was discussing design with a client stakeholder one day and made the comment that “Nobody can tell who the designer is on my team.” At first, they were a bit confused by this statement. “Aren’t the designers the ones who create the designs of the product?” they said. “Surely not everyone knows their way around the tools used to do that?”

But I wasn’t talking about the UI or visual design; I was talking about the understanding and empathy of the users that design brings to a team through discovery and research. In our case, the entire team—software engineers, stakeholders, product managers, and more—were contributing to developing that shared understanding by being involved in the research and user feedback process, which in turn helped everyone be more connected to our users and the problems we were building solutions for. Our team wasn’t just clearly aligned on the “what” and the “how” but also on the “why.” 

Now, this isn’t a new concept, but it’s rarely utilized, which is a huge missed opportunity to solve some of the problems that product teams experience. I’ve come across many of these problems over the years: Stakeholders asking for features instead of trying to address actual user needs; designers holding the majority of the context, which gets lost if they move to another team; or teams simply not being aligned on why they should be doing the work in the first place. 

At VMware Tanzu Labs, we help clients address some of these challenges by showing them how to work in multidisciplinary teams (we call this our Balanced Team approach), and empowering the team to be involved in speaking with users. This helps them make better decisions, move faster in developing great products, drive better outcomes, and increase the value they are able to deliver.

Here are four benefits of getting your product team involved in user research.

1. You’ll spend less time explaining problems and more time solving the right problems.  

Most people develop a better understanding of something when they experience it or hear it themselves, so having others in your team join research sessions to observe or take notes can reduce the effort for everyone to build empathy about those they are building products for. This will also allow the team to spend less time explaining the context around problems and free up more time to discuss how or why you’re going to solve them. 

Tip: Create a shared research calendar so everyone can be aware of what sessions are coming up. If you have a large team, get everyone to rotate so they all get the chance to hear from end users and possibly lead the interview themselves.  

Stock photo showing an overhead view of four co-workers collaborating on sketches of a mobile app

Image credit: Adobe Stock

2. You'll ask better questions and find ways to improve your research

When running research activities or experiments, it's common for teams to simply use the tools or approaches they've always used to gather insights. “Let’s send out a survey or build a clickable prototype and test it.” If you bring other disciplines in, you'll often uncover ways to learn that you didn't think of before. Engineering might suggest it's faster to put a prototype together in code than with Figma, which will bring a more realistic experience for your users. Or a product manager might suggest to also include a survey to support qualitative data to help paint the picture of the return on investment (ROI). 

Tip: Invite some of the team to research planning sessions. This includes writing screener surveys, assumptions mapping, script writing, or when setting success metrics. Having more than one team member’s perspective on how to get the insights you need will speed up the process and improve the quality of your learnings. 

Stock photo showing an overhead view of five co-workers collaborating around a table and looking at sketches of a mobile app

Image credit: Adobe Stock

3. You’ll reduce the time to get from from to insight to action 

Even a lean approach to research takes time and effort, but by having a broader team involved in the process, it's faster to get from raw notes to clear, validated learnings to taking action and delivering something valuable. By bringing in other members of the team (e.g., product managers, software engineers, stakeholders) to not only help take notes but also to synthesize learnings, teams can speed up the process of making decisions and moving forward.

Tip: Make reviewing and summarizing the learnings (AKA research synthesis) a team activity, and encourage conversations while you’re all in the room. Some of the conversations that get sparked when everyone is doing these activities together can really help the team get moving!

Stock photo of a person discussing sticky notes on a whiteboard with a table of teammates looking on

Image credit: Adobe Stock

4. Your teams will be more engaged about the products they deliver

From my experience, teams that have shared ownership of what they are developing because they’ve been (even for the smallest amount of time) part of the process to go from an initial idea or problem, to delivered solution, ship value faster and get more excited about the work. Getting your team involved in more steps of the development process makes the whole team feel involved and empowered rather than handing stories and tasks to engineers and expecting them to be excited about acting on them. 

Tip: Ask your team which part of the process they are excited about being part of. Some might be more interested in discovery research, in which you look to uncover the problem and opportunity space, whereas others might be more interested in taking part in concept or usability testing. Once they’ve taken part in one part of the process, invite them to some other activities and expose them to other opportunities to be more involved. 

Stock photo of three co-workers working together at a computer

Image credit: Adobe Stock

Now, I’m not suggesting that everyone drops what they are doing all the time to be involved in research activities, because code still needs to be written and valuable features still need to be delivered. But I am suggesting that getting more people involved in research will give your teams a superpower that allows them to move forward faster and get more excited about the value they are delivering to both the users and the business. 

Learn more about design at Tanzu Labs and check out the VMware Tanzu Labs Design Guide.

About the Author

Wal Gedeon

Wal Gedeon is a staff product designer at Tanzu Labs in Australia. User-centered and business-minded, he's always looking to push the boundaries of problem solving with technology and is passionate about elevating organizations through outcome-driven strategies, innovative and research-led solutions, and forward-thinking product design.

More Content by Wal Gedeon
Previous
How to Get Started Securing Your Internal Software Supply Chain
How to Get Started Securing Your Internal Software Supply Chain

Shifting security left doesn't mean forcing developers to become security experts. In this podcast episode,...

Next
5 Tips for Adopting a Product Mindset for APIs
5 Tips for Adopting a Product Mindset for APIs

Designing and building APIs might seem like a different animal from traditional customer-facing products, b...