Creating a User Insights Knowledge Base to keep track of research findings

How to create a library of user insights to keep track of research findings and for a better communication of user needs.

Doing user research, like usability tests, user interviews, and surveys, is certainly at the heart of UX, but what happens to all the gathered data once the research is over? My experience has shown me that interacting with a user can be very insightful, but the insights are lost as quickly as they were gained if you don’t have a way to document them in digestible chunks and spread the knowledge. That’s why, together with colleagues, I created a “User Insights Knowledge Base” at my current company Digitec — where I work as a Product Designer for the D3 product family, several software products for FX trading — to spread knowledge about the user across the company, to work more user-centered and to never lose a user insight again. This article will be all about the benefits and how to create a User Insights Knowledge Base.

“A knowledge base is a self-serve online library of information about a product, service, department, or topic.” — Atlassian

This is a quite basic definition of the term Knowledge Base, which can be literally anything. But as the name says, a User Insights Knowledge Base is a knowledge base to group and access all the insights about the users — like their problems and needs — of a particular product. I will tell you more about how to structure the data in it and what kinds of data can live in a User Insights Knowledge Base shortly but first let’s dive into which problems such a knowledge base can solve.

• Break user research findings down into understandable chunks: The result of user research is often a long report, which is partly visualized but generally takes a lot of time to read and understand. The User Insights Knowledge Base is intended to break this down even further and offer small chunks of information — short insights instead of long texts.
• Communication of user needs across departments: in most companies not all employees, for example developers, have (close) contact with customers. However, in order to work in a truly user-centered way, everyone should have an idea of who the product is being developed for. Therefore, it is important to communicate user insights across departments and make them accessible.
• User-centered decision-making: Product decisions should be based on user needs in addition to viability and feasibility. For this, it is important that important user data/insights are easily accessible and present for decision-makers like Product Managers, UX Designers, and stakeholders.
• Communicating the “Why are we doing this?”: when developing a new feature or improvement, it is not always immediately obvious what problem it solves. The User Insights Knowledge Base is designed to make exactly this information available to everyone.
• Getting data out of your head and “onto paper”: it can be fatal for companies if too much data exists only in the heads of employees. If an employee drops out or simply forgets certain information, a lot of knowledge is lost. The User Insights Knowledge Base contains all the knowledge about users and serves as a central location and reference point.

The general concept of the User Insights Knowledge Base is to take as much raw data, which is data from interactions or touchpoints with users — like protocols from user interviews, analytics data or emails from users — into the database and then derive more valuable data from it, like user insights, Personas or an Opportunity Solution Tree — which I will explain further.

Additionally, the User Insights Knowledge Base is kept searchable through keywords for every data point, links to other related data points and other important tags, like for our software the “User-Roles”. Since we have a b2b product family in the foreign exchange market, a user role for us would for example be “FX Trader” or “Trade Support”.

Opportunity Solution Tree

In her book “Continuous Discovery” Teresa Torres describes a technique to continuously discover the unmet customer needs and the solutions that will address those needs. She also invented a form to visualize Continuous discovery: The Opportunity Solution Tree. The goal of the tree is to address customer opportunities that will have the biggest impact on the company’s outcome.

While Teresa Torres’ Opportunity Solution Trees are rather small and have a short life, we decided that it would indeed be a good tool to structure the derived data in our User Insights Knowledge Base to visualize related user needs and to make it easier to find out the need a solution or user request is trying to solve. We changed the opportunity solution tree a little to include a distinction between requests (solutions that the user proposes) and solutions (solutions that we as a company/ team worked out) and we changed the tree top to the user’s role instead of the company outcome.

This Opportunity Solution Tree is the main outcome of the User Insights Knowledge Base. It enables the team to make data driven decisions and to empathize with the user. In our case our main Opportunity Solution Tree (for the role of the FX Trader) has nearly 1000 data points and many layers of opportunities. But it’s important to note that the lowest layer is always the layer of requests and solutions, while the top layer is a single role.

Data Points

Before we get to into how this actually looks like in practical use, I want to dive a little deeper into the different data points we use in the User Insights Knowledge Base:

• Raw data: any data point about the user that is coming into the knowledge base e.g. emails from the support hotline, protocols of interviews, demos or support sessions, other research data or analytics data.
• Opportunity (derived data): User needs, pain points and desires that can be derived from an interaction with the user (raw data). Opportunities don’t need to be specific or related directly to a part of the software.
• Insight (derived data): A loose insight into the user’s work, company internal procedures, or similar insight that should to be documented. (these can be linked to opportunities, but do not follow the same rigid rules as the rest of the tree)
• Request (derived data): A specific (feature) request by a user e.g. “there needs to be a form field where I can type in XY”. It’s important that a request isn’t “read into” something the user said, but only something that is really requested.
• Solution: similar to a request, but a solution for an Opportunity that is proposed internally by a colleague e.g. a developer or a UX designer. A solution can be anything between a vague idea and a detailed plan. Implementation details aren’t part of solutions.

Since Jira is a tool that is already adopted and widely used in the company, we also implemented the User Insights Knowledge Base with Jira. In principle, however, the basic concept presented here can also be implemented in any other tool.

Issues Types and Links

Each data type (Opportunity, Insight, …) is represented by a custom Jira Issue Type. For Raw Data, we have also created the data types relevant for us as issue types, currently these are protocols and emails, whereby we summarize different types of “data generation” in protocols, for example, we write protocols for user interviews, demos with customers or support sessions.

The different tickets are then linked to each other by custom links — whereby the link type also represents the relationship between the tickets and is later used to generate the opportunity solution tree.

The “arises from” and “is cause of” link is used to establish the connection between Raw Data and Derived Data. In addition, it is also used to express whether a raw data point is for or against a Solution (Request or Solution) (“arises from” vs “is opposed by”).

Opportunities are linked to each other with a parent-child relationship. Insights can also be linked to Opportunities using the same link. Additionally, Solutions and Requests are linked to Opportunities using the link “tries to solve”/ “might be solved by”.

Additionally, there are links to the development tickets (a ticket type that already existed before the creation of the User Insights Knowledge Base, which are used and edited by developers, product owners, etc.). The resulting relationships make it possible for software development to easily access the user insights knowledge base, for example, to understand why a particular feature is built and what user problem it solves. Importantly, only Solutions and Requests can be linked directly to development tickets, forcing a process in which multiple solutions to an Opportunity are first found and considered before a final decision is made on a Solution.

Another development ticket type that is directly integrated into the opportunity solution tree is the feature ticket. This is represented in the tree as a child of an Opportunity and can itself have children (Opportunities, Solutions and Requests). This should make it easier to identify user problems that are specifically related to a feature of the software.

Issue Fields & Custom Metrics

A Jira ticket (= data point) has different fields that are filled either manually or automatically.

As manual fields, all data types have the mandatory “title” as well as keywords. Raw data additionally have the field “Customer ID” as well as their actual content (the protocol, text of the email, screenshots, …). Opportunities are always assigned to a role. Moreover, they have some rules for the name: they are always written in first person and usually start with “I want to” (“IWT”), “I need to” (“INT”), “I have to” (“IHT”), “I don’t know” (“IDK”) and “I don’t understand” (“IDU”). Solutions and Requests always have a description that is supposed to describe the solution but doesn’t go into implementation details. Additionally, they have the field “Implementation Decision” which can be “Yes”, “No” or “None” (= no decision is made yet).

Automatically generated fields are available for the derived data types (Opportunity, Request, Insight and Solution). They go through the links and display the following data:

• Raw Data Count: the number of raw data that is linked (“arises from”)
• Raw Data Count inherited: the number of that is linked directly or to any child-node (“is child of”/ “might be solved by”)
• Unique Customers: all the Customer IDs from the linked Raw Data (“arises from” link)
• Unique Customers inherited: all the Customer IDs from the Raw Data that is linked directly or to any child-node
• Unique Customer Count: the number of different customers of the linked raw data (= the counted unique customers)

These metrics can also be used in search and can for example contribute to prioritization.

Opportunity Solution Tree in Jira

The Opportunity Solution Tree can be automatically generated by the links set in Jira using the Structure feature.

To create the structure, the Automation feature was used, whereby tickets are grouped by role and then ordered by the links (“is parent of”, “is implemented by” and “might be solved by”). The parent nodes can each be expanded until the lowest level is reached.

Ticket transitions/ workflow

All the raw data tickets first go into the “Inbox” there they wait to be looked at — by a single person or our weekly User Insights Knowledge Base meeting, where we derive data together. Once that is done, they go to “Done”.

Requests and Solutions have the states “Inbox” (= we need to talk about this Request/ Solution), “Todo” (= somebody is working on it and the decision if this is to be implemented is still open) and “Done” (= a decision has been made and the solution will now be handed to further specify it for development). The workflow of Opportunities is a little more complicated and shows our general product discovery workflow:

• Inbox: the Opportunity is to be discussed in the weekly Inbox meeting.
• Todo: The Opportunity is open and ready to be taken up by someone (a Product Owner or UX Designer).
• In Progress: Someone has taken the Opportunity and is working on the problem and solution space.
• Wait for Evidence: A solution has been worked out and handed over to development. The Opportunity is now waiting to be evaluated by user feedback (to determine that the problem has actually been solved).
• Done: Enough feedback has been gathered and the problem proved to be solved.