Feature Discovery Pattern Improvement

Description

Within the Secure section, there is an increasing need refine and consolidate our feature discovery patterns so that we can better signal to the user the alerts and actions they need to take. There are two parts to this problem currently:

  1. Inconsistent use of the feature discovery patterns. There is an over-reliance on the banner pattern to communicate important information, which leads to stacked banners with differing levels of importance. Screenshots attached below
  2. Stacked banners. Given the large volume of information being conveyed to users through the feature discovery patterns, we need to refine and consolidate how many notifications get presented on the page and explore a variants of our current feature discovery patterns to allow for multiple features/ notifications.

image__1_

image

Next Steps

Step One: Define a clear hierarchy of what type of information gets what type of feature discovery pattern. Security information, system information, status/ timestamp information, new feature announcement, and configuration enabled/disabled CTAs are not all at the same level of urgency. Define a clear hierarchy around what information gets what type of feature discovery/ notification, and what type of information should be removed from these notification methods entirely and embedded on the page.

Examples:

  • Timestamps/ statuses may not need to be conveyed through a feature discovery pattern, and could instead be directly embedded on the page at all times
  • Enabled/ disabled scanner configurations may not need to be displayed as banners at all. How might we improve that experience?

Step Two: Explore notification consolidation patterns. There is an existing issue related to better report notifications, as they relate to the Vuln Report pages. The linked ticket outlines use cases for notifications within those pages, but this pattern improvement should be applicable across all parts of the Sec experience.

Post Design Proposal Checklist

Make sure the following are completed before closing the issue:

  1. Assign the correct component label to this issue.
  2. Create an MR with the additions or updates needed.
  3. When applicable, create an issue using the Figma update issue template to update the component in Figma, and mark it as related to this one. Bring the issue to your team planning session for prioritization and scheduling.
  4. When applicable, create an MR in GitLab UI to update the component. If you do not have capacity or are unable to update the component directly, create a GitLab UI issue using the Component issue template. Mark the new issue as related to this one. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
  5. When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
  6. 🎉 Congrats, you made it! You can now close this issue.
Edited by Marissa Henri