IBM is big. We have around 350,000 employees including 20,000 design and user experience professionals, and only a fraction of them are experienced design researchers. Many of you reading this also work in or with large enterprise organizations and, as you know, at that scale it can be easy to get lost. At times, you might feel your research is undervalued and that you, as a researcher, are marginalized. We’ve been there, too, so we’ve identified some strategies that help to both address these issues and grow understanding at scale.
Crucially, we believe that the whole cross-functional team, not just the researcher, bares equal responsibility for advancing an understanding of the people the organization serves—more colloquially users, customers, constituents, and communities.
At this point, you may be thinking, “But wait…I’m not sure I trust my peers to not ask leading questions. I’m not sure they’ll pick the right methods, identify the right participants, or analyze the data without bias.” And your concerns may be well founded. But participation doesn’t have to come at the expense of rigor.
At IBM, we have seen that by extending a research mindset and some basic research skills we can empower exponentially more people to do more research and rapidly grow our collective understanding of our users and user groups. Greater participation can be compatible with rigor and truly augment the scope and impact of research for your organization.
Within a team setting, we’ve identified two key roles: Research Explorers and Research Guides. These titles help team members identify research as a collective process in which everyone has a concrete role. An Explorer has little applied research experience but participates in and helps with research activities. Explorers use their domain expertise to help identify what questions to ask—and answer. At IBM, Explorers include technical architects, product managers, engineers, support, sales, even designers.
Conversely, Guides have deep research experience. They facilitate the practice across their team and ensure the core rigor of the research program. They regularly gather and curate questions and assumptions from their team and identify frameworks and methods to address them. Guides craft and curate insights to inform the creation of better user experiences. They leverage their experience to help others discover things they didn’t know existed. We’ve found that when a team has a Guide (or at least access to one) their ability to reach meaningful insights is magnified.
The following stories from design researchers at IBM share advice on how to create a successful Explorer/Guide relationship.
Tip 1: Embrace the technical domain expertise of your peers
By opening the aperture of who is “allowed” to participate in formal research activities with users, we can greatly increase our understanding of the domain and improve the likelihood of uncovering a true insight.
The benefit of a multi-disciplinary team is that everyone has a different skillset and perspective to contribute. So lean on other subject matter experts for the value and ideas they provide. Involve Explorers in research planning and invite them to observe the research activities: they can help ensure you’re asking the right questions and might even catch a salient point that you’ve missed.
We’ve seen this happen at IBM. A researcher was conducting an interview, and his technical peer picked up on a comment that the rest of the team had missed. The team discovered their users wanted to import a specific type of data that, at the time, wasn’t something Product Management and Design had even considered including. Without the technical peer in the room, the team would have skipped over the comment, but thanks to the team’s inclusive approach to research, they were able to create valuable functionality that was a key point of differentiation from competing products.
Tip 2: Train your Explorers and put them to work
Share your research expertise with others in an effort to include and empower them. Teach other teammates, who frequently interact with customers and clients, to ask better questions and reduce confirmation bias.
One of our colleagues at IBM is the sole researcher on a team of hundreds. Lately, he has partnered with client executives and solution architects to help extend his reach. Since the researcher cannot physically join every client visit (nor should he), he’s helped client executives and solution architects to ask more probing questions coupled with good follow-ups. The team now embraces these new skills and shares back new insights with the larger team. To make it even better, this sharing is formalized and very intentional. Now, when a client-facing teammate logs client requests, they include user quotes to provide additional context and a human-centered lens.
The team leverages existing communication channels to extend the reach and discoverability of the insights.
Tip 3: Always trust your instincts about going “under the hood”
You’ve heard it before, but the saying goes for team-based research, too: always trust your inclination about when, where, and how to bring your team into the process. When your goal is to drive consensus, finding the right moment to bring the team together is key. Stay in tune with your stakeholders and teammates. Are they primed to buy into the process? Or are they still seeing research and design as an ‘other’? When in doubt, remember: you are the expert.
Another researcher at IBM was working on some in-depth analysis but decided to stop short before she completed it. Instead, she created an affinity map and then invited her teammates to join her in identifying the key insights. This tactic really helped drive consensus and create a sense of ownership for the decisions that were made and the next steps that were identified.
At other times, the same researcher has a need to deliver un-biased, hard results to a team to in order to help them avoid focusing on random data points that support their own point of view. As researchers, we know that a single conversation shouldn’t frame a team’s whole point of view on what’s right. Similarly, data can sometimes be inconclusive. As the Guide, it’s important to lean on your own research skills to inform your recommendations.
Tip 4: Create organizational conditions
Expect everyone—from leaders to new hires—to adopt a human-centered mindset and embrace diverse teaming. When you position some type of human-centered approach as a strategic skill for the company, that mindset will set you up to do research that is more in-depth, of higher quality, and more inclusive of your colleagues.
Organizationally at IBM, we’ve embraced design thinking in a big way. We are lucky to have our CEO regularly extol its virtues and its importance to our future success. In your organization, it doesn’t necessarily have to be design thinking—it could be any human-centered, iterative, whole team approach like design sprints, customer experience, lean, agile, and more.
It can be easy to write off these approaches as too democratic. Of course, it is essential to understand the value of highly trained human-centered researchers. But concerns that a broad practice of human-centered design dilutes the skills and rigor of “experts” should be dismissed. Design thinking has created time and space for more research to occur at IBM. It has brought research out of the lab (or the field) and into the mainstream lexicon of the company.
So what do you think, EPIC Community? Have you tried any of these tactics in your organizations? What successes or failures have you seen? How do you create the conditions for great research to occur and be valued by your organization? Share your stories in the comments below.
Editor’s note: IBM is an EPIC2019 sponsor. Sponsor support enables our unique program that is curated by independent committees and invites diverse, critical perspectives.
Eleanor and Chris work for IBM’s Design Program Office in Austin, Texas. Their team is focused on creating a sustainable culture of human-centeredness at IBM. We believe that great user experience is the differentiator that most readily impacts the business. Our program is tasked with creating a culture where the users of our offerings—real people—are the most important bellwether in product development. Our goal is to bring a sense of humanity into the complexity of enterprise technology. You can read more about our point of view on research at ibm.com/design/research. A special thanks to Ashley, Ellen, Frances, Jonathan, Nicholas, and the entire design research community at IBM for sharing their experiences from the field that informed this piece.
Photo: Reaching by Andrew E. Larsen (CC BY-ND 2.0) via flickr
Related
Scale, Nuance, and New Expectations in Ethnographic Observation and Sensemaking, Alexandra Zafiroglu & Yen-ning Chang
The De-skilling of Ethnographic Labor, Gerald Lombardi
Hyper-skilling: The Collaborative Ethnographer, William Reese et al
The Rise of the User and the Fall of the People, Shaheen Amirebrahimi
0 Comments