Building an inclusive research practice at Xero

Design research is a crucial part of the decision-making process that allows us to integrate the real stories, experiences, and needs of our customers into product decisions. A research practice that doesn't include disabled people produces incomplete data and a false kind of confidence, as teams believe they understand the full range of their users. This confidence shapes product decisions, which shapes what gets built.

Xero had mature evaluative and generative research practices with a team of 30+ researchers running regular usability studies, discovery interviews, and using research findings to inform product decisions. The infrastructure was solid, but there weren't any processes in place for ensuring that people with disabilities were included as research participants.

Accessibility-specific testing did exist through a platform called Fable, which connects teams with professional assistive technology users. But Fable was only used at the end of the development process, validating what had already been designed and built, rather than shaping the original decisions.

This meant we had an upstream problem: we were thinking about accessibility at the end of the process, when it's already too late. The decisions that determine whether a product is inclusive are made much earlier: in research, when you choose whose experiences count as evidence.

We needed to understand how to move inclusion upstream, so it could start shaping decisions rather than being at the end, and it turned out we had to involve almost every part of the organisation to do that.

Process‍

We defined our goal as enabling accessibility customer research across Xero's standard research practice, embedded into how research already happens.

From an operational perspective, we required a robust system with guardrails to safely store our customers' data and, in the future, enable us to build an internal panel.

• To include customers with disabilities in standard research practices, we needed to be able to recruit them, which meant being able to ask about disability and assistive technology use during screening.

From an accessibility perspective, we needed to make sure our Researchers understood the nuances involved with facilitating research with people with disabilities.

• Conducting research with assistive technology users requires understanding how those technologies work, what the nuances of different disabilities are, and how to create a session environment that doesn't inadvertently create barriers of its own. None of that knowledge existed systematically in our research practice yet.

We came up with a process made up of 3 main phases:

Foundations - compliance and data governance‍

Including disability-related screening questions meant handling and storing sensitive health data, which triggered a formal data impact assessment spanning seven teams. I coordinated this process across legal, privacy, research operations, and engineering, working through data retention policies, accessible NDA formats, and standardised language that was both legally sound and respectful to participants. We also participated in an unintended consequences workshop run by the data team to surface risks we hadn't anticipated.

This phase took significantly longer than we originally planned, and was the clearest signal of how structurally embedded the problem was.

Capability building‍

Conducting research with assistive technology users requires researchers to understand how those technologies work, what the nuances of different disabilities are, and how to avoid creating barriers within the research session itself.

I negotiated budget across three teams (Design, Accessibility, and Research) and managed a formal tender process with external vendors to develop training and guidelines. We then ran a three-session training, together with Intopia, to upskill our Researchers. We also decided to run a research study on accessibility in the product space, both to build internal knowledge and to test our new process end-to-end.

Process and rollout‍

We designed the rollout in phases: a narrow pilot with selected researchers, with structured feedback loops before expanding to the full team.

Testing the process‍

We wanted to find out if we could integrate accessibility screening questions and data guidelines directly into our standard research practices. Rather than running a standalone study, we embedded our new process into an existing research project that was about to begin, sharing our updated screening questions, session scripts, and data guidelines with the researcher, and joining each session involving participants who had self-identified as having a disability.

The study produced two misrecruits: participants who had passed screening but whose actual needs weren't what we'd anticipated. The screening questions weren't specific enough, and we didn't yet have a reliable way to verify participant information before recruitment was finalised.

This was a valuable finding. We met with Intopia, one of our accessibility partners, and refined the criteria further, adding more descriptive questions while still protecting the customers' privacy. The data storage and script worked as intended. We made a few tweaks, but we now had all our guidelines ready they were ready to be published.