Repositories in Practice:
Using Knowledge Management to Create Research Stories
This article is based on Emily’s June 2022 presentation at ResearchOps Conference. In the transition to article format, the presentation transcript was edited for length and clarity.
Watch video of talk | View all ResearchOps Conference videos
Beyond magical thinking
In conversations about research repositories, I’ve observed a little bit of magical thinking that goes something like “if we implement this repository, then all of our insights will be used.” Which, as we all know, is not true. You just create another place to put things, and a repository will not solve all of your knowledge management problems.
Three practices and behaviors that are critical to knowledge management:
1. Centralize content — Collecting all of the materials, artifacts, report outs, links to figma, etc. in one place, so you can find everything later. This is harder than it sounds.
2. Implement description practices — Defining and applying standard descriptions for research assets.
3. Curate content — Deciding what you want to put into the repository. What the boundaries are and what people should expect to find there.
In this article, we’ll focus on the second point — description practices — as a key aspect of knowledge management to start thinking about in the context of research repositories.
Toward archival description for research
Let’s start with a scenario:
Let’s say you put a document into a repository that’s acting as a report library, which is a fine place to start with research knowledge management. Let’s say it’s a 20-page report, or a link to a mural board with the report out on it.
A product manager or some other person might look at the document and wonder, “hmmm, what am I looking at exactly?” They then spend the next 10 minutes trying to figure that out.
This is not what we want people to do in our repository.
We need archival description.
Well, what’s that you may be asking? Archivists use a handbook called DACS (Describing Archives a Content Standard). This manual tells archivists exactly how to describe materials in collections.
And from DACS, the key value is to provide maximum access to materials.
“An essential precondition for providing access is sufficient and effective description.” -Preface, DACS 2021.0.0.2
Description is part of the the daily life of archivists and librarians:
Description = Access
Access = Democratization
Democratization connects people with information
And this is basically what we want to do with research repositories.
How do we define description? Where does it go?
There are two parts of description to consider — which are essentially scope and content:
- Information about the nature of the materials >
What is this thing? - Activities reflected in the unit being described >
What was this thing used for?
The reason that you provide it this way, is that you’re giving information to your repository users, so that they can judge how relevant the content is for their own needs.
There are two essential places to implement description:
- In your centralized file location, like Sharepoint, for example — or whatever tool you might be using to collect research.
- In your research outputs, whatever your organization uses: report, slide deck, mural board, etc.
Description in centralized content
The example pictured below has a variety of files in a file directory, and I’ve included some questions here that you might have, say if you were a new researcher coming on to a team and looking through the old research files and deciding what you should look at.
I would also point out that file naming as a form of description, which is important, but file naming doesn’t give us quite enough description for what we need.
So the image below shows the same files after some description has been applied. I took about 5 minutes to add a “what is this” column. In that column, I’ve added a variety of different descriptions. For example, I’ve added when interviews were conducted, so you know when you might need to get rid of them. For a brainstorming file, I added context to say that there was a product manager there, so you might want to go back and see what they said, and check whether we acted on it. I added the difference between the two reporting decks. For example, one file has the original research timeline, but another has how the timeline actually ended up.
So again, use cases for this kind of description are going to be thinks like new team members getting up to speed, managers wanting to look at something you’ve done, or you collecting artifacts to put into your repository.
Description in your report-outs
Going back to that earlier example of looking at a document and wondering “what I’m looking at,” I’ve gathered reports within an organization and found that basic things were missing, like date. There was no standard for describing research.
- One option is a metadata checklist to help make sure that your outputs contain consistent descriptive information.
- Another option is to use a metadata template that you can drop into documents and fill out.
- Additionally, the first thing that users want to see are the high-level insights that came from a research project, so you want to put that up front.
You’ll want to make each of these types of description very visible, so that people don’t have to go looking for them.
Report metadata: The MVT Level 1
[Update since presentation] The ResearchOps Community’s Repositories program has released Level 1 of the Minimum Viable Taxonomy (MVT). MVT Level 1 is a taxonomy for indexing research documents and artifacts and supports the research register and research library knowledge management systems.
Elements of the MVT Level 1 standard include:
- Project title / Project code or identifier
- Date
- Name of Product, Service, or Problem Space
- Topic(s) or Research Question
- Target Audience(s)
- Report Deliverables
- Researcher name / Research team
- Sample Size
- Access Level
- Research Method(s)
- Related / Cited research
See the MVT Level 1 article for additional details.
Example of description in your report-outs
Below, the yellow boxes — placed into a presentation and a miro board — are examples of where you might insert a metadata template. Or you might make a separate slide or area to hold this information. Regardless, again, it’s about visibility and putting it somewhere super obvious.
Better yet, if you have a tool that lets you do this, don’t put it in the document at all — put it in the description that pops up before the person opens the document, so they already know what they’re going to look at.
How do these knowledge management practices create research stories?
Creating description leads to synthesis (aka, storytelling). Just going through and reviewing your documents is synthesis. Don’t underestimate the power of doing this. When creating a description, you’re deciding what’s the most important story to tell about a document.
Forgotten / discarded insights. In reviewing research, you may remember some insights that you did throw on the cutting room floor or just weren’t relevant. Take the time to describe that and write it down.
Gaps and inconsistencies in the research process may become clear upon reviewing a set of research outputs.
Opportunities to create better stories. As you create this description — as you go through your artifacts and go through the process — you can improve the stories being told across the collected research.
Final thoughts
Another quote from DACS to conclude:
“Archivists make descriptive choices that impact how users find, identify, select, and use archival records. To make wise choices about descriptive practices, archivists must develop and maintain an awareness of user needs and behaviors.” -DACS Statement of Principles v.2021.0.0.2
What I’ve also observed, coming into companies as an anthropologist, is that being a researcher is really hard. When do researchers talk about their own stories? They talk about user stories, customer stories — but when do they talk about the story of their own research? I think that this lack of reflexivity is a missed opportunity.
I worked with this great research manager who did a debrief after every research study and video recorded it. This is brilliant. Not only is it a debrief where you could talk about what really happened, if you ask the same questions every time you do that debrief, you have got a great nugget of storytelling for your team. If you make it really brief, like 15 minutes, then it’s gold, and people can review it later.
Thank you to Brigette Metzler, Holly Cole, Ian Hamilton and the ReOps community!
