A pragmatic approach to building an insight repository
Have you been thinking about building an insight repository? Have you tried to see through the forest of available tools, and wondered which one is best for you and your company? I talked to people and read articles. I couldn’t find any clear answers on which tool I should use.
This is how I focused on mapping the needs, methods, and structure before considering a tool. And built one within the existing toolkit.
The start point
When I started working on this project quite a lot of user research had been done, but it wasn’t stored anywhere specific. It was hard to have an overview. This probably sounds familiar. You have to ask around to understand what has been conducted, and then ask to see the report if it exists.
Do I need to choose a tool first?
The need for transparency and one place to look for it was imminent, but how should I start? Looking through articles and information about this topic was more often than not connected to a specific tool to do the job. Often published by a company selling a tool. And most of the tools are very expensive.
If we chose the tool that seemed to be closest to what we thought our needs were, what if we found out that it didn’t suit our needs after all?
The risk of possibly spending hundreds of dollars and many hours setting up something that didn’t cover our needs was a bit terrifying, to be honest.
Another thing to consider here is introducing yet another tool to the organization. Will it be used? Will they remember that it exists? Seeing beyond that it has a cost in mere money, it might have a cost of being hard to access causing it to be less used by everyone.
What are our needs?
So I focused on mapping out the needs. What do we need, and how could a structure look like seeing beyond the tools? Our champions at Norman Nielsen Group have a great starting point.
Also, this article from Sameer Behere, has great points about what you should consider when creating an Insight Repository.
The most important thing to remember is that the structure has to make sense to those who read the insights. The users must easily recognize and understand the key takeaways. No matter the entry point and profession.
I boiled it down to this:
- It needs to be easy to find insights
- It needs to be easy to understand the insights
- It needs to be easy to record and store new insights
How do we structure the insight repository?
A potential trap in this part of the process is including too much. We should decide what makes the repository, and what we can leave out. Starting small with the core insights is key, enabling iterations on the repository to get it just right.
Building it from the ground
Simultaneous work with the structures of the repository and the insights we also created a proper tree structure for all our files. It must be easy to see the method, topic, and date. Getting this right will help other ways to get to the insights.
A good start is to collect and store all available insights and start building a tree structure on your computer. Iterate and test the structure and naming conventions together with your team. Doing this groundwork allows you to be flexible with the content and the structure and create a common ground.
Create a structure for the insights
We looked at the different ways of reporting the insights and iterated with the teams and main stakeholders mapping out best practices for reporting.
The guiding star for this work was the three points highlighted above. Making it easy to find, understand, conduct, and report user insights. And above them all how we present the Key takeaways.
Different methods need specific structures for reporting. The various methods are also often conducted and reported on by separate teams. Setting up a structure for each method means setting up guidelines.
Create templates for everything
To have a consistent structure we need to create templates for everything. Making basic rules and templates for everyone to harvest, report, and share the insights.
Establishing a structured and set way of conducting and reporting user insights will guide and help everyone on the team maintain consistency. And it is really helpful for new members joining the team.
The key takeaways
Video is king. Video over text if possible is always more efficient. Easier to share on the different internal channels and great to present in meetings. This format also helps the team leads present it to their stakeholders, and share it further in the decision chain. Win-win.
Also, think about how the takeaways are presented in your written report. Always use clear and easy-to-read sentences.
Even when you have a video recap, you should continue the report with a “one-pager” with the key takeaways — an Executive summary if you will — making your report search optimized.
So how do we store it?
As I mentioned we read a lot of articles and talked to a lot of people about possible solutions to start up a space without spending money and much time. We were looking for a solution that could handle iterations as we better understood our needs.
Confluence
One solution came from a colleague at Forte who used a separate Confluence space to create something similar for a different client. The use case was not the same, but the tool had lots of positive functions.
A confluence space, or a team space, is completely isolated. This allows for the content to be easily searchable. In addition, you can add tags, and use the folder architecture to organize the insights per method per period.
This tool already existed with the client and we could get a hold of it almost immediately. This was a great starting point for exploring our needs.
Teams or Sharepoint as an alternative
A different option could be Teams or SharePoint. Most companies have Microsoft licenses and store their information and files here. Creating a separate Team in Teams will also help you start gathering and structuring your user insights in a tool that is available to everyone.
Goal completed!
Now everything is in one place. Transparency is established.
But the work doesn’t stop there.
An insight repository needs to be nurtured…
If we don’t keep it fresh and nurture the insight repository it will become a dinosaur. And that can happen quickly. It needs to be updated; new insights must be stored as decided, and outdated information must be removed.
This demands ownership and responsibility from the team.
…and iterated on constantly.
The insights must be relevant and dated to be the go-to place for anyone interested in the insights we gather. If the products or services change it should influence or dictate how our repository is structured.
Share your insights!
So you have insights. The insights are structured and easy to digest. But does anyone besides your team know it exists?
Use the internal channels
Most companies have internal channels where they share internal information and news. It could be an intranet of some sort or maybe a Workplace, or a Teams channel.
This is a great place to showcase your findings and link to your insight repository.
Spread the gospel of your Insight Library’s existence!
Talk about the insights and library in meetings, around the coffee machine, share the links, and mention it to the right people at the right time.
If you don’t have any regular internal gatherings to talk about and share the latest knowledge, then you should work towards creating them.
The knowledge of the insight repository should even be part of the onboarding process for new employees. All new employees!
One source of truth
Having one reliable source of truth for all the relevant user insights will benefit everyone.
No matter the tool.
