When discovery became a team sport

The cost of excluding Dev Teams from Discovery

As designers, our role is to deeply understand our users' struggles, but that insight often stops with us when Discovery is treated as a design task rather than a team activity. Keeping developers out of the design process early on means missing out on valuable collaboration and shared ownership from the start, and the impact shows up later as misalignment between the two parties, dragging refinement sessions, and solutions that end up requiring a rebuild.

Were we at risk of following that path?

A few months into working with the team, I noticed our developers were genuinely engaged whenever we shared user insights with them, but Discovery still felt like something designers did in isolation. Developers wanted to understand the people using the product they built — but user data was something our CX team reported from a distance. Their belated involvement in the process sometimes felt like a missed opportunity and the reported data did not feel like something they could act on. Their interest was there however, and it was our responsibility to make the design process more accessible to them.

What if we made Discovery collaborative

I started having conversations with other designers, then our PO and business analyst, to see whether they also felt there was an opportunity to improve our workflow. We identified we were losing momentum during refinement, not from a lack of understanding between designers and developers, but because collaboration was happening too late, forcing us to diverge when we should have been converging. As a team, we agreed there was a need to introduce earlier, more horizontal co-creation.

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 to show how they were currently utilising our product. These were sometimes a heatmap, a sequence of screens, or a short snippet from Hotjar session recordings, which was very well received by our dev team.

Soon after, developers and QA engineers started reaching out wanting to hear more about our users' behaviors and asking for more session recording videos. They found it super interesting to see users find their own ways to explore the product, which sometimes looked very different than what we had initially planned. I made Hotjar recording snippets part of my Figma files and design handoff process, and they sparked curiosity within our devs, which told me there was real appetite to scale this to the full team.

Framing Discovery as a watchparty

I started drafting the concept of User Behavior Watchparties, where developers and designers could share focused time to watch session recordings together. By having these watchparties every other month, we could turn Discovery into a team ritual where we could build shared ownership over the problem to solve from the start, so that this would then trickle over to the solutions that followed. And by framing it as a movie night, UX research would feel more approachable than in the context of a formal methodology presentation. I framed each topic as a movie synopsis rather than a technical description of navigation issues, and presented the concept to our design manager and PO, who saw real potential.

What the sessions looked like

Every watchparty had 3 parts: presenting the problem we'd focus on (e.g. reordering challenges), watching a set of curated recordings relevant to the problem, and team reflections and discussion.

The audience was the entire Dev Team and QA engineers, our PO and Business analyst, and our other designers. Sessions were 60 to 90 minutes long, depending on the amount of recordings to review. The first couple of sessions also helped us introduce our dev team to the way we did Discovery in detail — something we had taken for granted. During the recording viewing, they would have the chance to write down all their observations, questions and ideas in a shared board, so we all could build off each other's comments. We would have a couple of minutes to share some general observations and move on to the next recording. I also built a template so our team's findings could become a structured starting point for new solutions instead of a lost one-off comment after the session wrapped up.

People came prepared for a show

Keeping a team that was fully remote engaged felt like one of the main challenges to tackle. They were based in Poland, with no prior experience with Hotjar or taking part in qualitative research, and we had seen a lot of changes across PO, BA, and developer roles recently. To work around this, I kept the format deliberately informal to make it as accessible as possible, and I coordinated with our Dev Lead to get the team together on site, in Krakow, on office days to get as much attendance as possible. We also encouraged people to bring popcorn — which they did — and added a few movie references and easter eggs to the material to keep people engaged.

The format was very successful, with great attendance and high engagement from even some of our more introverted team members.

The watchparties became a big success

Our surveys after the sessions reported that confidence in understanding user needs and pain points went from an average of 2.75 before the Watchparties to 4.50 after among our dev team. Every single respondent said they'd recommend making watchparties a permanent part of the team's process, and other teams at Heineken started preparations to incorporate them into their team's dynamic too.

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 search results to load gave him a different perspective entirely, something the raw numbers alone hadn't.

What I learned

1. Design language itself can be exclusionary. Rethinking how accessible our process is can be one of the best ways for a designer to create value within their team.
2. Being part of the design process is a strong motivator. The team's engagement peaked once they had a say beyond the technical aspect only, increasing their sense of ownership over our solutions.
3. Context changes perception. Even though our developers already had access to user data through their dashboards, seeing users' behavior in motion made a deeper impression.
4. Designers can shape the environment they work in beyond the screen. Our dev team now has standing access to Hotjar and a seat in ongoing UX insight sessions, none of which required any technical design skill to make happen.