---

---

Introduction

For much of my career, I have held firmly to the idea that good research and design practice should be tool-agnostic. Our craft is defined more by the methods we understand and can apply than by the tools we wield. In hiring interviews, I often ask candidates which methods they feel confident using and just as often, the response is a list of tools.

But if those tools disappeared tomorrow, could the candidate (or the designer, or the researcher), still perform their role?

Tools, in this view, are scaffolding: useful, sometimes transformative, but ultimately interchangeable. The real expertise sits in judgement, interpretation, method, and craft.

Can both things be true?

While I still believe that craft, method, and everything that happens outside a tool underpin a long and fruitful career, I have gained a deeper appreciation for what tools mean to teams and individuals, and the impact they can have when they change.

Earlier this year, we introduced a new research platform in our team. Unlike our earlier experience introducing a tool where none had existed (we did predominantly lab-based testing), this was a tool-for-tool swap but not a like-for-like change.

Like many tool rollouts, our initial focus was practical and technical. We organised training sessions to familiarise the team with the interface, walked through features, and learned how to operate the platform with a simple goal: help people feel confident using the tool. If the team understood the software, the transition should follow naturally.

But as rollout progressed, the questions which initially sounded simple: “How do we do X in the new tool?”, had more complex answers.

The real questions were:

• What new possibilities had emerged, and how should research evolve in response?
• What features had the team lost that had previously supported their practice?

What was really happening was a renegotiation of research practice itself. Tool migration is rarely just technical. It is behavioural, cultural, and, in many ways, epistemic change — a shift not only in how work is done, but in how knowledge is created. This is especially true in a world where introducing new tools often also means introducing new AI-powered research capability.

Why tools change teams

What makes tool changes so disruptive is that tools are never neutral. They carry embedded assumptions about workflow, collaboration, and even what counts as evidence or insight. Different platforms privilege different ways of organising work. Some make certain activities frictionless while making others harder or less visible.

Competing tools differentiate themselves through new features, automation, or AI-driven capabilities.

When teams adopt a new tool, these innovations reshape how work is done, influence which activities are prioritised, and ultimately shift what is considered valuable within the research process. In doing so, teams are also encountering a new set of expectations about how work should happen.

These shifts tend to surface in three interconnected ways: through the workflows tools assume, the expertise they redistribute, and the epistemologies they reinforce.

Tools assume workflows

Tools rarely present themselves as methodological prescriptions, yet they often encode strong assumptions about how research should be conducted.

Consider study setup. One platform may guide researchers through a tightly sequenced flow — define objectives, select a method, recruit participants, run sessions, then analyse — with each stage unlocking only after the previous one is completed. This structure makes certain tasks efficient and repeatable, particularly for standardised studies.

However, for teams accustomed to more iterative or parallel ways of working, say by refining questions mid-study, or synthesising early signals while fieldwork is still ongoing, this workflow can feel constraining.

To continue working as before, teams must either adjust their methods to fit the tool’s logic or invent workarounds outside the platform.

In this way, adopting a new tool is not just a technical change, but an implicit negotiation about how research is meant to happen.

Tools redistribute expertise

Tool changes can quietly reshuffle where expertise sits within a team.

Consider a researcher known for speed, someone who can set up, run, and deliver insights from unmoderated studies rapidly. In the previous platform, this capability had been refined over time: a combination of deep familiarity with the tool, well-worn templates, and tacit knowledge about how to move efficiently from setup to insight.

With the introduction of a new platform, that expertise becomes temporarily misaligned with the environment. The researcher must experiment, reconfigure studies, and rebuild workflows to reach the same level of fluency.

In the interim, the capability they were known for can become less visible, even though their underlying skill has not changed.

In this way, tool change does not just introduce new capabilities; it reshapes how expertise is expressed, recognised, and valued within a team.

Tools shape epistemology

Tools do not just support research practice; they influence how knowledge is constructed and what comes to be treated as credible insight.

Consider something as familiar as insight tagging. One platform may support tagging in ways that reinforce traditional thematic analysis, encouraging researchers to build structured, traceable interpretations across datasets. Another may emphasise tagging as a mechanism for quickly generating highlight reels or shareable artefacts.

Both support tagging. Yet they subtly privilege different research outcomes, rhythms of synthesis, and, ultimately, different ways of constructing knowledge.

In this way, tool choice does not just shape how research is conducted, but how knowledge itself is produced and validated.

So, what are my reflections…

I still believe we are more than our tools. If our tools disappear, we should still be able to do the job. Where my thinking has evolved, is that we should recognise tool change as potential practice change.

If I had to distill the experience into five lessons, they would be:

1. Tool rollout is organisational change, not software deployment
2. Teams need permission to redesign workflows
3. Tacit knowledge should be surfaced
4. Expertise shifts must be recognised and supported
5. AI tooling and AI methods accelerate these dynamics

None of these lessons are especially new in isolation. But tool change has a way of making the foundations of good work suddenly visible.

In conclusion

Most rollouts treat tool change as a technical problem: procurement, configuration, training. Success is measured through adoption metrics or feature usage.

But if tool migration reshapes workflows, redistributes expertise, and changes how knowledge is produced, then the way organisations typically manage tool change starts to look misaligned.

Even when a team knows how to use a tool, understanding how work itself changes, and learning to collaborate and make decisions in a new context, is an entirely different challenge.

When this is overlooked, adaptation is mistaken for resistance, and temporary loss of fluency is mistaken for loss of competence. The result: workarounds emerge, adoption becomes uneven, and the gap widens between how the tool is designed to be used and how work actually happens.

In addition, these dynamics are amplified when tools get updates that are AI-powered, or methods which are entirely AI… though that is a topic for another blog.

While tool migration will always come with challenges, taking a socio-technical approach can ease the friction and uncertainty teams experience, helping work and expertise adapt intentionally rather than accidentally.