Error Tracking Viable - Discovery
Overview
Error Tracking allows GitLab to receive and act on application errors. This product offering is based on an integration with Sentry. The current implementation is minimal
. As we mature this category to viable
we will be focusing on how we can improve and streamline the workflow between GitLab and Sentry, to allow users to more easily work with and interact with errors.
Goals
Identify, define, and understand the customer problems we want to solve next as we mature Error Tracking from minimal to viable in FY20Q4
Deliverable
- Complete opportunity canvas
- Epics/Issues created for each problem
Discovery Plan - Problem Validation
-
Fill out opportunity canvas -
Create customer interview guide (i.e. draft questions for interviews) - here is a good guide -
Submit research request to UX research to recruit interview participants (GOAL: 5-8 participants) -
Send email invites to interviews -
Schedule at least 5 interviews -
Customer Interviews -
Interview internal customers asynchronously on this issue to answer questions (GOAL: 5 responses) -
Interview external customers synchronously (GOAL: 5 responses)
-
-
Synthesize research findings using affinity mapping or other technique -
Update/refine opportunity canvas -
Review opportunity canvas with Product and UX leadership If approved -
Create epics/issues -
Review plan/roadmap with Sentry
Customer Interview Guide - DRAFT
External
- What is your role and title at your company?
- What would you say your main responsibilities are?
- Do you use GitLab? If yes, in what capacity?
- Do you use error tracking tools as part of your work? If so, which one?
- Can you describe how you use {INSERT ERROR TRACKING TOOL}, under what circumstances, and how frequently?
- Can you walk me through a typical workflow using {INSERT ERROR TRACKING TOOL}?
- What parts of these workflows do you find valuable? unnecessary?
- Are you able to check if your code is causing errors before it hits production?
- How do you learn about critical errors that you need to fix?
- What information in an error or stack trace are most important? what information is not important?
- When you find an error you need to fix, how do you track the work and closing the error?
- Do you find yourself moving back and forth in between GitLab and {INSERT ERROR TRACKING TOOL} often?
- Are you on-call?
- Have you worked with any other error tracking tools at previous jobs?
Internal
- Can you describe how you use Sentry, under what circumstances, and how frequently?
- Can you describe your typical workflow using Sentry and GitLab?
- What parts of these workflows do you find valuable? Unnecessary?
- Are you able to check if your code is causing errors before it hits production?
- How do you learn about critical errors that you need to fix?
- When you find an error you need to fix, how do you track the work and closing the error?
- Do you find yourself moving back and forth in between GitLab and Sentry often?
- Are you on-call?
- Have you worked with any other error tracking tools?
References
- Link to UX research issue
- Link to Screener for recruiting interview participants
- Link to discussion guide
- Link to User Interview Notes
- Link to issue discussion about processes for Error Tracking
- Link to Opportunity Canvas
Easy opportunities to start with
- Allowing users to perform actions on items in the list view (would be good to define which actions are most useful to users)
- Allowing users to create issues/incidents out of errors
- Allowing users to click into list items for a more detailed view of individual errors