The challenge

As Digital Science was going through a large reorganisation and consolidation phase, a centralised design team was established — designers would still focus on products or segments, but be part of a larger functional team (in a matrix organisation). This created opportunities to benefit from scale, but also to elevate our practice by establishing sensible standards and practices.

The designers who came together to form the new central design team had experience with user research and were engaged. The newly formed product team included very research and user-engaged product managers. The opportunity was great: as we were breaking silos between products, we could increase the impact of user research by establishing a base level of structure for research.

Despite our privileged position (i.e. we were already conducting extensive research, and stakeholders generally valued user insights), the reality was that research knowledge was scattered, and perhaps not as impactful as it could be. If I had a new research question, I’d reach out to the team and ask if they know of any relevant research. This is fallible: people might be on holiday, may not remember what they’ve done months/years ago, may leave the organisation, etc. It was clear that we needed something more structured and less dependent on individuals being on top of everything.

Goals

With this context in mind, we formalised the following three goals:

• Efficiency: We codify our decisions and remove guesswork. This leads to less time spent planning research and more time doing actual research.
• Quality: We define best practices, provide guidance and embody the practice in the repo. This helps us ensure a base level of quality.
• Impact: Consistently organised research is discoverable and easy to disseminate. People can browse a repository if the structure is predictable, and we can go and inform product planning and roadmapping beyond the scope of individual products.

A corollary that I’ve repeated often in meetings is that it’s great when we have the opportunity to conduct research, but it’s even better when we can reuse research that others have already done.

My role

I led this project, engaging with other designers (particularly with a close group of engaged, research-focused team members) and stakeholders. My responsibilities included project management, running workshops, the actual hands-on work, disseminating and socialising the outcomes.

Discovery

To form a better picture of the current state of affairs, I needed to understand how research was being conducted by different designers and product managers, how the insights were disseminated and, ultimately, how impactful the research practice was. I have conducted interviews with people doing research as well as with stakeholders who might benefit from research (e.g. product leadership who’d benefit from user research insights when planning) and clustered their main pain points.

Equipped with this context and knowledge, I then conducted a series of collaborative workshops with a small group of designers, heavily involved in (and passionate about) user research. We came up with good examples/references, as well as our own struggles, along with our initial thoughts about potential solutions (ranging from high-level organisational structures to in-depth taxonomies for analysing research data).

The solution: a two-part approach

It became evident that our problem needed at least two distinct (yet connected) sub-solutions: something standardised where we could store and organise research; and guidance for conducting research consistently.

The research repository

The research repository was essentially Dovetail + configuration + templates. We were already using it for specific products/segments, and it ticked all the boxes, so this was the logical choice.

Beyond ensuring organisation-wide access, we’ve created the following artefacts to ensure consistency and scale up good research decisions:

• A project template, which ensured consistency and a minimum set of project-level metadata (really a minimum: we didn’t want to be overly prescriptive, and certainly didn’t want to overwhelm people).
• An insight template, which is similar, but for insights. An insight is an interpretation of data. It reveals underlying patterns, motivations, or needs that aren’t immediately obvious. Unlike raw data or stating facts, insights provide a deeper understanding of why something is happening and what it means in a broader context.
• A base analysis taxonomy, which included global tags (the basic unit of analysis in Dovetail) and global fields (the metadata associated with each unit of research data). These, together, would ensure consistency and enable cross-product discoverability of insights.

The research playbook

We have also created a playbook which provides guidance on how to use the research repository (including its components) as well as on how to conduct research. It’s a deliberately concise document, including quick start guides (both for researchers and “consumers”) to help us do research in a consistent, systematic and impactful way.

Dissemination

Getting people to actually use the new system required more than just documentation. I took every team meeting as an opportunity to communicate impact, and seek feedback, as a way to engage other designers and convey that — rather than a top-down mandate — this was a collaborative effort. When we reached a first draft, I organised internal brownbag sessions where team members could see the repository in action and ask questions in a familiar environment.

The most successful session was one co-hosted with our Dovetail account manager, demonstrating newer AI capabilities such as automated highlight suggestions and AI-generated summaries. The team responded well to seeing how these tools could help reduce manual work in tagging and initial synthesis, while maintaining human oversight.

Impact

It’s hard to assess impact in the absence of a baseline. Before the reorganisation, research was not only scattered and documented in different places, but it was also being conducted by siloed teams. We have, however, some quite encouraging usage metrics. With a team of 19 designers, in the first 6 months after the first version of the repository was shared, we have:

• Created 93 research projects.
• Added 3,209 research records (individual data points from a specific research project, e.g. interview transcripts, survey responses, usability test recordings, etc).
• Tagged 7753 highlights (a portion of a research record flagged for analysis).
• Created 131 insights.

This is seen as a success, and we’re happy with it. We will iterate on it, but adoption indicates that we’ve built something sensible and helpful. This validation allows us to focus on the next steps to amplify the impact of our research practice.

First, we’re continuing to explore how AI can make us more efficient. The positive reception during our Dovetail training sessions suggests the team is ready to experiment further—particularly around identifying patterns across projects and accelerating analysis.

Second, we’re working on socialising research more broadly, across the company. A repository that works for researchers is great, but the real impact comes when user insights actually influence decision-making beyond the design team. We’re planning to share research snippets in all-hands meetings, include highlights in company-wide communications, and exploring a Slackbot that automatically shares relevant insights to appropriate channels. The goal is to foster greater empathy towards our end-users and ensure that we accurately represent them in product and business decisions.