As more and more orgs realize the importance of quality user insights, the demand for good research is higher than ever—and it’s up to UXRs to react.
dscout partnered with AnswerLab to host a panel of research leaders and explore how they're responding to the ever-growing demand, and visibility, of UX insights.
Jennifer Keller (AnswerLab), Judd Antin (AirBnB), Julie Norvaisis (LinkedIn), Katy Mogal (Google), and Sabrina Kang (Charles Schwab) highlighted three key ways they're reacting to new research needs: rethinking strategy, democratizing execution, and optimizing their team's structure.
The answers you find from your tactical work can and should influence the team in strategic ways…Today’s tactic is next week’s strategy.
Julie Norvaisis, LinkedIn
Being strategic...and tactical
These leaders know that to have the most impact, research needs to punch "up" and resonate with decision makers in the C-Suite. Too many projects set at a high altitude, however, and your team might be called “launch-blockers” for holding up product and feature releases.
UX needs to test concepts, wireframes, and conduct usability studies—being tactical and forward-looking. That means asking ambiguous and complex questions about user environments, new product categories, and emerging modes of engagement.
Increasingly, top teams are thinking of ways to move their work beyond validation and iteration—without being a "burden" on their "delivery-focused" organizations.
Julie (LinkedIn): We're trying to weave our UXRs earlier into the process of innovation, so we're right there at the table as strategic decisions are being made. There are fewer people to engage with, however, when working on high-level strategy. To reach teams where they are, the strategic should have tactical implications: you should always be thinking about the details of the thing you're building.
And there are strategic implications to (just about) everything a researcher does, from usability work to evaluation projects. It's imperative that researchers on my team understand the strategic implications of all of their work.
Really, the distinction between strategic and tactical research non-existent. It's a myth. A truly great experience is going to come from thinking about tactical elements. The answers you find from your tactical work can and should influence the team in strategic ways. Good researchers are thinking about their work iteratively: today's tactic is next week's strategy, especially if your UX team is working across product teams.
Sabrina (Charles Schwab): There's an organizational hunger for themes and trendspotting across teams and products. We hold quarterly share-outs for these. Recently, we've been thinking about and investigating in the idea of "digital confidence" and how it both affects our experience across products and how we can be building for it.
A lot of the work we do is quick-iterative and we're always asking, "How can/does this test influence this or that question?" Experience strategy is still evolving at Schwab; more is needed. Driving strategy helps us all reconnect and check in on the work we're doing as a team. Our strategy comes from these jam sessions and lets us create larger readouts for leadership, who are really hungry for strategic level insights. And because those leaders aren't in the room with users like we are, they're usually blown away. For us, strategy is about serving as the user advocate.
Katy (Google): Because our team is still growing, tactical work is key to building out important programs. It is easier for us, in an embedded structure, to get bogged down, caught-up, or overly focused on and in the lab. It's really on the senior researchers or leader(s) of the team to inject strategy into the day-to-day work. It's important to find a way to balance the tactical work necessary to launch a product, and the strategic work that we recognize the need for, even if stakeholders don't always see the immediate value.
There's the potential to be awash in data but low in insights in any organization. It's something we're really thinking about: synthesis across our research teams and the different kinds of products. We're working to come together more to share resources.
We're thinking a lot about how to better showcase the imperatives laid out in our work to our stakeholders. What's worked in my experience is bringing together different data streams across teams and weaving a cohesive story for leadership.
Takeaway: Make the tactical, day-to-day work your team does strategic, by reminding them of the roll-up value, partnering with other teams/groups, or even syncing together to trend and theme-spot. The more consolidation of data streams into stories, the more strategic your work can (and will) become
We [UXRs] need to not be gatekeepy about who gets to say an insight.
Judd Antin, AirBnB
Making user research a team sport
Sometimes the best—or only—way to respond to the increased research demand is with more hands and brains. But if your team is maxed out and headcount isn't going to grow immediately, who do you turn to? Some of our research leaders are enabling others to get involved through DIY and self-service programs. Stakeholders like engineering, design, and product teams are pitching in to contribute.
Julie (LinkedIn): There were so few of us in the beginning and so much demand that we just had to empower designers to get involved. We created a "Bento" kit for designers to get some training in research methods and start working with researchers more closely on answering their questions.
This has grown into a UXRs University where training is more standardized and formal, where we explore sharing insights and making conclusions appropriate for the selected method. This has the byproduct of injecting empathy into the work my UXRs are doing, as our teammates get to see how challenging and time-consuming this process can be.
Judd (AirBnB): I've found that sometimes researchers can be too precious about "non-researchers" doing the research "wrong." We [UXRs] need to not be gatekeepy about who gets to say an insight; that just doesn't end up helping anyone.
We're being careful about equipping folks correctly, so that they're still recognizing the value that researchers offer. And training someone to do a first foray shows them the value of having a user-insights design research team for those technical, specialized research questions. Together we can answer a lot, especially with that shared empathy for knowledge.
I strive to avoid the "safety blanket" research that merely confirms values. I want my team to say "no" more, which shows that you (as a researcher) are judicious and that research isn't a crutch. Sometimes we can just ship a thing; other times, there's a real need to dig into the user experience. Saying no gives you credibility and increases the impact.
Katy (Google): To that point, saying no and leveraging research under certain circumstances shifts it from a service to a partnership within the organization. I'm always encouraging my researchers to ask stakeholders, "What might this change?" and if a stakeholder has a hard time answering, then we don't pursue it.
Julie (LinkedIn): We've been thinking about ways to socialize the decision processes we employ for whether or not a question "needs" research. This, we think, would improve the visibility of the work UXRs do, and empower our stakeholders to engage in some of the decision-making we would ordinarily do. Certainly, we want them to upkeep a dialogue with us, and a shared decision set might be useful for speed.
Takeaway: What self-service model might you scale within your org to get traditional stakeholders—like product managers, designers, and even engineers—involved in the research process? Could you upskill them in a small set of methods and co-create work? Finding ways to co-enable can lessen the burden on the central team, freeing them to tackle the more pressing and complex questions.
We’re awash in data but low in insights in data-hungry orgs.
Katy Mogal, Google
Team structure: Embedded, agency, or hybrid?
Most of these leaders have played with different models of team composition: from agency models, where the team serves a reactive consulting function, to embedded models, where researchers work within specific product/business units. Some structures are better suited to demand response; others, less so.
Judd (AirBnB): AirBnB grew quickly and we started as a very embedded structure, which led to technical expertise among my researchers for the area they served, but also to territoriality among product owners. These product areas wanted more researchers, but "their own" researchers, which is not working toward our broader goals.
I've seen this same pattern play out at a few other places, where folks are doing great work in their slice of the world, but then it becomes harder to collaborate are rise up to see what others are doing. As such, we're clawing our way back to create structures to allow for cross-functional collaboration and not be so deeply dug in.
Katy (Google): Embedded models have many benefits. However, there can be lots of parallel work going on. We're thinking a lot about how to create a structure that both leverages the subject-matter expertise of embedded but also creates a strong community that is invested in knowledge sharing.
Jennifer (AnswerLab): Because our researchers serve as partners to clients, we're trying to structure a team that allows folks to specialize in verticals, industries, and/or methods, and to rotate to teams where their knowledge is best utilized. This both helps get the clients the best possible solution and upskills other researchers in those areas of knowledge. That's especially helpful because our team is across the country, and it facilitates a spirit of teaching and education.
Sabrina (Charles Schwab): We are very much embedded right now, and that in part comes from the funding and prioritization structure we have. As others have said, we are getting to the place where I'm trying to get more researchers in the room together for knowledge sharing, because it feels like there isn't enough sharing across our researchers in the embedded model.
We grew very quickly: from five to 30! As we've matured, embedded(ish) is what we have evolved into. We are, ultimately, funded by product teams and working closely with them elevates the work we do and keeps it top-of-mind organizationally. We've been trying to think about ways to combat silos and create a connective layer across the product groups. For example, we've got practice areas (e.g., formative, evaluative) where researchers can jump in and support regardless of the product area or business unit.
Julie (LinkedIn): Our team structure is always evolving and shifts with the org; it changes each year and so we too seem to change right along with it. Team community is a big part of how I'm structuring it today, trying to cross-pollinate even in a hybrid structure, where we're moving now.
Today we have pods serving concepts that look at broader user motivations that map to product areas. These can even cluster together. Again, these can be embedded, but we're reactive and thinking about where to point people for a certain product; we're really trying to be fungible and nimble. For us, it's really important to be flexible and open to trying new things; we're developing products, and so our team structure should be developing, too.
Takeaway: Many research teams start as embedded to build product area expertise. Eventually, however, organizations may need to shift to a hybrid model where more data are shared and insights culled together, to avoid too-narrowly focused or subject to tribalism within orgs. There's no one way to structure your team, but all these leaders believe that staying flexible and open to shifts is a best bet.
Bonus: What's Your One Big Focus For 2020?
Julie (LinkedIn): Infusing diversity, inclusivity, and belonging both within the team and workforce, and in the workplace's decision making about anything from buttons to strategy. I want to include more voices in every aspect of our business—our users are diverse and our organization should reflect that.
Sabrina (Charles Schwab): Privacy. As we continue to grow and scale the team, we need to keep the right of privacy at the forefront, especially as the hunger and demand continues to grow. We have a responsibility to our users to build a strong privacy practice and that will be very top-of-mind for me in 2020.
Judd (AirBnB): I keep thinking about how we need to build a representative research practice to best serve our global community. Even though AirBnB researchers are located in a few places across the globe, our hosts and guests are everywhere. How can we keep thinking globally in our practices?
Another concern is how we can build an industry that nurtures folks new to UX; we all ended up here from different paths...is there a way we can make more accessible the work we do to those just getting started? The pipeline needs to be welcoming to anyone with the talent and interest to enter this field.
Katy (Google): I'm really deep in building the Assistant UXR team, and Google has a lot of work looking at effective leaders and high-performing teams globally, so we've been thinking a lot about hiring and balancing that with effective team scaling. There are lots of backgrounds that can generate great insights about users—journalists and data scientists being two examples.
Jennifer (AnswerLab): We've grown a team of folks hungry for diversity of methods and industry representativeness, and I'm wondering how we can create a program to keep that sustained. It's shifting this initial desire to a community of practice and a platform to support our clients in the best way for the future.
Ben is the product evangelist at dscout, where he spreads the “good news” of contextual research, helps customers understand how to get the most from dscout, and impersonates everyone in the office. He has a doctorate in communication studies from Arizona State University, studying “nonverbal courtship signals”, a.k.a. flirting. No, he doesn’t have dating advice for you.