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).
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 label to keep track of the progress being made regarding the 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.
Actionable insights are tracked at GitLab for:
The proposed data that will be tracked and possibly measured in the future:
Actionable Insight label
Actionable Insight label.Actionable Insight label, both closed and open, across the total number of research studies conducted