Solution validation: inline alerts in the MR
What did we learn?
| Results |
|---|
The top actionable finding was that users unfamiliar with GitLab struggled to know where to filter the inline findings. The top informative findings were 1) Users familiar with GitLab will have no problem noticing and interacting with the inline findings and 2) participants unfamiliar with GitLab were confused on the difference between Start a review and Add a comment in the MR comment. Overall, there was a lot of praise about the feature and it received a 6.14 out of 7 rating on a scale of how useful users (all software developers) see this feature being in their workflows. |
| Link to Dovetail project |
Problem to solve
Code quality built a backend functionality to add inline findings in the MR diff. SAST and Secret Detection want to show inline vulnerability findings as well, but we need to make sure that the proposed designs are validated with our primary persona, Sasha, Software Developer, first.
-
Potential positive impact: Developers (the target persona) can triage findings from within the MR diff contextual to the code being introduced, rather than remembering or needing to look at the widgets in the MR overview tab
-
Potential negative impact: These inline findings create too much noise from an already busy area of the UI, creating confusion and a poorer user experience, contributing to an already falling SUS score.
User stories
-
As a developer, I want to see detected security vulnerabilities in the context of my code so that I can triage them (in addition to code quality issues) in the same place and without disrupting my workflow.
-
As a security engineer, I want to encourage developers on my team to triage their own vulnerabilities so that we can shift left and empower them to prioritize application security without adding additional time or effort to their workflow.
Steps
-
Look at prior research from Vulnerability Management (Dovetail) (if any) -
Create research script -
Include links to prototypes into script -
Create Google doc for notetaking -
Recruit at least 5 internal participants and book times on calendars for synchronous research sessions -
Complete internal solution validation testing -
Collect and analyze research insights -
Iterate on designs (V2) -
RITE testing internally V2 -
Internal feedback and iterations with team (see Reconsider the UX of interacting with Vulnerabilities in the MR) -
Complete external solution validation testing (UserTesting.com or FirstLook) -
Create Dovetail project with insights -
Communicate insights with Secure and UX teams
Related links
cc @pedroms @phikai @tmccaslin @gitlab-com/gitlab-ux/secure-protect-ux