Research insights are the collective findings and learnings that come from a research study.
At GitLab, we measure the impact of our research by:
Informative insights help us learn about something or someone and don’t result in immediate action. Instead, these insights help build knowledge about our users, industry, competitors, and so on. For example:
When documenting informative insights, no special actions or processes need to be followed. These simply get documented into Dovetail, per the standard process.
Actionable insights always have a follow-up action that needs to take place as a result of the research observation or data, and a clear recommendation or action associated with it. An actionable insight both defines the insight and clearly calls out the next step. For example:
Users weren't able to submit a merge request in the proposed design because they couldn't find the “Submit” button. They expected it to be located at the top of the page. Action: Iterate on the design to relocate the 'Submit' button to the top of the page and retest (link to Issue # XYZ).
IT Admins want a way to view all of their teams' activity over time, in 15 min increments. IT Admins are being asked to report on this information as part of a new company policy. Action: Explore the feasibility of such a request (link to Issue # ABC).
When creating an actionable insight issue to propose a change to a feature or product area under use, be cognizant of the wider impact of the changes on the top JTBDs associated with that area. If the data backing the insight does not provide enough confidence in the highlighted problem, take additional measures to validate it.
Actionable insights need to be handled differently than informative insights. Actionable insights are tracked over time and will include follow-up, so document actionable insights in Dovetail and in GitLab as unique Issues.
When you document an actionable insight, its three main components are:
Tips for writing an actionable insight:
To document actionable insights:
Actionable Insight::Exploration needed scoped label.Actionable Insight::Product change scoped label. Note that the SUS label and a severity label are both required for actionable insights that require product changes.Both templates use a corresponding scoped label (above) to keep track of the progress being made regarding next step(s). To streamline this process, add a link to the Dovetail insight in the GitLab issue, rather than typing out all the details again. (If you want to include details, you certainly can.)
Group (such as ~"group::source code") label to the issue. This is done to identify and track actionable insights at the group level.Actionable insights are created and managed by the person closest to the research, which is typically the Product Manager, Product Designer, or UX Researcher. However, it’s ultimately up to the team to decide who manages actionable insights.
All discussions and decisions made about the actionable insight must be documented within the issue, because these issues are tracked as performance indicators. As we track actionable insights over time, it’s important to understand what kinds of decisions we’re making based on user research.
When closing an actionable insight issue, it’s important to document why it was closed and whether the original action was acted upon.
In some cases, no action will be taken for a number of reasons, such as low priority, too large of an effort, not technically feasible, and so on. Regardless of the reason, document the decisions in the issue when closing it.
Both Problem Validation and Solution Validation need to follow the actionable insights documentation process if actionable insights are discovered. For example:
The above examples have one thing in common regardless of the kind of research: the insight is actionable, and therefore, must be documented as such.
Additionally, UX Scorecard testing can yield actionable insights. Since UX Scorecard testing is an expert review and/or heuristic evaluation, creating Dovetail insights may not be applicable. Instead, be sure to document the details in the GitLab issue using the actionable insight template in GitLab.com.
We label issues containing insights identified through customer calls differently than other insights, because they don't directly relate to UX research efforts or tracking. For issues that contain insights derived from customer calls (or other customer support channels), please use the Customer feedback label.
Actionable insights are tracked at GitLab for:
The proposed data that will be tracked and possibly measured in the future:
Actionable Insight::Product change and Actionable Insight::Exploration needed scoped labels
Actionable Insight::Product change and Actionable Insight::Exploration needed scoped labels, both closed and open, across the total number of research studies conducted