From the anatomy of an insight to the business of research

I’ll start by discussing the core components of an insight and specifically what differentiates insights from learnings. Then, after we’ve developed these juicy, compelling insights, what do we do with them? (Because insight production is only about 25% of our research role.)

Okay, let’s get into it.

Insights - core components and how to differentiate them from learnings

Data points are things that we think about as raw data. They can be implicit—ones that we’re already measuring, and we look at our dashboards to see. Or, they can be results from one-on-one interviews, notes, and other outputs from our surveys. Think about them as data points—points of information coming from users.

A practical Fintech example

Imagine you work at a Fintech company and are building out their website. An example of a data point is when users can’t find the credit card application on a bank’s website. Learnings then take those data points and look at trends and patterns. They’re one level up. And so, if you can imagine, we’ve got similar data points, but users cannot find something.

An example of a learning might be: [Poor] information architecture is a barrier to users navigating the site.

What differentiates insights from learnings is that insights take those learnings from user research and tie it back to the original business objective we went into the research to do. Imagine one of the metrics we were trying to move is conversion rate. An insight would be that making card applications more discoverable will raise the user conversion rate.

So, it takes what we learned in the research and then ties it back. It also calls out that opportunity—here’s something we can do based on what came through in the research.

Speaking the language of insights

While working with product teams, collaboration improves when we speak the language of solutions or insights—by taking that extra step and raising the opportunities coming through the learnings.

Instead of just surfacing user problems and saying: Hey, these are things that users need, which we must fix in our product. We take the next step, saying: Here are some recommendations to get us closer to our goal and serve the user.

This sets you up to co-create solutions rather than just sharing learnings. It can be tempting to have the learnings and say: Hey! Look at this new thing we’ve learned about our users and how they interact with our products. Isn’t this really, really interesting? (And sometimes, those learnings are less interesting to product teams than they are to me as a researcher).

Taking the next step: Hey, this is also what we can do with it, is really helpful for our product partners. They respond a lot better to that.

Yes, researchers should make product recommendations This brings us to a controversial conversation in the UX research community: Do researchers have the right to make product recommendations?

Or should we share what we learn with our teams and allow our product teams to determine what we will do with that learning? (And it’s clear where my standpoint is based on the opening to my talk).

But I’ll tell you anyway: the answer to this question is in the definition of insight.

Insights are not just sharing learnings. They’re identifying opportunities and making recommendations based on those learnings. As researchers, we are responsible for knowing our product space, our problem, our market, and our business objectives so that we’re best positioned to make those recommendations.

Who better than the person who knows the business really, really well and also the person who knows the user and what we’re building for really, really well?

A typical product team at a tech company has many different roles, right? We have product professionals: data scientists, researchers, product designers, and content strategists. We’ve got PMs, PMMs, and engineers.

Overall, before each of our functions, we’re all product professionals. We’re all responsible for driving the product forward when working in our roles, right? As product professionals, it’s all our business to know our business objectives and help our companies get closer to them.

Shifting the narrative - UXR to ‘strategic product partner’

As researchers, we have this rap of not being revenue-generating roles or not being business-involved roles and just being involved in the quality portion of a product or a workflow. And that’s just not the case, right? And as researchers, we’re storytellers. So, it’s our responsibility to tell that story, and we can shift this narrative through storytelling.

Traditionally, on a product team, we’ve seen that kind of business sense represented in the PM and PMM roles. But nowadays, in 2024, every function across a product team is expected to have a strong business sense.

Do you understand how your work ladders to the overall business objectives and impacts the bottom line? (Things like revenue conversion rates or metrics the company is paying attention to?)

Do you also understand how business priorities set by leadership trickle down and impact how you should prioritize your work? So traditionally, researchers and designers have been kind of pigeonholed to, “Oh, we just talk about quality, or we just do research.”

But our titles or our functions are just the toolboxes that we have—they’re not meant to silo us. I’m a person who does research at the end of the day. For each of our functions, we are product professionals who use what’s in our toolbox. I do a lot of research but I am also a strategic product partner.

I just want to acknowledge that this might rub some folks the wrong way—thinking about research as someone responsible for revenue generation and the business. I want to put this into language that resonates with researchers. When I talk about driving products forward, some examples of how we do that in research are

• Building more accessible user flows

• Improving user interfaces or increasing the efficiency of a product according to a user’s jobs-to-be-done

• Better problem-solving of our priority pain points

Stakeholders are users, too

As storytellers, we must tie in our objectives and how those impact the business’s bottom line. A lot of times, there’s a different timeline for when our impact will land. And so it’s our job to continue building on those insights and maintain a body of work that keeps them relevant and tells the story.

We can have a short attention span on product teams with so much reorganization and movement. So, we need to remind our product teams often—and in spaces where they’re paying attention already—what kind of impact our insights have had and how it’s directed—the direction we’re going as a product.

Considering our product partners as users is helpful when discussing this kind of revenue generation democratization. We spend so much time and intentionality around how we build for users, their journeys, and things like that. But when we think about working internally on these product teams, our stakeholders are our users, too.

If we imagine them as our users and our product as our insights and think about:

• What are the goals that they’re trying to accomplish?

• What do their journeys look like, and what do their timelines look like?

Then we are addressing that tension that sometimes comes between product and researchers—vying for quality of the experience and advocating for users—and vying for the business and the metrics we’re trying to accomplish. Or speed of shipping our products or services with the democratization of revenue generation.

Democratizing user-centricity and quality

In 2024, we’ve also seen the shift of democratizing user-centricity. And to be clear, I’m not talking about democratizing user research. Researchers should do research—we put a lot of time into learning human-centered design and understanding how to do user-centered research.

I’m talking about democratizing the responsibility of building based on our users and holding them at the center based on what we built.

Often, designers and researchers are responsible for driving quality. But we all have the same goal as product professionals and teams. We want to build great products that are sustainable, accessible, and lucrative and grow. And so there shouldn’t be this kind of siloing of which part of the quality of the product.

As product teams, we all must understand our business objectives and the quality we’re targeting.

Shifting the culture

To do this, we need a culture shift within our tech companies. We, as researchers, are really at the forefront of driving that cultural shift. For it to be a shared responsibility, we must all be held to the same metrics. Product teams, rather than just measuring based on the speed of shipping something or the growth of a product, have to look at things like sustainability, quality, ease of use, and accessibility.

A big piece of this is connecting the dots between insights landing and the impact of those insights. It’s only sometimes immediately apparent based on what we’re doing, depending on the type of research that you’re doing or where in the life cycle you are of a product. And so, some things came to mind when I think about connecting the dots between insights and what we want to do with them:

Be in the spaces where people are already paying attention

Rather than trying to get our product partners super excited to come to research readouts—which they should be (!), we must actively build out those product strategy documents.

Whether it’s posting online internally or attending meetings that are typically deemed “for product” or “product-forward” and bringing that design research element in so that it’s not an afterthought, it’s not a separate meeting. We have to participate in those conversations because we’re product professionals.

Make it clear how data determines the priority of your work streams

Often, research helps us prioritize what we’re building and when we’re building it. And then as we go through quarter by quarter or half by half. It can get easy just to think, “These are our priorities, and this is what we’re building, and that’s it,” without paying attention to the background story of “How did we get here? And “What is the impact that UX research has already shown?”

It’s not the value of UX research that has changed. It’s our perception of value. It’s our job to hold that story and to tell it often.

Make insights discoverable

The third thing that comes to mind is building a body of work. Instead of building insights project-by-project and shipping them as they come, we build this body of work that we keep relevant by refreshing and constructing new insights based on what teams are asking or what new products those learnings might apply to. The key to building this body of work is making sure it’s discoverable. As researchers, we have a lot of empathy, talk to many users, and are convinced we should build for the user. But if our product teams can’t touch, feel, and hear from users, build empathy, and understand exactly how someone wants to engage with the product.

In that case, it will be difficult to build well for them, so we need to make that work understandable and accessible to everyone on our product team. We also need to keep it fresh so that it continues to be relevant and exciting to engage with.

Strategies for road-mapping and increasing research impact When we think about insight production, that process starts after the data analysis phase of a research project. It starts way before then, typically at the beginning of a quarter or a half where we are road mapping.

Again, researchers need to participate in that process and actively determine what we’re building based on our objectives. We don’t have just to be involved in conversations that ask for our research. And so, when we determined our product road map and what we’re building over a quarter or a half, what research road map corresponds with that? Then, after that’s done (before each project), we want to scope it out and align with our product teams on a few different points:

Metrics. Which are the metrics that we’re most interested in both tracking and changing? Where are we now? Where have we been already? (And like a lot of researchers know, a lot of times, we don’t have to start new research to answer the question. We can go back into our bodies of work that speak to those elements and pull them back up).

Goals. We have to align on our objectives. What are the business objectives that we’re trying to move?

Timing. When are we trying to get there?

Intended impact. What do we intend to do with the results of this research? I think the intended impact is probably one of the most important things to align with your product team before even designing a research project, asking your product team, your PM, and your PMMs: Based on our hypotheses, what will we do with it if we get positive/negative feedback? What is that going to look like?

That puts them in the posture of, okay, there has to be an intention behind these insights and what we will do. It prepares them to use those insights and transfer them into impact so that you avoid researching just to check a box. If someone can’t answer that question, we just go back to the drawing board, determine that together, and then move forward.

So, what knowledge gaps are we looking to fill? And then our hypotheses. What do we know already? And what’s our best guess at some of the questions we’re trying to answer?

In summary

If you take nothing else from today, there are three things I want you to take away:

1) Insights are not neutral. They’re not meant to be. They’re intended to inform teams of what we know and are learning and identify the best next steps to move closer to our goals.

2) Communicating value. As researchers and product partners, it’s more important than ever for us to communicate our value and how that value translates into value for the business. Our job is to drive products forward, including revenue generation and quality and accessibility, and connect the dots between the two.

3) Research is not a lane we’re confined to as researchers. It’s not the only thing we do, the only thing we can talk about, or the way to show our value. We’re strategic product partners who have research as our zone of genius. We’re strategy partners and use our storytelling to drive strategy on the team. It’s the means to an end. It’s not a destination. So, remember that as we’re working with our product partners and talking about the research and what comes next after those insights are shared.

Editor’s note: This article is a condensed overview of Eniola Abioye’s session and Q&A on the main stage at Insight Out 2024.