Your stakeholders are hungry for user insights — are you serving up raw ingredients or tasty treats?
Have you seen “The Bear” yet? I’m slowly making my way through season 2. It’s reminding me of how much I love cooking, as demonstrated by the photos above.
But the show isn’t just about the food; it’s about transforming a restaurant into a environment devoted to making an excellent dining experience for their customers.
Now, when I hang up my apron and do my actual job, I work as a UX Research professional.
I’ve spent the last few years of my career rethinking how I deliver insights to my stakeholders, and to be honest, I see a lot of parallels to the dining experience:
- Stakeholders are my guests, hungry for user insights
- User data are raw ingredients
- The researcher is a chef, responsible for combining, transforming, and presenting the ingredients in a way that satisfies their hunger
If I’m really good at it, what I bring to their table isn’t just satisfying their hunger, though; it’s downright delicious, and they can’t wait for more.
We’ve all been through a research presentation that felt like being served a bagful of flour.
The slides are dense with graphs and charts, little arrows up and down, little boxes calling out findings that the researcher clearly considers important.
Halfway through the readout, they started getting peppered with questions. Why was this number so much higher? How should I think about this chart? Are we able to dig in more over here?
It isn’t that the ingredients of the dish (i.e. data) are bad; the team is interested in what the researcher is trying to cook up. The meal just isn’t cooked or plated very well.
This might be because the researcher sits in another part of the organization, and doesn’t understand who’s consuming the meal.
Maybe they don’t have a strong enough sense of what the diners do and do not control, or what questions linger on the tips of their tongues.
And maybe they’ve just never considered changing up their technique.
So, like the staff of The Beef (the sandwich shop in “The Bear”), researchers keep slapping together meals the way they always have and praying the diners won’t notice anything’s off.
In the first few years of my career, I was definitely guilty of shoving raw data into people’s faces and expecting them to make a meal out of it themselves.
Over time, I watched them ignore the raw data I was serving up and go do whatever their gut told them to do in the first place, so I started to modify my technique.
I made glorious meals out of each project, and delivered reports that were more like an all-you-can-eat buffet: slide after slide after slide of content that may or may not pique my audience’s interests.
The trouble with that approach was that my stakeholders could pick and choose which bits are most delectable. Did you ever take a kid to a buffet and all he ate was the rolls? Kind of disappointing. It was a bit like that.
Sometimes, I’d make a UX Research report that was more like a platter with enough food for a whole family, which isn’t necessarily a bad thing; a big, meaty generative study is always going to require a big ol’ heaping plate of data in the form of larger slide decks.
However, everyone leaves that kind of meal super stuffed, to the point where they can barely move or take any kind of meaningful action based on what they’ve been served.
So in the last few years, my research deliverables have slimmed down — more of a light meal that’s nutritious and filling, but doesn’t leave you in a food/data coma.
Instead of 20 or 30 slides, I shoot for fewer than 10. For the really light studies, I only need 1–5.
And lately, in an effort to make research findings even more snackable, I’ve been sharing what I call research nuggets: 2–3 sentence stories that describe an “ah-hah” moment we got from a study.
I usually accompany the story with an artifact from testing: a video clip, a graph, a quote, or other point of data we’ve collected.
I still build small decks to explain the project fully, in case anyone’s interested, but they’re usually fewer than 10 slides.
For example, here’s one I shared in our product-wide channel of about 80 folks (with some bits covered for privacy):
There’s a lot I love about lighter-weight reporting, especially the research nuggets.
First, they don’t block up calendars. Whether you send them out in email, chat, or some other method, a research nugget is much easier to fit into everyone’s workday than an hour-long readout call.
It only takes a few minutes for the researcher to whip up the story and provide the artifact, and any interested party can snack on the nugget when they have the time.
Nuggets also remind people of how user research is able to support their projects.
Product managers, designers, and other stakeholders may have passing knowledge of the UX Research function, and they probably know some methods…but do they remember to call on you in the moment they need user insight?
Probably not always.
This way you’re keeping research a bit more top of mind, and gently educating them on how you can support them in different ways.
The research nugget also affords you the opportunity to celebrate collaboration and boost team morale and connectedness.
I’m almost never doing a project just because I thought it was a good idea; a designer, strategist, or product manager is probably involved. Maybe even leadership.
When I include those collaborators in my nugget, it’s like throwing my arm around their shoulder and letting them bask up a little positive attention, too. (I only recently realized how re-affirming that could feel — one of my coworkers recently told me, “that level of validation was much needed and really gave me what I needed to know that my efforts are worthy.” How’s THAT for boosting your coworkers?)
Finally, the humble research nugget demonstrates the volume of work your UXR team is producing.
This may not matter to everyone, but I spent the last 8 months as the sole researcher supporting about 20 product managers and 20 UX designers.
I was always juggling multiple projects at once, but usually only 2–3 people were involved in each one, so it would’ve been super easy for someone to start to wonder what I was actually spending my time working on.
The research nugget has been an invaluable way to communicate how I’m contributing to the team, and different nuggets have been acknowledged multiple times by leadership as a demonstration of how helpful and effective I am in my role.
(The research nugget is one of the best ways to exhibit some shameless self-promotion for the user research discipline into my workplace.)
To be clear: the research nugget isn’t really a new idea or approach.
I’m not the first researcher to try to make insights more snackable. I’ve worked with researchers who conducted “quick hit” tests that could be communicated in just a handful of slides.
Repository tools like EnjoyHQ and Dovetail have built “stories” as a potential deliverable you can create in their platforms and a way you can access findings.
When I first came across those kinds of techniques, they felt odd to me. How can you leave out so much context? There’s so much more to tell you about the project and all the awesome shit I learned!
But over time, I’ve learned the importance of making insights more consumable.
Sometimes, my stakeholders will ask for a giant feast of a project, and when that’s the case, I do my best to make every course count for something and be talked about later.
But more often, I find the nugget (the amuse bouche, the appetizer, the nibble, the tasty treat) is great for whetting my stakeholders’ appetites and getting them to invite me to the table more often.
Looking forward to seeing what you readers cook up!
