When discovery became a team sport

Opening

As designers, our role is to deeply understand our users' struggles. We identify needs and pain points, but that insight often stops with us, because Discovery is treated as a design task rather than a team activity. I wanted to change that, so I designed and led the concept of Hotjar Watchparties, turning Discovery into a ritual where developers and designers watch real user behaviour together, and build shared ownership over the solutions that follow.

Goal

To make Discovery collaborative, so the team could improve collaboration with developers, build genuine buy-in and ownership on their side, and create better solutions through more horizontal collaboration.

How I noticed this was a real problem

A few months into working with the team, I noticed something worth paying attention to. Our developers were genuinely engaged whenever we shared user insights with them, but Discovery still felt like something designers did in isolation. They wanted to understand the people using what they built, but user data was something the customer experience team reported from a distance, informative but not something they could act on or shape solutions with.

I started asking around, first other designers, then our PO and BA. Everyone liked the idea of more co-creation, though there were some concerns about time investment. We were also losing momentum during refinement, not from a lack of understanding between designers and developers, but because collaboration was happening too late, forcing divergence when we should have been converging.

Testing the idea before committing to it

Rather than proposing a big initiative outright, I tested smaller signals first. Whenever I presented work, I'd include a relevant bit of user data, device usage if we were discussing a mobile-only feature, scroll depth if we were evaluating a "back to top" solution. Developers and QA engineers started reaching back with follow-up questions, sometimes just to say thanks for sharing it.

So I tested desirability directly: I began sharing short Hotjar recording snippets individually, then made them a recurring part of my Figma files. The response was consistently strong, which told me there was real appetite to scale this to the full team.

The idea: Watchparty as a movie night

To scale this to the full team, I conceptualised it as a "movie night," reasoning that an informal setting would make UX research more approachable than a formal methodology session. I framed each topic as a movie synopsis rather than a clinical description of navigation issues, which made the sessions feel like something to look forward to rather than another meeting.

What the sessions looked like

I built a Hotjar finding template so observations from the sessions could become a structured starting point for new solutions rather than a one-off conversation. If the team could capture what they noticed in an unbiased, thought-provoking format, those findings could directly challenge weak points in the experience.

Navigating the constraints

The dev team was remote, based in Poland, with no prior experience with Hotjar or qualitative research, and we had seen a lot of changes across PO, BA, and developer roles. To work around this, I kept the format deliberately informal, worked with the dev lead to get the team together in person in Krakow on office days, encouraged people to bring snacks, and framed each session with enough context around Discovery that it doubled as a light introduction for anyone new to the process.

Results

The team's own numbers tell the story better than I can. Self-reported confidence in understanding user needs and pain points went from an average of 2.75 before the Watchparties to 4.50 after. Every single respondent said they'd recommend making Watchparties a permanent part of the team's process.

When asked how the Watchparties changed collaboration, the team described becoming more proactive, asking sharper questions, and building a shared understanding of user needs across roles that previously sat with design alone. One backend developer who already had access to load-time data in a monitoring tool said that watching users actually wait for results to load gave him a different perspective entirely, something the raw numbers alone hadn't.

What I learned

Four things stayed with me. Design language itself can be exclusionary, and rethinking how accessible our process is, not just our interfaces, can be one of the highest-leverage things a designer does. Being part of the design process is a strong motivator on its own, the team's engagement peaked not because of incentives but because they felt ownership. Context changes perception, even familiar data lands differently in motion than in a dashboard. And designers can shape the environment they work in beyond the screen, the dev team now has standing access to Hotjar and a seat in ongoing UX insight sessions, none of which required technical design skill to make happen.