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.

UX Collective
A laptop display showing the tree structure of the User Knowledge Base and a iPad with a graphic. Both will be described below.

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”.

The graphic shows a funnel of raw data going into a database icon with the text “user insights knowledge base” and a funnel going out of it with derived data and examples like “Opportunity Solution Tree” and “Personas”. A magnifying glass points to the database in the middle with the text “Searchable via tags like keywords, userroles and applications or links to other data points”.

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.

A tree structure with “Outcome” at the top and two levels of “Opportunities” as children the leaves (on the lowest level) are “Solutions”.
Opportunity Solution Tree by Teresa Torres

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.

A tree structure with “Role” at the top and two levels of “Opportunities” as children the leaves (on the lowest level) are “Solutions” or “Requests”.
Modified Opportunity Solution Tree for use in the User Insights Knowledge Base

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 graphic shows the link structure of “Raw data”, “Opportunities”, “Insights”, “Solutions” and “Requests” in Jira that will be described further in the text below.

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”.

The same graphic of the Jira links with another level added above the User Insights Knowledge Base related tickets: Development Tickets like Epics and Improvements. Development tickets are linked to Requests and Solutions with the link “targets” (or “is targeted by”). And Feature tickets are linked with “implements” or “is implemented 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).

The screenshot shows the custom metrics like “raw data count” described below.

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.

An example screenshot of the tree in Jira. At the top is the Role “Trader”, which is a category/ label in Jira, underneath are opportunities in the tree structure. The one at the top is “I want to provide accurate prices without interruption”, children of it are Opportunities like “I want to customize my working environment” or “I need to price the currencies I am responsible for”.

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:

The workflow has 5 stages. From “Inbox” a ticket can only be moved to “todo”, from “todo” it can go to “in progress”. From “in progress” it can either be moved back to “todo” or forward to “Wait for evidence”. From “wait for evidence” it can go back to “todo” or “in progress” or be moved to “done”.
  • 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.

Read the full article here

Leave a Reply

Your email address will not be published.

Google I/O 2023 Will Highlight Generative AI and Ignore Google Assistant

Google I/O 2023 Will Highlight Generative AI and Ignore Google Assistant

on May 9, 2023 at 3:00 pm Google I/O this year promises a lot of focus on

Have you considered designing your own life? | by Ankita Gupta | May, 2023

Have you considered designing your own life? | by Ankita Gupta | May, 2023

Applying product design principles to design your life: A structured approach to

You May Also Like