Join over 150k subscribers to get the latest articles, podcast episodes, and data-packed reports—in your inbox, every week.
SUBSCRIBE TO OUR NEWSLETTER
We're on a mission to figure out the best, most modern, usable way to build a team-wide research habit.
For our purposes, we’re interested in building a research practice that:
So with that in mind, Joe and I covered a lot of these topics a little bit, but we focused on the aspects of building long-term knowledge through what he calls timeless research. I was thrilled to dive into this topic with someone who has actually been working to make it happen for years. In my year or so of being fully enmeshed in the world of user research, the piece on making the most use out of the research you actually do feels like one of the most important, and least solved. What follows are some of the main insights from our conversation, insights we plan to let inform our evolving approach to user research at User Interviews.
If the goal is to make research actually useful, to turn the unknown or assumed into the known and understood, part of what we’re talking about is the nature of learning itself. Joe uses the example of a child who touches a hot stove. If they touch the stove again, the learning hasn’t been applied, it hasn’t actually been learned. On the other hand, if they associate touching the stove with getting hurt, and don’t do it again, they have learned the key lesson. They applied it.
User research works the same way. Insights sitting in a Google doc somewhere will never be applied. So, how do you apply the research you do?
User research is all about people at every turn. From building an overall understanding of human motivations, behavioral economics, and the like over time, to asking questions that elicit true answers, to sharing insights in a way that makes an impact on those you seek to influence (i.e. your internal stakeholders), this whole discipline is all about people.
When it comes to building timeless research, Munko shares “We’re so inclined to speed, we don’t have people whose goal it actually is to learn.” People work in systems, and many of our systems, especially in an agile environment, prioritize speed above all else. But if you say, actually our goal in research is to learn about our users, and to learn more over time, so we can build products that serve them well, that our competitors could never dream of building because they haven’t invested that time to actually learn—then speed to cobble together a method that meets the constraints of the product that needs to ship next week doesn’t feel like the right goal anymore.
So the first transformation that needs to happen is that people need permission and motivation to design research that will last beyond the next product release, and then to start with “what do we already know,” instead of starting from scratch each time. “The fastest method is to use what you already have. That will beat an a/b test anytime,” Joe says.
Of course, you won’t have anything to reuse if you don’t build your research to last in the first place. So, how do you build research to last? Part of the cause of disposable research is this construct of new product = new research. A better way is:
How do you get to a place where you can build that canon of research over time?
It’s very hard to share what’s in your head, at scale, over time. Get notes, research artifacts, and especially findings and insights out of your head and into a document.
The minimum step is to put it somewhere. The more important step is to put it somewhere accessible. For this, you’ll need some tools. At Microsoft, Munko uses a combination of Powerpoint, Sharepoint, Word and the like, and of course they all work perfectly 😉, but they aren’t purpose-built for atomized research.
If I’m a researcher, or a person in a company who is trying to solve a customer problem by understanding customers, and I need to understand what tools people use when they’re using our product’s calendar and how they feel about it, I’m not looking for the “calendar study” that doesn’t exist. I’m looking for a summary of feedback we’ve gotten on these topics through active (say user interviews or qualitative usability testing) and passive (say support tickets and NPS survey data) feedback and insights.
I don’t need a report, I need insights spread across a variety of inputs, brought together. “How do I ladder what I learned into how to apply it?” as Munko says. Many organizations, including Munko’s team at Microsoft, are working at creating tools to better support this opportunity. Theirs is called HITS, or Human Insight Tools & Services.
“HITS is a platform that helps teams easily discover, curate, and democratize human insights, breaking them free from organizational and memory silos. HITS modernizes the way we work by atomizing insights so researchers can reuse and remix them, making connections that contribute to a dynamic and living body of knowledge."
For our efforts, we’re experimenting with Productboard. It’s a step up from Airtable, which we were using, because it’s easier to both submit and find information you’re looking for. More on this later as we get to using it and refining the process. A few things we’re thinking about though are: automating where possible and creating the most useful metadata, plus the easiest ways to input that metadata. Munko says of creating a data model in the beginning of their system “You’d be surprised how much time and energy we’ve spent on it,” and that “words matter” and “which words you choose is super important.”
The metadata we are currently capturing include:
We’re starting to think about what should be tags versus features, and how to store general insights about user context and motivation that don’t map clearly to current or planned features. This feels important for creating timeless, reusable research, but hey, you can’t figure everything out at once, yes?
Only through using the research canon you’re building can you test its efficacy in doing its job: helping you find insight and apply it efficiently. As you use it, seek to improve the system based on what works and what does not. “The more mature your product gets, the more you’ll be asking the same questions,” Munko notes. Setting up a system early should provide compounding benefit over time, saving you time by not reinventing the wheel, and building the right products the first time. That’s what we’re banking on, and we’ll be back soon to report on our progress and learnings.
Want to contribute to User Interviews content? Here’s how.
VP, Growth & Marketing
Left brained, right brained. Customer and user advocate. Writer and editor. Lifelong learner. Strong opinions, weakly held.