Insights Repositories with Nada Alnakeeb and Joanna Perez

Published:

May 4, 2022

Last Updated:

November 1, 2022

Public libraries have been using insights repositories for decades—and it’s time user research teams catch up. This week, we’re joined by Nada Alnakeeb, Head of Design and Research Operations at DoorDash, and Joanna Perez, Sr. Taxonomy Strategist/Digital Archivist, Studio Production at Netflix.

Nada and Joanna shared learnings from their experience building the insights repository at Meta, using familiar organizational patterns to reduce mental load, tips for effective taxonomies, and more.

They talked about…

The business case for an insights repository
The tools and teams required to build a minimum viable repository
Features to look for in a repository tool
How to ensure continued adoption and success

Plus—why every good insights repository needs a good librarian.

Listen to the episode

Click the embedded player below to listen to the audio recording. Go to our podcast website for full episode details.

Highlights

[00:01:34] Their experience building the repository at Meta

[00:04:14] Why everyone needs an insights repository

[00:05:54] How to archive fleeting or one-off insights

[00:07:59] Tools and teams required to build a minimum viable repository

[00:09:10] Building a low-budget repository

[00:11:20] What is an ‘insight’?

[00:12:42] Why does the way you organize insights matter?

[00:13:23] Using familiar organizational patterns to reduce mental load

[00:17:57] Features to look for in a repository tool

[00:24:53] Buying vs. building in-house

[00:28:08] The business case for a repository tool

[00:30:04] How to ensure continued adoption and maintenance

[00:33:29] Considerations for scale

[00:36:52] Measuring success and value

[00:39:20] Tips for effective taxonomies and mistakes to avoid

About our guests

Nada Alnakeeb is Head of Design and Research Operations at DoorDash. Joanna Perez is the Sr. Taxonomy Strategist/Digital Archivist of Studio Production at Netflix. Previously, they’ve worked together in Research Operations at Facebook (now Meta).

Transcript

[00:00:00] Joanna: It’s definitely not a set it and forget it tool. This is a program that's ongoing there, and isn't the beginning and end. It's going to go for as long as your team, assets, company exist. So it's something that does have to be lovingly cared for on a day to day basis.

[00:00:40] Erin: Hi everybody. And welcome back to Awkward Silences. Today we are here with not one, but two guests, very lucky to have Nada Alnakeeb and Joanna Perez here. We've got Nada from DoorDash, Head of Design and Research Operations. We've got Joanna from Netflix, Senior Taxonomy Strategist, Digital Archivist and Studio Production. And we're going to be talking about insights repositories, and you thank you for being with us.

[00:01:09] Nada: Thanks for having us.

[00:01:11] Joanna: Hello.

[00:01:12] Erin: Hello hello. Got JH here too.

[00:01:15] JH: Yeah. I think in a recent episode, I had a hot take that insight repositories are going to make some big leaps forward this year. So maybe we'll figure it out on this podcast together.

[00:01:23] Erin: Yeah, let's figure it out. They keep coming up more and more

[00:01:26] Nada: and they will, it's a hot topic, for sure.

[00:01:30] Erin: And on that note, you've been thinking about insights repositories for a bit, right.

[00:01:34] Nada: Yeah. Probably now, since what, 2018, 2019 Joanna and I got to work together more closely in the time period between. I think 2019 or 2020. I don't remember. I feel like with the pandemic, it's been like years now. but yeah, Joanna and I worked together on the research operations function over at Meta or Facebook.

And we specifically focused on the repository space and finding the right tool and the right process to archive research reports. And there is where I learned a whole lot from Joanna about taxonomy, about, you know, how system architectures and metadata work. And she was our awesome librarian that we brought on after I put together some main business requirements to have a repository.

And then she came in and we flushed all of those together and launched a really solid tool there for researchers to use. Joanna, you want to talk a little bit about that?

[00:02:34] Joanna: Yeah, I was super excited to come on. Like the whole team was just awesome and amazing. And as someone that's been doing this for quite some time and the reason we're all here, you know, obviously I'm not just biased. I definitely think that repositories are wonderful and great for everyone. But this particular experience was just really great and awesome.

And we were able to move really quickly and build something that I think our users we're happy to have. And we had so much support that it was amazing. But yes, it's, I am a librarian and I will be the first person to say, everybody needs a centralized repository. It's something that public libraries have been doing for decades now.

So it is nothing new, but it suits the needs for everyone, whether you're just a small team within a larger org that they just need for a specific purpose or a museum or a gaming company or Netflix or Facebook or Amazon. Everyone needs one.

[00:03:35] JH: Yeah, so I'm guessing you're curious, you know, why is that? Cause I think on the surface, it seems somewhat obvious, right? If we did all this work to learn things. This is valuable information. Let's make it cataloged and accessible for people. So we don't have to go do that work again. The next time questions here come up.

But there is a little bit of a, probably a tough conflict, right? Where some things you learn are much more evergreen, or like this is a core truth about this user and how they feel or how they experience things. And then other things are going to be very, like, much more fleeting or like, this is feedback on this screen, but we redesigned it three months later.

So it's not really applicable anymore. Like what, what is like the why of how it becomes valuable for a whole team?

[00:04:14] Nada: I mean, I can talk to you about my most recent example here, you know, at the DoorDash, you know, we're a fairly small team. There's about 14 researchers or so, and we grew so much over just the past year. I think it started out with a few researchers. Now we're at 14 and we plan to get bigger and bigger over the next few months.

And you know, when you start out such a small team. Yeah, it might not seem like it's necessary because you know, you always go to that one person or two people and, you ask about, Hey, have we done research about this or that? Or where can we find it? But as your team grows and scales, you need to think about, what research have we done?

Who knows? Right? Like if people company, or like, the more people that join, they want to know about, what have we learned about our products so far, and, you know, how can I come in and make direct impact and pass them impact. So, you know, having a repository it's so important because you can see what's been done, you can see how it's impacted the product directly or how it didn't.

And you can, you know, as somebody new joining the company or somebody that's been here a while, you can actually make that decision of, okay, we have research, that's valuable, you know, I can do more research or I can decide not to, I can use what the data that already lives out there and share it with my product team or with my designers or engineers.

So there's so much value added whether you start small or you start big. I mean, I definitely recommend that you do this right away when your team is small, so you get this right. For the future. But Joanna, you know, a lot about that space there, and it's so important to you too.

[00:05:54] Joanna: And I think something to keep in mind is obviously you want to start at the beginning. The ideal place to start isn't always the case. We wish we could start right at the beginning. We don't have time machines. We can't go backwards. So you know you have to start where you are.

However, one thing I like to think about is, you know, you mentioned insights that may be fleeting, that they may be like a quick one-off use case to remember. It is good to just archive or add everything to the repository, but you can also bake into that a lifecycle for maybe there's those assets that, you know, aren't going to be utilized right away, but you don't know the value of them today. Maybe you only see the value in that small lens of how you're using it today. If you create a lifecycle for your data and it moves maybe to cold or dark storage. So it's there just in case, for example, if you work for a gaming company you may create a game, you knock it out, you have those research insights and let's say they go back and remaster that game 20 years later, you have that data.

You have those insights, you have the original concepts in your cold storage, and you can just pull it out. It may not be there at the forefront with all your insights and all your work that you need today, but it's stored and it's archived.

[00:07:21] Erin: Joanna when you talk about cold storage and life cycles of data, it kind of makes me think that whoever is setting this repository up in the first place should kind of know what they're doing. So I wonder, you know, so the earlier the better, right? That doesn't matter how small a team you want to put those learnings somewhere so that you can use them again and learn from them again, if you are a smaller team or maybe you aren't a librarian or, you know, not sure how to kind of get started.

Minimum viable repository. What are we talking about? What do we need to have a kind of functioning, useful repository?

[00:07:59] Joanna: A tool is ideal, whether you decide to make your tool internal or you go out and you get your tool as a third party. And these are things that have their pros and cons and Nada can probably speak to that very well. But a tool is ideal. If you know that you can only function on folders for a bit, you still need to come up with some type of structure.

So even if you don't have a librarian, although you all should have a librarian, you at least have to have some type of committee of stakeholders that can make these decisions. I mean, even as a librarian, I don't operate in a vacuum. What I build for people for a living. It's not for me, these things aren't mine. They belong to other people and they're the ones that are going to use it. So even if you don't have a librarian, gather a group like a task force of people that can work together to make these decisions, what kind of tool are we going to have? What's our next steps? If you can get an engineer on board, that's even like a win right there. A tools PM like, like we had with Nada, that's a win Nada.

[00:09:10] Nada: I'm going to take a different approach here too, because I'm going to get very realistic. Not everybody has a budget for it. There are companies that are just starting out or teams that are just starting out. And my biggest advice is. Just try to have all of your reports centralized. In one place. And try to, you know, if you can't purchase a tool or if you don't know how to make the decisions about things like, Hey, what are the actual business requirements or product requirements that are needed?

And that's actually the case for a lot of teams and companies right now, what I recommend for you is, hell, just started out of Google sheets. That's fine. Like just put everything in one place, you know, say it's from this date, it's about this product. This is the researcher. And if there's specific, keywords that you know about or specific methodology that you performed in this research just call it out because what this does is, once you do have the ability to hire a librarian or cataloger or.

Even as a program project manager, they can come in and they can help you evaluate different tools or different options, whether you want to build this in house or find a vendor that does this really well. And, you know, it would make things a lot easier for them to see that it's all collected in one place and have that conversation with the vendor and say, okay, this is the data. Now let's think about a plan.

How do we want to map it out to your site? This is what we have today. And, you know, I may need to do some additional work with organizing, but at least it's in one place. So, I would say centralized your data as much as you can, pick one method and stick to it, whether that's going to be, you know, everybody creates the reports in docs or in the, in a deck or you know, and any type of other forms.

Pick something and stick to it and also let your new hires know about it. So that way you know, they can follow the same formatting and the same.

[00:11:09] JH: So we're talking a lot on the repository side, which makes sense. But the other part of this is, you know, insights. I'm actually curious. Maybe we should just start there, like, how would you define an insight? What's an insight to you?

[00:11:20] Nada: I mean, that could be many things. So you know, it depends on the team and how they structure their reporting. So. A lot of teams that I've worked with create research reports. So these are final reports that have, you know, the research details, the findings, the recommendation but there's also times where.

Different metadata involved, different files like videos or PDFs or pictures, you name it. At the end of the day you know, no matter what type of assets or files that you have and how you do this type of reporting you need to think about the final results that you want to share with your partner teams or with your company. So, you know, whether that's a quick one pager or a deck or a document that includes certain images or embedded videos of what your participants mentioned. It's really up to how you want to structure it.

[00:12:21] Erin: Yeah, I think we're talking about right. Like what is the unit of insight? Right. And then I guess to that point, the insights are collected. They get put somewhere organized and then extracted and used, I guess, right by like the end user of, to your point, Joanna, like I'm the librarian, I'm not the, what do you call someone who visits a library, visitor.

[00:12:42] Nada: And I think that's what people are used to, right? Like, you know, when you write and read these research reports at the end of the day you're sharing them, not just with your direct research team, but you know, you have partners that you work with.

You have the product team, the design team engineering, right. And there's so much more and you want to make sure that. The way you organize them here matters, you know, you want to make sure that it's familiar to people and they can locate it easily once you know, put it on a specific topic.

[00:13:23] Joanna: Yeah. Like one of the things that I always think about, I started off my career as a public librarian, and I still think of myself as a public librarian, even though I haven't done that for a very long time.

Is that the public library, their catalogs are amazing. And they've been working in a really fabulous way for a very long time to catalog and give accessibility to people of all ages, to a variety of all subjects, to collections that are in the hundreds of thousands.

So what we did was modernize. As I like to, we like to model our search and discovery or I, and I like to go forward. And every place I work with on what a public library does, creating something that is accessible and familiar to people, no matter who your audience is, whether it's a public library and it's like a three-year-old kid or a senior citizen, or in UX, whether we're talking about the researcher and the creator of an insight.

Or whoever the stakeholders are or the designers or the engineers can all of these people access and use your repository in a way that yes, of course there is going to be some literacy involved that you're going to need to do. But how can you design the system so that literacy is a low-level lift for people that they can just hop in and intuitively know, oh, this is how this is working.

It's familiar because hopefully other people have used similar repositories, whether it's their public library or an online journal database, everything's pretty much the same. So if you follow that model and then couple that with creating really good information, architecture, a taxonomy, then it's going to be this really awesome, beautiful, usable thing.

[00:15:28] Erin: Right. And so you're talking about using patterns and organizing systems. People are used to, whether it be, I don't know, alphabetical order or tags or folders within folders, there's some sort of hierarchy like these kinds of things that might be ways that people are used to organizing information, right?

Like not reinventing the organization structures themselves, but starting with a familiar pattern someone's used before. And then letting that be a way of organizing these insights?

[00:15:54] Joanna: Yeah, for sure. Like, and some of these dams, you know, when you purchase on these repositories digital asset management systems, Some of them will favor folder structures, which is fine. And then some will favor something where you have to really build a good, robust taxonomy and information architecture.

But it does help when it's familiar. Because even though you may strive to bake in information literacy programs, and training. You may not be able to capture all of your audience all the time. So yeah, it does help to create some familiar structure. And again if you're a company or your department or a team that isn't going to hire a librarian and, or can't hire a librarian right away don't think too hard about it.

Like, don't try to go nuts and do something entirely off the wall because you have a goal. You want to store your information for the now and the future, and you want to make it accessible for the now in the future. Don't get nuts trying to do something crazy.

[00:17:03] Erin: and I think that's a good segue to maybe talk more about tools. Cause I know we have a lot of experience finding, buying, purchasing a tool, and we're saying at the beginning, get a tool. It's a good place to start because as you were saying, Joanna, like. You need the tools to have some opinion, right?

Some are going to be more flexible than others, but there's going to be, you're going to be somewhat limited somewhere in terms of how you can build this out. So I imagine you don't want to get too far down the path of building out, you know, a really robust organization, organizational structure with tagging and metadata and all of this before you've decided on a tool, or maybe you can correct me if I'm wrong.

When's the best time to kind of start planning out. What tool are we going to use? And then all of the organizational decisions we need to make about how we get our insights into that tool. How does that work? How do those things fit together?

[00:17:57] Nada: I would say the very first thing you need is like, identify what your goals are, like, what your goals are for the team, for the company. And that could differ from one team to another. Right, going back to like familiarity too. You want to think of it like this. If you're a non researcher or if you're a researcher, it's the same thing, but you think of it, like, as you go into a website, you want to make sure that there's the ability to search, right?

So, that's a common function. And as you search and I'll, you know, give an example here. Macy's, for example, in your online shopping for a dress, you search for a dress. And from there you want to be able to look into different filters and categories to really nail down the beautiful, most perfect dress for you that you want to purchase.

It's really the same idea here. You know, you want to make sure that you pick a tool that can do just that. So for me, when I evaluate tools, I have three main things. A place that truly centralizes where our insights live and that a place that researchers or I'll call them content creators here, because it's not just the researcher that's uploading the material, but sometimes you have to, you know, the librarian or the cataloger, or even designers who do research.

You want to make sure that the tool has those super simple UI where people can just go in and create content. But also it's smart enough that it could tell you that you need to tag a certain way, or you need to make sure that you've uploaded all your material before you move on and publish it.

Another thing that I look at going back to content creation versus content discovery is that it's super easy for people to just go into the site or go into the centralized place and find what they need. The idea is for it to be self-serve as much as possible. And the other thing that I really care about that we haven't talked about yet is how secure this space is. You know, you want to make sure, cause you're, sometimes you have a lot of sensitive data. PII is involved and you know, that's just the nature of research. So as you're thinking about what type of requirements you have for this ideal tool. You have to think about the security functions as well and security functions here.

It's just not, where does the data live and how secure it is, but also how customizable is that process of security? Meaning, if I have specific type of insights that can only be shared with a specific team or specific individuals, you want to make sure that the system has those capabilities of really nailing down and saying, you know, this post can only be viewable by this person or this team versus this post should be or this, these insights should be viewable by everybody at the company. You know, we want everyone to see what this research is all about. So I would say three things that I care about is centralizing the content and it's an easy way for content creators to upload all of their materials as well as discovery, like how are we leveraging past research and security is the top three things for me that I look at.

[00:21:14] JH: You mentioned the content piece a little bit. And I'm curious cause I think in a lot of roles you get insights from all over the place. Like obviously there's the, we’ll usually internally refer to it as active research. Like we went out and did an active study here to learn something, whether that be, you know, more generative or evaluative or whatever.

But you know, you also get stuff through sales or customer support or whatever, right. With interesting feedback through an interaction or a concern that a prospect had or whatever. Would you think about pulling that kind of stuff in here as well? Or is that separately?

[00:22:22] Nada: I think it all depends. Really the teams and like how centralized research is, there are, I've worked at companies where research was super centralized and all the research that was done was through research teams or design teams. I also have been in a company where it's not centralized.

And there are people everywhere at the company doing research, just because maybe there's no, not enough resources available, not enough head count for researchers. So I'd recommend you evaluate this as part of your requirements stage. And as part of the draft stage, when you're trying to figure out, you know, what's our goal here?

Do we want everyone at the company to be able to upload, or do we want to keep this more standardized and minimal to just the research team? Our focus specifically like Joanna and I is the research teams, you know, coming from Facebook, or Meta, we had a really big research team who had lots of reports and insights to share and, you know, they were doing it maybe differently, or they had a centralized place and we just wanted to.

That was our focus. That was our goal is to get the research team's insights all into one place. So I would say it really all depends on your company. And I would definitely think about who your content creators are as you're building out these requirements. Because there's going to be part of your, you know, rollout process as well.

You know, your training, your communications. So, yeah it's dependent.

[00:23:52] Erin: Gotcha. So, so we've talked about, you know, generally speaking, any kind of system you're going to use, you want to think about getting the information in easily and centrally getting it out easily and making sure it's secure. There are a lot of different kinds of tools and solutions. In different scenarios could get you there.

What do you think about, you know, one, one option you might come across and you mentioned Nada that some folks maybe don't have the budget to buy a custom solution, so that might factor in here, but how do you, what's your opinion of, or what do you think about. You know, you're seeing a lot more emergent, dedicated tools for the purpose of research insight repositories.

Then you have other, you know, I think Joanna, you mentioned dams that can be used for all sorts of different kinds of digital assets, whether they be a researcher or other. And then of course you have Google spreadsheets and general purpose tools like that. So how do you go about thinking about what kind of category of tool might be a good fit for your needs?

[00:24:53] Nada: I mean, we're in a much better place right now in 2022, then we were, you know, back in 20 18, 19 trying to figure this out because there, there have been a lot of tools that have since launched or have made iterations to make this you know, a more simpler process for. Research teams to consider. But you know, at the end of the day, whether you are in operations or you're a researcher or a research manager, and you really want to centralize your insights all into one place, you should really, you know, you have a business case at the end of the day. Right. And you should really think about investing in a repository system versus all the other hacks that we have out today, like, you know, spreadsheets for example or using folders.

But really think about investing early. You know, Joanna mentioned earlier, like hire a librarian first, if you can. Plus one to that, for sure. And that's exactly what I'm going through right now. And, you know, talking about it with our research leaders here at DoorDash, they all agree.

And then they see the value in bringing on a system that already, you know, works and also looking into the opportunity of bringing on a librarian to really help us manage all the insights that go in and go out of it. So I would definitely recommend that people look at the value that it would bring in and create that budget for the system.

A lot of, you know, a lot of teams might consider building this in-house and that's not a bad idea either. What I would caution in-house is, you know, you definitely need engineering resources. That's a budget that's really hard to get internally. And also over time you know, especially a lot of research teams, don't have direct engineering support.

And if you get like another engineering team to do this for you to do this favor and build you a quick tool over time, their priorities might shift. So you don't want to end up with a tool that's, you know, abandoned over time because you want to make sure that it's a solid foundation and it's maintenanced over time because your needs and your requirements, specifically feature requirements are going to change with time. When we started this out even before Joanna joined the program we had many business requirements. We had feature requirements. We had, you know, we've developed our user journeys and stories and you know, we thought we had it altogether.

And then Joanna came and said, no, we need to ask more. We need to make sure that the system can do this or that. So, so you're, you know, even though you might have known what you need and you get someone to build it for you, chances are for sure that your needs will change over time.

[00:27:33] Erin: So even though, right, it might get a little sticker shock at the price of a tool, especially a new category of tool, right? Like, wait, we're doing fine without this tool. Why do we need this budget? Why do we need this tool? It might save money in the long run. Not actually building it when you factor those things in, and then I imagine the business case, what you're thinking about time saved, right?

Not trying to waste time, hunting down these insights, not having to do the research again, when we already maybe know the answer to some of these questions, what are some of the other business cases for if there's skepticism in terms of, you know, getting a tool for this.

[00:28:08] Nada: Yeah. I mean, like you, you mentioned the obvious where like, ROI is like right there and we can actually like that data or those metrics even over time. But also what we're not considering here, and I talked a little bit about is security, right? Like you, you want to make sure that you invest in something that is a tool that provides security and security options as well.

So, that in itself, Probably your biggest ROI statement there. So, those are definitely things to consider and to create your business statement for an ask like this. And yeah. What else do you think, Joanna, I'm curious to hear from an organizational perspective.

[00:28:50] Joanna: That's funny yeah, you totally called it out. That's always the big one is security. When you get into working for large enterprises or companies that are dealing with sensitive data or sensitive assets that are at risk of leaks could happen. And I mean, as Nada spoke to it earlier, there's so many ways that security is going to work for you internally and control what goes out externally.

That's probably one of the biggest top priorities as somebody that's been a long time archivist. You want to make sure your objects, your assets are safe and secure no matter what they are. No matter if it's research, no matter if it's like some gaming concept, even if it's, you know, a million year old dinosaur bone, you need to make sure it's secure.

And that's probably like the number one. Is your stuff secure? Is it accessible?

[00:29:44] JH: I don't know if either of you have examples here or have seen other teams struggle with it. I'd imagine there's a lot of people or a lot of teams trying to go down this path and either they buy a tool or they set something up themselves and they get it started. And then something about it just never clicks.

Like where do you think, like, what mistakes do people make or where does this not end up working out for teams? And like, how can people get ahead of that?

[00:30:04] Nada: Hire a librarian of ours, or us or a committee, right? Like this is what Joanna talked about early on is like, you want to make sure that commitment is there. And it's part of your goals every quarter every half hell, even every week, you know, set reminders for your teams to make sure that the content is uploaded because that content is created anyway.

It's like, we're all going out to do research work. We're getting insights, we're putting reports together. You just want to make sure that you stay consistent. It's really important that you set those goals ahead of time and you even maybe embedded into your values. Right. You know, as part of your. An example here, if, as part of your hiring process and you know, when you're hiring researchers on board this should be something that you're very proud about.

Like, hey, we also, you know, have a repository of all of our insights and we do this every week. This is becoming more and more common. You know, as we go through, even the interview process, I hear a lot of researchers, ask me “hey, what are we doing about past research reports?''

How are those communicated? Where are they stored today? So it's definitely becoming more of a common thing that people are asking for. I would definitely say, if you choose to invest time or money and resources in a tool, you definitely should have a plan for how it is going to be maintenanced for the long term.

Whether it's, you know, the librarian that you hire or the task force that you put together.

[00:31:33] Joanna: It’s definitely not a set it and forget it tool. This is a program that's ongoing there, and isn't the beginning and end. It's going to go for as long as your team assets company exists. So it's something that does have to be lovingly cared for on a day to day basis. You have to have that point person. You know that at least someone overseeing it to see are the assets that are being ingested into this repository is all the metadata filled out, is everything, are the assets being uploaded?

If you just set up a tool and hope that everybody uses it, that's all well and good. You know, the chances that 100% everyone is using it the way they're supposed to be. That's going to take some time. That's going to take some education and that's like a muscle that's going to have to be exercised to get to that point where everyone is doing it in a way that a librarian that's just second nature to them.

So it is always good to make sure you have that governance over it, to make sure that it is being cared for and maintained over time.

[00:32:45] Erin: Yeah, scale feels really important here, contextually. Cause I'm imagining, were you the only librarian at Meta, Joanna? Were there a bunch or?

[00:32:52] Joanna: There, our team I think we were very unique in that from what I saw and the configure out, we were one of the teams that was doing this idea, this project. To this full fledged beast mode capability that we dreamed of, there are other people at meta that are taxonomists, there's an archivist, who's awesome. But in terms of doing this particular thing in this manner, we're definitely, I think as far as I know, one of the first people to do this.

[00:33:29] Erin: Yeah. Yeah. Cause I'm thinking, you know, in these different scenarios, you know, you're a different size organization, different size research ops, different number of researchers, different number of people who are doing research in the org, right? There's all these different permutations and scales. Just the number of people who are going to do that maintenance and what that looks like can probably vary quite a bit.

You know, the key thing is. It's happening, but you know, any tips on how to make that happen? Is it best to have one dedicated person, if in a large scale scenario, do you even have one full-time person, is that enough? Do you need multiple people? Do you need to then start thinking about democratizing the maintenance of the insights?

Because it's just one, one person or a team of people could never do it. Like what are some ways that might look in terms of this maintenance. You know, it's happening over the long haul.

[00:34:21] Joanna: So having a large team is great. And it's wonderful because you want to collect all those insights, but having one person govern, you know, a very large team of individuals, adding assets to a repository can become very daunting and almost to the point of it's just not scalable.

So you may want to have point people within teams within a large org that you have open communication with that these people are using the system for their team to make sure. Their smaller team is all using the system. They are all adding the correct metadata. They are monitoring the terms that are being used, and if they identify new terms or taxonomy terms then they can push that upstream to the administrators of the tool, whether that's a librarian or a PM or just whoever's assigned to govern the entire tool and say, hey, we're seeing these changes happen. Can we talk about them and kind of flesh them out and add them to the system?

And in that way now you're putting the weight off that one person that may not have the time to manage something where you have insights coming in, you know, a hundred insights a week, which is. Not doable more than a hundred insights a week, which have a lot of content to read through. And unless you're doing the work yourself, you're not quite sure, you know, what is this about?

What does the subject matter? It's going to take a long time for somebody to comb through that. So it is good to have sort of warriors and point people. The stakeholders that you can. Communicate with all of your smaller teams, if you have a large team that you're dealing with.

[00:36:13] JH: So, yeah this is all making sense since you talked about, you know, this is something that has to be very habitual in terms of how you cultivate it and get it started. As you scale, you have to figure out the right kind of hierarchy to keep up with all the insights that are coming in. I guess I'm curious, you do all this work.

How do you all think of like success here in terms of you know, is it just like people are going in there and you see people doing the search and discovery to look for all the insights and that's a signal that it's valuable or is it maybe it's not used all that frequently, but when it is used, it's super helpful.

And so that, you know, that made it all worth it, or I'm just curious what you think about, like, when you see it click for the organization and you're getting value from it. Like, how do you, what are some signals that that's happening?

[00:36:52] Nada: I think there are different ways to measure success. That one great way to do this through a tool is, you know, you look into the system metrics and you can see are daily or monthly users and you can maybe even break it down a step further to downloads or interactions, right? Like, so that's the one way that could tell you, okay.

Over time and as our company or our teams are growing, we also seek growth in the visitors. But also I think, and Joanna, you can talk about this too, but the more self-serve it becomes the more that they're not relying on, like, pings and saying like, who has anybody done research on this or that?

And the more that you see your product teams or your designer engineering teams finding the content on their own, that's when you know. We've been successful and not another way to think about measuring this. And maybe this is more for like research leadership if you know, as part of research planning you know, we can start to think about.

Past research that we've referenced or that we could leverage for this project. And talk about it in your one-on-ones or talk about it as part of your quarterly or half plannings as you go. I think, you know, it, once you start to see that, you know, naturally happening, that's when you know that this tool or this program has been successful

[00:38:13] Erin: Yeah, that's great. I wanted to just close with talking a little bit more about taxonomy, cause I know we've talked about taxonomy this whole time in a sort of passing, but we've got a librarian in here, so I really want to geek out for a minute. You know, when we think about taxonomy of course it has to do with organizing information, naming information so we've got insights, there are different formats.

We've talked about, you know, maybe you have decks or docks or, you know, whatever the format of all these insights is. We're going to organize it into some kind of taxonomy. I imagine this can be daunting, particularly for folks who are maybe not librarians or you know, don't have that depth of experience at the same time.

We're talking about researchers who, you know, certainly part of UX research work. So maybe we have a, actually a really good group of folks to work with when you think about building out a good taxonomy. But yeah, what are some kinds of rookie things, rookie mistakes people make, or on the other side, some ways to get off starting with of course you can make your taxonomy more robust over time.

Get it started in a good place. Any top tips there on, on a kind of starter taxonomy for your insights repository.

[00:39:20] Joanna: Top tips. This is such a good question. And I think it's good to note that you can create a system and you can put your stuff in it. And cool. I did that, but it's not going to be wonderfully accessible unless you really focus on the information architecture of that taxonomy, because that's where the value is gonna come from, that's what's going to make your search and discovery super strong. So even if you don't have a tool, this can be built out beforehand. You can build out a metadata model in a Google sheet. Rookie mistake, free tagging. Sounds like a grand idea. We do it all the time when we use Instagram, it seems great.

But it's actually not that good. You know, it opens up a field or a dataset to allow users to add any tag they want to any asset, any. Just stop that. Cut that out.

[00:40:21] Erin: Well, yeah. And then you get, you probably get like 17 versions of almost the same thing, too, right?

[00:40:27] Joanna: Yeah, so it allows, yeah. So what free tagging does, sounds like it's a great idea. First thought, oh, it's a great way to have everybody add all their assets at once and add all your tags. Cool. It's find-able we're human. We create errors. A lot of misspellings happen, whether we just don't know how to spell something, but through fast typing, I do it all the time.

How many times have we misspelled something by accident and. That Google spelling correction is fixing it for us. These systems may not have that. So opening it up to free tagging is going to have a lot of misspellings. You're also going to get, here's a common thing in UXR. Everyone's going to want to tag their research as UXR or,

[00:41:17] Erin: Right, right, right.

[00:41:19] Joanna: I need to go.

[00:41:19] Erin: Yeah. Yeah.

[00:41:21] Joanna: As you know, all a hundred percent of your assets, that's not a great search. So you really want to, and what I always try to encourage people to do is create a controlled vocabulary, some type of rigid hierarchy of categories. That's been research discussed and agreed upon by a governance group, not just your librarian, but a team of people.

That can be the voice for the larger team to say, this is what we're going to call this thing. And then also have that communication for new concepts, new products. If you're a company that deals in many IPS and products knowing what's being built when those names or language changes over time having that open communication.

When you maintain a taxonomy, staying away from acronyms is probably the hardest thing for new people trying to learn and understand the language of a company or institution that they're working for. Imagine them going into a repository, they're tasked with finding out, learn what we've done on this particular subject.

And there's just a host of acronyms that are used in a variety of ways across a whole company. That's going to get really confusing. So stay away from acronyms, stay away from jargon. You're going to have a lot of people coming in from different backgrounds and other different companies or institutions.

They're all going to be speaking about things in a variety of ways. That means the same thing. That's where your governance team can really take that. Variety or similarity like terms and narrow down and zoom in on one term. And if you have a really awesome tool, you can take all those other terms that are alike or similar and point them to the preferred term.

So that even if you get someone that searches the word cat, maybe your preferred term is feline. Everything is going to surface at once. So yeah, stay away from free tagging, create a controlled vocabulary. It's going to make your search and discovery so much better. For the long term.

[00:43:33] Nada: And I think one other thing that Joanna you and I talk a lot about is, you know, especially if you are in product a lot of product names or features might change over time, or you might have like a secret word for it until it launches—stay away from those too.

[00:43:49] Erin: Yeah.

[00:43:49] Nada: Try to keep it maybe more. Focused on the keywords that you do know about for sure.

Versus what you think people know about. So yeah, definitely. Plus one to everything Joanna said.

[00:44:00] Erin: Amazing. Well, it's clear we could talk for hours about repositories, just a wealth of information. Thank you for sharing all of this with us. Any parting thoughts for folks on repositories that we didn't get to cover?

[00:44:13] Nada: I would, you know, just reiterate the importance of them everywhere you go. Regardless of the team size that you have. Start with just centralizing the content put them all into one place and get in the habit of doing this every time, you have collected insight or feedback and you always are going to have a business case regardless of the company that you're in or the team that you're on there is always a case to have this valuable data in one place that you can share and have others discover it easily.

[00:44:47] Joanna: And, you know, I'm a librarian. So I am going to sing the praises of preserving and curating your content for. You know, for as long as I exist on this earth. So yeah, plus 1 million to organize your content in a way that anybody can access it and discover it, even if you don't have a tool making sure that literacy is baked into your system, that people know the workflow that you're using, whether you have a tool or not.

And if you have a tool, hire a librarian.

[00:45:22] Erin: Good tool, good librarian, good taxonomy. And just do it. Get it centralized.

[00:45:26] Joanna: Makes for happy researchers.