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?
- Is the kanban style layout a preferred and useful UI?
- 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?
Status: finalized recruiting and most interviews (notes/recordings here). Next steps: debrief and analysis