Experience Recommendations - Security Policies FY24-Q4 - Onboarding New Policy Creation
- UX Scorecard Part 1: #2437 (closed)
Opportunity | Recommendation | Comments | Insight Issue | |
---|---|---|---|---|
1 | Each card has a lot of copy to read and try to understand. | On the Policy selection screen, it could be nice to add some quick, keyword type of words to the cards that simplifies the parsing of what each card's copy means. E.g. Card1 is for the MR stage, or before merging code. Card2 is for any non-MR stage scans (i.e. anytime desired). | This isn't a huge deal, overall the copy is pretty good. | https://gitlab.com/gitlab-org/gitlab/-/issues/438187 |
2 | Not enough explanation or assistance when completing the policy form. | Add the ability to educate users as to what each option allows them to do. Doc links, or maybe a Help drawer that walks the user through set up, displaying a subset of the help documentation. Just enough to help them complete the form. Would also be good to add a direct link/button to help docs for more details if you're not going to add the drawer idea. | I think this would be helpful for any user level. | gitlab#438297 |
3 | Inconsistent menu patterns | When selecting from the Choose approver type menu, the selected options are removed from the menu. This is different from how the other menus work with showing checkmarks next to the selected item(s), while remaining in the menu. These should be the same. |
This difference was a bit jarring when I went to change my selection. | gitlab#438298 |
4 | Strange disabled menu option behavior | When viewing the Add new criteria menu, the new age item was disabled, but still clickable. It also wasn't clear how to enable it. We should figure out a way to make it unlickable while also communicating to the user what they need to do to enable it. |
It's possible that this is a technical constraint that is forcing us to make it clickable, but this is a strange behavior for something that is disabled, yet clicking it does nothing. | gitlab#438299 |
5 | The Logic error alert is sparse in explanation | The explanation could be more clear as to what it’s trying to communicate. There’s space to add a little more explanation here. | I think it's hard to wrap your head around what is being explained because it's using the same word twice (i.e. Approvals/approvers). | gitlab#438301 |
6 | During and after MR creation, it's unclear what's happening/happened. | Add some sort of success information that lets the user know the policy was created, or move them to the Policies page where they can see it was created successfully. | Could add an alert banner or some copy to the MR's description that explains what's happening (i.e. why is the MR needed), what will happen next, how long it might take for the policy to appear. | gitlab#438302 |
7 | When viewing the Policies page right after creating a new policy, it takes a while to appear. | Recommend adding some success information that lets the user know the policy was created and will appear soon. | Because it takes a min or two for the system to propagate newly merged items, it would be good to communicate to the user. | gitlab#438305 |
Experience Recommendations Checklist
Learn more about UX Scorecards
-
Add this issue to the stage group epic for the corresponding quarter's UX scorecards. -
Brainstorm opportunities to fix or improve areas of the experience. - Use the findings from the Emotional Grading scale to determine areas of immediate focus. For example, if parts of the experience received a “Negative” Emotional Grade, consider addressing those first.
-
Create an issue for each recommendation using one of the Actionable Insight templates in the GitLab project, depending on if it relates to a product change or needs more exploration. Alternatively, you can create a separate epic to hold all your recommendations. Add a UX scorecard-rec
label to every issue or epic for traceability. To help with prioritization, add a severity label to communicate appropriate urgency and impact to the experience. Link to the epic or issues here.- Recommendations do not need to be documented in your Dovetail project.
-
Think iteratively, and create dependencies where appropriate, remembering that sometimes the order of what we release is just as important as what we release. - If you need to break recommendations into phases or over multiple milestones, create multiple epics and use the Category Maturity Definitions in the title of each epic: Minimal, Viable, Complete, or Lovable.
Edited by Justin Mandell