Making it easy to learn about users and their needs

How we created a user research library

Published in

RNID

4 min readMay 9, 2022

A screenshot of a search in our user research library. They’ve searched for ‘sign language’ and the first result is a user need that says, “As a deaf person who uses British Sign Language, I need to find support that is relevant to deaf people so that I get the right support or advice.” — Our user research library lets people find insights and user needs.

As our user research practice grows, more people across and outside of RNID ask about our findings. In this blog, I’ll share how we’ve made it easier for people to learn about users and their needs.

How it used to work

I’ve maintained a user research repository (basically, a really big spreadsheet) since I started at RNID. It’s where I store findings and includes things like, insights, observations and quotes.

User research findings are stored in our repository in Airtable.

Let’s say a content designer asked what we know about British Sign Language (BSL) translations. I’d search in the repository, find relevant information and share links to items in Airtable.

So, why weren’t other people looking in the repository?

I noticed that people were still coming to me instead of looking in the repository. I started to ask why, and found that:

some people couldn’t access Airtable
some people didn’t know how to use Airtable
some people couldn’t find what they were looking for
most people found the amount of information overwhelming

There were a few exceptions. Those who found the repository helpful explained why and how they used it, which showed how we might make it easier for others to use too.

“I search, ‘assistive technology’ or ‘hearing aids’ and I see if I can find something. Otherwise, I search by a type of user, for example, ‘deaf person’ or ‘hearing loss.’”

Building a simpler frontend

After learning about the problems with our current setup, I recommended creating a frontend, or a simple interface, for the repository. The frontend would:

be open and easy to access (without a login)
let people search for insights or user needs
let people share a link to a specific finding
let people find high-level information, not all the detail

Our freelance developer, Rich, started building a proof of concept. He suggested creating a static site, using a static site generator, which connects to the Airtable API and generates a website.

How we structured the library

While Rich worked out Airtable’s API, we needed to learn how we should structure the library.

I planned a two-part study to learn:

which words people use when they search for research
the relationship between different topics

This would help us understand how to structure the library so it makes sense for the people using it.

First, what do people search?

To learn how people search for research, I asked colleagues to read one interview transcript and one insight and, using sticky notes, write down which word(s) they would use to search for that snippet of data.

A screenshot of an exercise. On the left is an excerpt from a transcript. There’s small text, and yellow sticky notes in the margins. On the right there is a research insight, again with sticky notes in the margins. — People used sticky notes to tag a transcript and insight.

I found that people from the same discipline tend to use similar words to describe a topic, but this can differ across disciplines. I recommended updating tags to make them more descriptive or something that a user would say.

Next, how do people categorise different tags?

Using a sample of the tags we created, I ran a card sort where I asked colleagues to organise tags into categories.

A screenshot of a card sort in optimal workshop. There are 4 categories, called: users, components, topics and services. In users: BSL user, volunteers, use a service on behalf of someone else. In components: print, results pages, checkboxes. In topics: accessibility, stigma, hearing aid, online chat. In services: Book an interpreter, get support online, fix a problem with your hearing aids and contact RNID. — I used Optimal Workshop to run an open card sort.

The card sort showed that most people, across different disciplines, put tags into similar groups and use similar names to describe them. I used these findings to recommend which fields we use to describe each user need and insight in the library.

These exercises also helped us recommend a structure for the library overall. Alex, our Design Lead, mocked up how the library might work based on this.

He proposed we have a single main page where people can search for both insights and needs through a basic text search, as opposed to having separate pages and searches for each.

We shared recommendations with Rich who pulled it all together in a working prototype.

A screenshot of an insight in our user research library. It says: “When people’s hearing aids stop working they often can’t identify the problem.” There’s a description and a quote and then it’s tagged with different categories: date, type, user, topics and service. — An insight in our user research library.

What’s next

We’re launching a prototype of the library soon, which we’ll share to gather live feedback.

If we find that we’re solving the right problem then we’ll continue to increase awareness of the library and improve over time.