Are teams ignoring your user research? 6 keys to increasing impact
Want research to drive change? Drop the reports and presentations, and turn research into a team sport.
For our agency’s first 5 years, we used the traditional approach to user research: teams hired us, then we disappeared to conduct research and analysis, and returned with a big report.
Over and over, our research failed to drive change. No matter how clear the problems and opportunities were to us, teams nodded politely — and then largely ignored our findings and recommendations.
Frustrated by this lack of impact, about 6 years ago we began to experiment with more collaborative approaches to research. We started by adopting Jared Spool’s variation of the KJ-Method, where we brought diverse teams into the observation and analysis process. Immediately, we saw a difference: teams that previously ignored research began to internalize it, act on it, and ask for more.
Since then, we’ve borrowed, adapted, and mashed up many other collaborative techniques, including those from design thinking, the Google Ventures Design Sprint, the Lean Startup, and Gamestorming.
While we are not done experimenting, we can confidently say this: if your goal is to drive human-centered change, team sport research blows away traditional expert-led research.
And yet, based on what we hear and see from clients, we estimate that 90–95% of consultants and in-house teams use the traditional approach to user research. Their impact lives or dies with their report or presentation. And most often, it dies — no matter how great the research and analysis — because other teams were not part of the process.
The result: most research is failing to drive the positive changes that it could — whether it’s an organizational transformation, a new product strategy, or a small usability improvement.
Ready to try switching from traditional research to a more collaborative approach? Based on what we’ve learned during hundreds of projects, here are 6 key differences between the approaches, along with specific tactics you can adopt to make the switch.
How to Switch from Traditional Research to Team Research
1. Depth of Observation
Traditional Approach: Researchers conduct the research and share highlights and clips in a report and debrief. Result: Stakeholders gain a superficial understanding of users and their needs.
Team Approach: The stakeholder team observes significant amounts of raw user research directly and in depth. Result: Stakeholders develop a deep understanding of users and their needs.
2. Stakeholder Diversity
Traditional Approach: The team that watches extended research is limited, often to just researchers. Result: Development, product and design teams fail to align on many critical decisions.
Team Approach: Non-researchers, including designers, developers, product owners, and management, are part of the team gaining in-depth exposure to users. Result: Teams develop a shared understanding about users and reach consensus on key decisions more often.
3. Frequency of Observation
Traditional Approach: Most stakeholders’ research exposure is limited to large, ad hoc, and infrequent studies — twice a year at best. Result: It is easy to ignore persistent problems and forget about user needs.
Team Approach: Over time the diverse stakeholder teams observe in-depth user research at least once every 6 weeks. Result: It is hard to ignore persistent problems — and easy to keep an accurate picture of users in mind during design decisions.
4. Problem Analysis
Traditional Approach: Researchers analyze and synthesize the research and share their problem findings in a report and debrief. Result: Stakeholders often hear what they want to hear, and dismiss findings that contradict their assumptions. Disagreement about top problems persists.
Team Approach: Researchers teach stakeholders design thinking techniques and facilitate a structured process to analyze and synthesize problem findings as a team. Result: False assumptions die quickly, and the team gets on the same page about the biggest problems worth solving.
5. Solution Generation
Traditional Approach: Researchers brainstorm ideas and recommend solutions in a report or debrief — sometimes supported by sketches or wireframes. Result: Stakeholders dismiss solutions they don’t like — often rightly so. But because they lack the research context and/or design skills, they struggle to generate alternative solutions that move the needle.
Team Approach: Researchers lead stakeholders through a step-by-step process to generate, sketch, combine, and critique ideas — both individually and in small teams. Result: Because they generated the solutions themselves, teams are more likely to implement them. And because those solutions embraced design thinking and the diverse knowledge of the team, they succeed more often.
6. Researcher Role & Value
Traditional Approach: Researchers focus on 1) analyzing research, 2) designing solutions, 3) and presenting reports. Their value lies in UX expertise plus their ability to persuade others. Result: Relationships are often tense. Partner teams “just don’t get” researchers’ advice; researchers “just don’t get” the team’s business/IT/design constraints.
Team Approach: Researchers focus on 1) exposing teams to users, 2) teaching research methods and design thinking, and 3) creating a habit of user research. Their value lies in facilitation, empowerment, and program-building. Result: Because the partner team is an active player throughout the process, both sides work through disagreements in real time, with data. Relationships are more harmonious and productive.
From Telling to Teaching
When we bring these 6 keys together, we get this single, guiding principle statement:
For a user research program to be effective and impactful, it must empower a diverse stakeholder group to frequently observe users directly and in depth, and to analyze and solve problems collaboratively — supported by expert facilitation.
The team approach to research isn’t a silver bullet. It has plenty of challenges, such as getting partner teams to invest the necessary time to observe research and teaching engineers to ask open-ended interview questions.
But in our experience, these are solvable challenges in many organizations, especially when you start small and practice patience. As 1 or 2 teams experience the power of collaborative user research, they spread the word to other teams, and momentum builds.
Over time, instead of telling teams about their users, you’ll be teaching teams how to conduct their own user research. And eventually, your impact as a researcher will grow in ways you never thought was possible when your main deliverable was a report.
