Managing what we know: Lessons from the Atlassian Research Library (Think Tank)

Being able to find relevant existing research content quickly helps us respond promptly to stakeholder requests, share relevant research, and scope new research projects.

During this webinar, Alison Jones provided realistic and achievable ways of getting started with managing your existing research content. Drawing on the foundations underpinning the success of the Atlassian Research Library, you will learn how to organise and describe your research content so you can easily discover all your existing research on any topic.

The webinar also covers how employing an information professional, now or in the future, will greatly increase the impact of your team’s research across your organisation.

Watch the recording

Watch the recording of the session or read the session notes below.

Transcript

Alison – I am grateful to UXinsight for this opportunity to discuss managing what we know with everyone here. Here in Australia, it is usual to commence presentations with an acknowledgement of the County, showing respect for the traditional owners of the County in which we are residing, and I’d therefore like to begin with such an acknowledgement.
I’d like to acknowledge the traditional owners of the land on which I am presenting today, the Ngunnawal and Ngambri peoples of the area now known as Canberra and pay my respect to Elders, past and present.

This image is of Tidbinbilla, just outside Canberra where I live. Tidbinbilla is an area of particular significance to local Aboriginal people and much loved by all Canberrans.

I’m Alison, Lead Research Librarian working in the Atlassian Research and Insights Team. In early 2022, the team wanted to develop a research library that worked and decided to hire a librarian – me! Today, I will share with you some ideas on creating a simple research library which will manage your existing research.

Why would you want to manage what you know?

The research library which I will show you how to create today will at very least:

• Enable all researchers to find existing research on any topic, reducing duplicated research;
• Enable researchers to easily conduct secondary research, because you can quickly find all the relevant research on a topic and spend your time analysing and synthesising what you know. This enables prompt responses to stakeholder requests and;
• Enable your colleagues beyond the research team to self-serve into the library, helping themselves to the goodness of your research content.

With all those advantages, who wouldn’t want a research library?!

But most research teams don’t have a librarian to create & manage your library, and managing research knowledge is usually done as a side task by researchers.
I truly believe you can create a simple library that will assist at least the research team in undertaking research, without any professional input from a librarian or similar, and as a “side task” to your main job.

Today, we will focus on three key concepts that will enable you to set up a simple library, which will provide a great start to managing what is known by your research team. These concepts are:

• Don’t collect – catalogue!
• Concentrate on consistency and
• The soon-to-be-revealed secret to widespread library adoption.

Let’s look in detail at each of these concepts and what they mean in practice.

Don’t collect, catalogue

I’ve seen a lot of research libraries attempted by various research teams in the past few years. Most teams have gone to enormous trouble to gather all their research content into a single place. When I ask them why they collect their research, they don’t know. Maybe it’s because when we think of a library, we immediately think of a very organised collection of books. So, we assume that to have a library, our research needs to be neatly collected into a single space.

But when you think about it, there’s no advantage in gathering your research content together. Physical books are only collected in a library and lent out to people because that’s the most effective way of making physical books widely available. In a research team – where I hope no one is producing their research content as a printed book – the most effective way to make our research content widely available is to tell our users what research exists and provide the URL for each research artefact so they can find the research relevant to them.

In this model, the library is where relevant content is recorded and discovered through being directed to its URL, and is not a collection of content at all.

The Atlassian Research Library records all the Research and Insight Team’s content and enables it all to be found… but contains absolutely nothing.

Now that’s great news for all of us! Because suddenly, the seemingly insurmountable task of collecting all your research content into one space, including converting it into a format that allows it to be included in that space, completely vanishes! You don’t have to spend time migrating the content or converting the content at all.

So, what are we to do instead? What do I mean by the word “catalogue” when I suggest you shouldn’t collect but catalogue?

Concentrate on consistency

I mean that you should concentrate on building a space which describes all your research content consistently – in other words, your library, like the Atlassian Research Library, is actually a simple library catalogue. Let’s have a look at what this kind of library looks like.

Here is a mock-up of exactly such a library! This is built in Confluence Databases, which you now have access to if you have use Confluence. There are other tools that will do a similar job, such as Airtable and SharePoint Lists.

This mock-up only contains 4 pretend records. You might look at this and think “well, even if that contained hundreds of records, that’s so simple. Are you sure?” I recently saw a beautiful research library like this being developed by someone who I think is here today – a shout out to you Isabel if you are here! One of her concerns was that this approach was too simple, but I was able to assure her she was on exactly the right track.
The beauty of this approach is precisely that it is so simple. It is relatively easy to set up, easy to maintain and better still, it works!!

What do we need to think about when we set up such a library?

Let’s look at the elements of this library that enable the research content to be consistently described. Firstly, fields. We need to think about what attributes of our research content will be searched for by library users to separate one piece of research from another and then provide fields for each attribute. So, for example,

• Our users often know of a researcher who conducts research in their area, and they want to find research by that researcher. We therefore include a field to allow them to search by author.
• We have a lot of products at Atlassian, so our users will want to search by product, and we therefore include a product field. and
• Our research, like yours, covers a wide variety of topics, such as product features or a customer experience. Users must be able to find research related to these topics so a topics field will be essential in almost all research libraries.

In all those fields, we always enter the information consistently. But what “consistent” means varies depending on the field. In some fields, like the title, the actual wording will vary for every piece of content, as all artefacts will have a unique title. How we enter that title though should still be consistent. For example, the Atlassian Research Library always records the title exactly as it is displayed at the top of the research report.

But there’s other fields where we are describing concepts common across many reports, and we need to enforce the use of one term to describe that common concept whenever it occurs in our research content.

To see what I mean, let’s first consider the product field in the mock library. One of our products is called Confluence and we obviously want everyone to be able to find all the research on Confluence. Within Atlassian, Confluence is often referred to by a shortened name and by a nickname, so mandating that we always use the term Confluence for any report about Confluence is important. The tag “Confluence” is therefore included in the list of terms that can be used in the Products field. This mock library is set up so that we can select multiple terms from this term list for any library record, so we can select all the products mentioned in a research artefact.

Likewise, we use a term list for our topics to ensure we always describe a topic using the same term. In this list, we have included the term “purchase”. If a report refers to purchasing a product or buying a product or procuring a product, we will always tag it with the term Purchase. Again, this is set up so we can select all relevant topic terms from this list for each record.

Why do we take the trouble to create term lists and only allow terms from that term list to be selected? Well applying the term Confluence to all research about Confluence enables users to ultimately find all the research about Confluence. Likewise, all research on the experience of purchasing a product can be found by users searching on the word “purchase”, regardless of whether the research refers to purchasing, buying or procuring.

Being this consistent in how we describe our research is the absolute key to the success of your library.

Because it enables the user to find all the research on a product or topic of interest to them. And when users combine these terms in the library to pinpoint research of relevance to them, such consistency quickly becomes very powerful.

To understand this better, let’s see what happens when we run this library live. Because this library is hosted in Confluence Databases, it has some searching and filtering capability. Let’s make use of that to show you the strength of consistent description, even with this very small dataset of four research reports. So, our library user wants to find research on purchasing Confluence. They type the word “purchase” into the search box.
And immediately it returns just the two reports which cover the topic of purchasing.

Now, if they had a long list of results here and wanted to find only reports on purchasing Confluence, they could also do that using filters. Once they apply that filter, they get one record returned containing the topic of purchase and the product of Confluence.
If you imagine a library with many hundreds of reports all consistently described by well curated term lists, you can see how this library enables users to quickly find highly relevant research content.

To summarise how you’d go about creating such a library:

Firstly, think about the fields you need to describe all the research attributes which are important to users of your library.
Then think about how you are going to ensure consistency in the information recorded in each field. Pay attention to entering unique information, such as a title, in a broadly consistent fashion. And consider which fields will need a term list to ensure the application of consistent terms so that users can find all relevant research.

Term lists can start very simply. If there’s one thing I’d do differently now if I was starting the Atlassian Research Library today, it would be to begin with a much simpler term list for my topics field. I think that just beginning with very broad terms, like “feature” or, “customer experience” can be legitimate, as even that broad level of description will start to distinguish between research on different topics.
Because it’s your term list, it can and should always change and grow. So be bold with your term lists – you can’t get them wrong, they’re also never perfect and you can always change them.

Populate your library

To populate your library, I’d suggest starting with the research you’re doing when your library is ready to receive content. Once new content is being contributed smoothly and the library is beginning to run nicely, you can then consider back capturing older research. You may not need to capture it all. You may want to capture it “lightly” and not fill in every field, just the critical ones.

If you create a library like this, I know that you will soon have a library that is being well used by your research team to quickly identify relevant content for secondary research and to reduce duplication. That alone makes a research library so worthwhile!

Secret to an adopted library

But… and here I’m going to get controversial… if you really want your library to grow and to be adopted beyond the research team, I think you will eventually find that you need to hire a person dedicated to running it. So, my secret to getting your library adopted across your organisation is to hire a librarian! Or a similar information professional, such as an archivist or records manager.

Because to get it really humming, you need to go beyond this library, which is just the library-as-a-tool, and develop a whole library-as-a-service around it.

What do I mean by a library-as-a-service?

Well, here’s the main activities I currently undertake to support all Atlassians to make excellent use of the library. This is my library-as-a-service. You can see that there’s so much that goes into enabling people to use the library well and therefore getting it adopted into their daily work. To mention some briefly, for me, it includes:

• Encouraging a culture among those who can contribute of contributing research content to the library.
• Running library workshops to assist any Atlassian to find relevant information or to provide training on using the library and
• Providing desk research support to the Research team, which further speeds up our team’s response to stakeholders.
• All of this is in addition to the small matter of maintaining the library, including maintaining the associated term lists and taxonomies.

It is this library-as-a-service that has enabled the adoption of the library across Atlassian because it is no longer just a tool thrown at people to use but a service which supports researchers to manage what they know, and which helps everyone to discover what is known by the research team in a timely and decision ready fashion. Less than two years since the library launched, about 10% of all Atlassians have used the library and 1/3 of those users are repeat users. They tell me that they love the ease of self serving into the library to find relevant research content for themselves, while also appreciating the support available.

The great news is that if you have developed a simple library such as we’ve discussed today and you eventually bring a dedicated information professional onboard to run the library, they will love that this simple library is already available. They’ll be able to immediately make use of it to start developing a library-as-a-service. And the consistent data applied in the library will provide an excellent basis for future library development.

So, at Atlassian, with a library on a highly functional platform, a librarian and a well developed library as a service, is managing what we know at Atlassian at the point where I as the librarian can sit back, relax and everything will just work smoothly? For me, one of the best aspects of working as a librarian is that a library, both the tool and the library service, is never complete. It’s always changing, growing and developing and it’s therefore also always going to be imperfect.

For us, we have almost all the existing research content from the Research and Insights team discoverable through the Atlassian Research Library and all the services I previously mentioned supporting everyone with using the library. I know that this is currently unusual in research teams, and I’d love to see it become way more usual.

But even at this stage of knowledge management maturity, we have some big questions before us.

Atlassian has democratised research & we’re grappling with whether to include research done by people outside the research team in the library. We’ve recently run a proof-of-concept to include some data science analysis content in the library & are now wondering, should we further expand the scope of what the library collects to include research created outside the research team?
Our other big question is how far can the library go while it only has one dedicated staff member? Which I know is one more than almost all other Research teams have but is a live question against which all questions of growth and scaling need to be run.

So those are the two big challenges that we currently face on which I’d welcome some further discussion. Equally, I would love to answer any questions you have about managing what you know through developing a simple library as has been
demonstrated and I look forward to discussing more broadly how UX researchers can manage what we know.

Photo by Craig Strahorn on Unsplash