Creating a User Insights Knowledge Base

In the rapidly evolving landscape of user experience, understanding users and their needs is crucial for driving product success. Digitec, a B2B software company operating in a niche market, faced unique challenges due to limited user interaction and a lack of accessible user knowledge across departments. To overcome these obstacles, the User Insights Knowledge Base project was undertaken, aiming to establish a centralized repository of user insights and foster collaboration among teams. This article presents a detailed case study that highlights the projectʼs approach, including a workshop-inspired Design Sprint, the implementation using Atlassian Jira, and continuous improvement through testing and iteration. By delving into the projectʼs objectives, methodology, and outcomes, this article showcases the value of a user-centered approach in driving informed decision-making and promoting cross-functional collaboration within an organization.

Project Approach

Why create a User Insights Knowledge Base?

Our goal of creating the User Insights Knowledge Base was to solve several problems we had (especially as the Product Management team). As a b2b company with a software in a niche area, Digitec has a few specific problems connected to the fact that we only have a handful of users per customer. This also limits the contact to the users and before the introduction of the User Insights Knowledge Base, many employees did not have sufficient knowledge about users. This has resulted in two primary problems:

• decision-making without (real) data
• a few colleagues have knowledge about the users that wasnʼt accessible for other colleagues

Design Sprint to create a Concept

We decided to do a workshop to create a general concept for the User Insights Knowledge Base. There were several reasons, why we did a workshop and not just worked out a concept by ourselves:

• getting the buy-in of several stakeholders outside the team that would need to collaborate in the future (because they are people with customer contact)
• including the expertise of different people (from different backgrounds and departments) into the concept
• finding a good solution by deeply understanding the problem and evaluating different solutions

The workshop was strongly inspired by Design Sprints and was done with 6 participants: 2 persons from Product Management, 2 UX Designers, 1 person from the Support team and 1 person from Sales. I planned and moderated the workshop together with a colleague.

Screenshot of the workshop timetable in Miro: on the first day the Empathize phase took place, including different exercises, and was followed by the Ideate phase on the second day. I will describe both phases in detail below.

Empathize

After a little intro including the current problems we saw in the company as well as a definition of the term Knowledge Base and telling the participants about the workshops goals, we started with a mix of the Empathize and Define phase of Design Thinking, which are all about understanding the problem and building up empathy with the user (which in this case was us as users from different departments).

We first did Expert Talks where we interviewed a person from Product Management and another one from Support about their daily work and their requirements. While listening to the interviews the participants wrote down notes as How Might We Statements - short statements starting with “How might we“ like “How might we make visible where problems for users exist?“. We then read through all the notes and grouped them with headings like “Quantifying problems“, “Workflow of the teams“ or “Benefits of the User Insights Knowledge Base“.

The next task was to define a Long Term Goal for the User Insights Knowledge Base. For this every participant wrote down 3 goals imagining a ideal world in 2 years. Then we voted for one goal, which was:

Our next task isnʼt a part of a usual Design Sprint. It was a short brainstorming session where everyone wrote down all the possible data or touchpoints with customers that could go into the knowledge base, like events, support requests, software demos, training sessions, log files, user analytics, surveys etc.

Afterwards we did User Journey Maps. In this case we ourselves are the users of the User Insights Knowledge Base, so we created a map with 4 different users: Support, Sales, UX and Product Management and brainstormed about their goals and mapped their workflow. Then we marked steps where either data could go into the User Insights Knowledge Base or the insights in it would be helpful for our work.

The resulting user journey maps from the workshop. Red rectanges: data comes into the User Insights Knowledge Base, green rectanges: data from the User Insights Knowledge Base is used. “UKB” is an abbreviation for User Insights Knowledge Base.

Ideate

Since ideation is better done alone - because group dynamics can lead to having worse solutions - all the participants got the “home work“ to come up with a solution.

In the second part of the workshop we came together to discuss the solutions by the participants and come up with a final solution. Every workshop participant got 10 minutes to present their concept to the other participants and to answer questions. Afterwards we did a Dot Voting on the different solutions and parts of it. And finally we took the parts we liked and put them into a final solution, that I will present below.

Screenshot of the Miro-Board that was used in the workshop

Test & Iterate

After creating the concept, we implemented it using Atlassian Jira. Now it was time to test the concept. For this we set up a weekly "UKB Inbox"-Meeting (UKB is our abbreviation for User Insights Knowledge Base), where we went through data together to get a feeling for the process and work with our concept. After a few months we then did a Retrospective to get feedback from all the colleagues working with the User Insights Knowledge Base and continuously improved it. A few improvements we did over time:

• Introduction of automatically generated metrics (described below) to make the data easier comparable
• Including (already existing) Feature tickets into the Knowledge Base to improve the sometimes existing connection between user needs and existing Features

Theoretical Basis

Theoretical concept

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 below).

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.

On the first level are Outcomes, these are business outcomes that describe the business needs of the company. Below it are Opportunities on as many levels as needed, therefore one Opportunity can be the child of another opportunity and so forth. On the lowest levels are Solutions. We adapted the Opportunity Solution Tree as the main outcome of and as a structure for our User Insights Knowledge Base. For that we switched the Outcomes to our User Roles, which now form the head of the tree. Additionally, we included (Customer-) Requests on the same levels as the Solutions, since both describe possible solutions to an opportunity.

The Opportunity Solution Tree 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 dive 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.

Realization with Atlassian Jira

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 many other tools.

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 team 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 raw data that is linked directly (“arises from”) 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”)
• 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 in Jira using the Structure feature and the links between the tickets.

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.