Filter school list for user research extracts
We’ve designed an concept interface exploring how might we enable user researchers to self serve sample extracts.
The problem
During user research, we regularly reach out to developers to provide samples for user research.
Because the research is focused on different areas, we usually need schools who satisfy particular criteria or have specific attributes.
The current situation is that the User researcher will provide a developer with the relevant sample criteria, who in turn, will create the extract of suitable schools manually and output an Excel spreadsheet.
Furthermore, this approach means we do not capture what the data is used for and by whom which could result in over-contacting the same schools.
By empowering user researchers to create the criteria for sample extracts, we can foster autonomy and agency for our user researchers.
This allows UR to have more control over their time and significantly reduces the time developers have to spend on manual extraction resulting in a more efficient and streamlined user research process.
The design concept
We initiated discussions with our user researcher to understand what filters would help generate a worthwhile extract for them.
Through collaboration, we crafted a prototype of a filter panel and how it might work. This served as a tool to stimulate continued discussion and gather valuable insights from our team members.
We had a session with our lead developer to determine what complexity these filters would generate in the build and what type of spreadsheet we could output from them.
We agreed that the product idea would be helpful from here, provided the filters were not too granular.
How might the tool work for all our URs?
We wanted to take advice on how the tool could work for our wider UR practice, so we invited two UR leads who raised questions about ethics, namely, whether we could capture and retrieve users’ data already used in UR.
This is an important datapoint to track if we can because there should be an appropriate window passed before we approach them again for further UR work. This way, we are not repeatedly using the same schools for our research.
One of the URs stated they already use a spreadsheet where they capture that ‘already contacted’ data point and wondered if that could be an additional bit of functionality for our proposed solution.
The tech lead on the call said it would have data model implications and add complexity to the solution and might be something to add down the line if the tool became established.
The user research lead decided that we can go ahead and develop the tool for our (ECF team) purposes with a view to enhancing it should it meet expected outcomes, specifically, reducing manual process, saving user researcher and developer time.
Next steps
As work to improve the regsitration journey approaches, this piece of work has been de-prioritised for now but should be picked up later on and build on the work already done.
We learned there is a balance between the narrowing down with filters and the complexity required to build a filtering UI to support it.
Striking that balance will be critical to this tool’s usefulness, viability and feasibility.
A prototype is ready to test when the work is picked back up.
Further collaboration should ensure the filters help generate an Excel spreadsheet that allows user researchers to create a satisfactory sample.
We should also investigate what enhancements would enable us to roll it out to researchers across the progamme