Solution validation: alerts workflow
What’s this issue all about?
In gitlab#219436 (closed), we introduced an MVC to display alerts in the UI. In follow up iterations, we are including: alert details, status, and ability to create issues.
Users will be able to move Alerts through the following status states:
graph TD
A(Unreviewed) --> B
B(In Review) --> C(Dismissed)
B --> D
D(Confirmed) --> E(Resolved)
In the above unreviewed
are newly detected activity/alerts being displayed and the user may dismiss it (likely for a false positive) or move it though the process of unreviewed > in review > confirmed (or directly to a certain status). These steps are aimed at helping the users investigate and take action toward an alert as/if needed.
Who is the target user of the feature?
What questions are you trying to answer?
- Where do users navigate to, to view alert activity?
- Do users know why an alert is being displayed?
- Do users know how to set an alert?
- Do users understand the workflow (status)?
- Can users change the workflow status?
Core questions
- Is the kanban style layout a preferred and useful UI?
Additional questions
- What users current workflow looks like today?
- How much time do they dedicate to reviewing new alerts?
- What painpoints do they have with this workflow?
- How might the proposed UI help? or regress their workflow?
What hypotheses and/or assumptions do you have?
- Most users spend 3-4 hours daily investigating/remediating new alerts
- The kanban workflow (and prescribed statuses) will help optimize alert management
- Users may want to create custom statuses
What decisions will you make based on the research findings?
- Moving forward with the kanban or table style layout
- Improvements to the workflow layout
- Edit or keep same names of status
What's the latest milestone that the research will still be useful to you?
Conclusion
Interview tags, notes, and videos found here.
Informative insights
- Identified alert policy (p: 1, 4, 5, 6, 7, 8): users identified alerts as policies and/or violations.
- Understand and use status as triage process (1, 4, 5, 6, 7, 8): users identified the alert UI and related statuses as a workflow. There wasn’t any mention of changing the status, nor notable confusion of the status names and related meaning.
- Environment-selection (5, 7): most users understood the display was per environment, and a few users alluded/noticed the filter to change.
Actionable insights
-
Users want to create an issue (1, 4, 5, 6, 8): most cases users indicate as a first step would be to create an issue to discuss and document with the team. Primarily desire related to true-positive alerts.
- issue: gitlab#275994 (closed)
- User wants to be able to assign or know who made changes (1, 5, 6): when changing statuses or related activity (such as creating issues); overall, users want a log of what actions were taken and who took the actions toward an alert.
- issue: gitlab#275995 (closed)
-
Users want to add a comment/feedback to alert status change (4, 5, 6, 8): this primarily focused around false-positive alerts; users were hesitant to
dismiss
a false positive, without being able to comment and/or document why the dismissal was made.- issue: gitlab#275998 (closed)
Edited by Kyle Mann