The building blocks of libraries and repositories in user research

Published in

Springer Nature UX Research

14 min readSep 1, 2021

This blog post is based on a talk I did at ConveyUX 2021 https://conveyux.com/ in April and updates the thinking I’ve been doing since I share this post: https://uxdesign.cc/working-towards-user-research-and-insight-libraries-1c618bcec565

I am grateful for the opportunity to get to talk about this subject, which I have been thinking about a lot lately as I prepare to start working on this myself. I am also grateful to the conference attendee who pointed out that building repositories and libraries are heavy on content structure and content strategy. I hadn’t thought about it through that lens, but it’s so true.

Definitions — the difference between repositories and libraries

Longevity is not just about insight it's about maintenance

I’m going to start with a couple of definitions. In the field of user research at the moment, repository and library are used interchangeably, we all do it, I do it myself. But I also think it’s worth distinguishing between the two.

Research repository:

Where you store your research artefacts.
This is information management.

Insight library:

Where you maintain knowledge of your users and their context.
This is knowledge management.

A library is a repository, but a repository is not always a library. Using the analogy of physical shared spaces (if you can remember them), the difference between visiting a repository and a library is that a library is intended for public use for research and leisure, and (usually) allows items to be checked out, with a library card, it’s a place to access knowledge.

A repository is a location for storage, often for safekeeping or preservation, stored information for use by the public or qualified people, for data and information but not knowledge, we’ll go into what that means for user research in more detail.

I think in an ideal world, organisations with a mature research practice would have both a research repository and an insight library. If it was my choice, I would keep them separate for simplicity and they are essentially two different things.

Libraries and repositories are important as they support the doing of higher quality, more sophisticated user research.

Research repository — giving people who do research quick and easy access to the things they need to do the research.
Insight libraries — store and manage knowledge, maximise the use of research, help decision-makers to be evidence-based, understanding user behaviours and context, support secondary research being the first step in primary research projects.

I recently realised (though it seems obvious) that one of the benefits of curated insight libraries is that you get to capture all those insights you’ve gathered that aren’t directly relevant to the current research question being focussed on. This ‘secondary’ insight is usually forgotten and lost, but it can be put to good use in an insight library. A curated and well-maintained insight library supports people doing secondary research. Secondary research is the prime use case for libraries. Secondary/desk research is the searching, finding and using already existing data and insight. During secondary research we take (generally) primary research edit, redact, reformulate and represent for new work, or for other new purposes with our teams, stakeholders, departments, clients etc. With primary research, we’re creating new datasets (doing research with participants).

Why is their usefulness hotly debated?

There are well-founded concerns about how much work it takes to keep libraries and repositories up to date and how quickly data becomes out of date.

A lot of consideration is needed to create a repo or a library, it’s unwise to jump straight into it. They present a huge opportunity for surfacing relevant insights from different projects, study design, business functions and disciplines. However, they are often poorly implemented, they are laborious and siloed.

We need to think about:

The infrastructure first
And the tooling second

Maintaining an insight library is one of the most sophisticated things you can do in your user research and research operations practices. What I’m suggesting here is to start with setting up a research repo, this will help you on your way to an insight library.

When discussing the sharing of research/findings/insights more effectively, it often quickly turns to tools as solutions to this. As I’ll talk about later, there are other cheaper, less risky ways to start this process, other than buying a tool or building one in house. There is also the risk of not having something to collate your research, which means extra work for the researchers and not getting the maximum value out of the research done.

A low effort, high impact way to make research more easily accessible is a simple list (catalogue) of research done, so work can be accessed with just enough context to know that you are accessing the right thing. Write a list you can group into high-level themes. There are varying amounts of detail you can include in your list — e.g. title, data, link, methodology, findings, outcomes.

I often get asked the question, have we done any research on x. The social network of colleagues is still an important way of finding out what the collective contextual knowledge of the organisation is about the users and the research. I don’t think this is going away any time soon. Having somewhere to point to or self-serve that collects together past research from, say, the last 3 years is another extremely useful thing, to start reducing waste and redundancy in the research done. It’s also helpful to those who are new to your organisation, for example, and they don’t know who to ask about a certain research project.

Research report repo

Just a list, not just a list

Things that you’ll need to create your list:

Consistent naming convention
Know where the reports are located

Things that will enhance your list:

Unique identifier for each project (like ISBN for UR)
Using repo functions of existing tools
Make it someone’s job to maintain the list

One version of a research repository is a report repository — a consistent place to go for research outputs. This could be a separate thing or combined with the next version, so let’s move on to that.

Another version is a repo for research artefacts that are needed for the planning and doing of research. If you want to go deeper and expand the scope of a research repository, I see this as part of the next step… It’s already getting more complicated.

Making research easier to do by having:

Shared language: ideally free of jargon, across all the teams potentially using the research
Report templates consistent ways to report different types of research, so each report will meet basic expectations of what info it will contain.
A known place for storage: have a known consistent place to store research data (an ongoing problem, particularly in large organisations with siloed programmes of work)

Having a shared language requires consistency — this makes things easier to find and evaluate if it’s the thing you are looking for — it’s easier to do this because it’s expected and you don’t have to learn something new each time you look for a piece of research. It also needs to be understandable to all, especially if non-user research experts are using the library.

In a second iteration, you could continue to add useful things to the repo. This will support people doing research to do consistent research more easily, it will save them time and effort, it will help you all be GDPR compliant, it helps certain ReOps tasks be self-service.

* it’s important to highlight here that data can also get trapped in silos, in the different tools we use to do the research, of which there are often many, one tool for card sorting and tree testing, another for running usability and interview sessions, a tool for surveys etc etc. It’s not always easy to, and depending on data processing agreements and regulations we may not want to move data from one tool to another.

So what happens if we need to store our data in multiple places? This is tricky and I don’t have a good answer, but one thing we can do is link them to give. Document in the repo where the data is stored/where it can be accessed.

This also comes with the additional data protection questions, of what to do in the repo when the time comes to delete the raw data, for whatever reasons. I think that’s probably a whole other talk, and it’s too much to get into now.

When considering creating insight libraries the first thing i’d reiterate is that research report repo ≠ Insight library.

A research report repository is not an insight library. An insight library is a collation of knowledge, an insight that has been extracted from the research data, not links to reports. That’s not to diminish the usefulness of a research report repo, but insight libraries are more sophisticated and require a lot more work.

You can’t have a quality insight library, without quality insights

This means that robust analysis is a cornerstone of any high-quality user research, but I include it here because it’s really hard. Analysis is a skill in itself and it’s quite easy to do an unintentional bad job of it. Robust analysis is a sophisticated skill, and a necessary skill to be able to share high-quality research insight.

Why invest in an insight library?

Be able to:

Properly categorise research insight
Find insight easily
Understand provenance, context & limitations of research
Discover patterns
Support an evidence-based approach

As with most elements of user research, there isn’t one way to structure your insights.

The first one we’ll look at is likely to be the most familiar — user needs.

User Needs

Based on a talk done in 2017 in Paris for OCED with Kate Ivy-Williams when I was at GDS.

Stated need: This is an example of a need as stated by the user themselves. Stated needs are in the user’s own language.

Unstated need: They won’t say it, they assume you know this. These kinds of needs are inferred from other things the user’s say and through their behaviour.

User needs are usually written in this format. It’s useful to identify which type of user the need is relevant to (maybe more than one user group):

As a… [what user group are they from?]

I need/want/expect to… [what does the user want to do?]

So that… [why does the user want to do this?]

User needs should:

Be written in the user’s language
Help you organise and prioritise work
Describe the problem, not the solution

Insight taxonomy

This second way to structure your insights is using an insight taxonomy I adapted from the one that Uber created.

Part of the process of creating an effective research practice and research sharing could be to define what actionable insight means for your organisation.

This taxonomy is adapted from the Uber insight taxonomy. Such taxonomies can be used to help with governance and answering the questions of what should be included and what should be left out of your library. For example, your entry in the library must include the things outlined in the taxonomy or it doesn’t get included.

Atomic research

The third way is the Atomic Research approach to managing research knowledge that redefines the atomic unit of a research insight.

Atomic unit of research insight = a nugget.

A nugget = tagged observation supported by evidence.

A single experience insight about a user’s experience.

Tags classify the nugget and allow it to be found when needed.

Evidence = material that supports the observation — video, audio, images.

Procedural tags: date, time, source, research method, media type

Demographic tags: age, location

Experience tags: magnitude, frequency, emotion

Business tags: revenue range, business unit, product line

Service design tags: journey, act, scene, character

Examples and case studies

So we’ve looked at the theory in quite a lot of detail. Now we’ll look at some case studies of what various organisations have done in this space both in terms of Repos and Libraries.

Based on work I did at GDS with the Service Communities team

Service communities are networks of people in different public sector departments who work together to design and deliver an end-to-end service, like start a business or get health benefits. At the time this work was being done, it was not easy to share research findings between different government departments. Sharing insight with a different department was considered making the insight public.

We identified the basic elements that are important to share to make the information useful to others but also easier to share, without having information sensitivity concerns. These categories can essentially be used as a crib sheet or a summary sheet that the researcher can complete:

Context (such as service, phase of development)
Research questions
Sample size
User groups/persona summary
Research methodology used
Ethical considerations and consent
Materials and artefacts used in the research
Summary of findings and insights

Constraints are not just around the sensitivity of data but also the platform that we share on. There was no one, secure tool that all government departments are currently using to share this kind of information. Rather, many different tools are used in different departments.

Created and iterated a user research summary sheet — sort of a simple hybrid between a repo and a library. Through iteration of the crib sheet, we removed all jargon so it could be used by anyone.

Research output repo - How Home Office Digital did it

The Home Office Digital team created a repo of user research outputs. This was achieved by a couple of people going through all the raw data themselves to identify user needs in a consistent way, which is quite an undertaking. The repo included:

Links lists of user needs that don’t change very often and give a real feel for the context
Links to experience maps / actual user journeys
Anonymised interview transcripts
Research brief, research questions and debriefs
Types of users
Anonymised case studies
Anonymised highlight videos
Summary slide decks of insights
Photos of research happening and being synthesised, to give a sense that it’s real

Research process repo - How we’re currently doing it at Springer Nature

We track the research process through a Trello board — combining artefacts and reports in the same place.

Repo governance - Ofsted governance

Salma Patel used governance to have a community-sourced research library at Ofsted, encouraging teams to add their own research into the library and the description into the catalogue. Some of the instructions listed after the contents page in the catalogue include:

Which files should be placed in the catalogue
How to anonymise participant data adequately
Which naming structure they should use to add files and folders to the catalogue
How to link the catalogue to the new files they have inserted
How to share the files in the library
How and from whom they can request access to edit the catalogue

Ofsted is the Office for Standards in Education, Children’s Services and Skills

Defining the scope of the research repository - University of Arizona Library

By defining the scope for the research repo, it helped them define their metadata and templates for each project and make it manageable to maintain, using a tool called Notion.

Scope: to be useful, practical, sustainable.

Only data relevant to multiple departments.
Only user-focussed research aiming to improve services.
Other data is out of scope.

Metadata for each research project:

Title of project
Start date
Researcher(s)
Status (planning, execution, analysis, reporting, completed)
Related department(s)
Tags (for type of research, e.g. interviews, usability testing)
Products (e.g. main website, Weaver Library)
Keywords
User type

Summary template for each project:

What we did and why
What we found
What we did next
Now what?

WeWork Insight Library

We’ve looked at atomic research which WeWork used to structure their insights, they used Airtable. Their intentions are to meet three needs of the team members:

I. Prioritize: Decide whether one project is more important than another based on data rather than passion and gut feeling. The tool helps with identifying valid and reliable user needs.

II. Educate: Polaris helps with getting insights from actual users about a project that is already in progress.

III. Allocate: If a team is looking for its next project (big or small), Polaris helps decide what that project might be.

Uber Insight Library - Kaleidoscope

We have also seen the way Uber structured their insights through the insight taxonomy. They wanted to increase the impact of their research insights by sharing insights from teams around the world and use insights to inform decisions on where to invest. They have a really useful example of the difference between a finding and an insight.

Other examples I’ve found of how to organise your research insights:

https://www.qualdesk.com/blog/strategic-vs-tactical-insights

https://uxdesign.cc/how-can-you-make-ux-research-insights-visible-traceable-and-fun-14aee6376e5d

https://uxdesign.cc/learning-cards-bf7fb204d2f6

Conclusions

Global Research Operations community project focusing on research repositories — aims to discover why they are needed, what is needed to put one together, how to maintain them to deliver lasting value for people doing, using or supporting user research.