Improve project dashboard layout: usability, visual prominence, and data optimization
Problem to solve
Layout: the 1 column layout restricts the addition of new items, as new objects are stacked on each other. This causes the most important data, the vulnerability table, to be less visually prominent. Objects that interfere with vuln table prominence are: possible info banner, latest pipeline object, and the vuln # blocks.
UI copy: the page name “security dashboard” isn’t clear enough in describing the content. In a recent usability study, we saw that users would often call the vulnerabilities in the table “issues”. Consider the next steps/task for the user would be to “confirm” or “dismiss” or "create issue" - having the objects thought of issues, may confuse this intended workflow.
Clarify data source: Dependency list and license compliance have a header and subtext, that includes the latest pipeline ran data (to clarify when data was last collected). This data is displayed in the project dashboard but displayed differently/inconsistent as the header/subtext seen on the other pages (LC and dependency list). Additionally, it is not clear what scans are providing the vuln object results. If the user applies the filters: UI allows you to filter by a certain scan, but that scan type may not be configured.
Current UI view
Intended user
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sam (Security Analyst)
Proposal ideation
Optimize the layout to surface the most important data with a clear visual prominence. Using a 2 column layout will open space for new data and optimizes data that can be displayed in the viewport. Show summary results in a more dense format for easy reading and space optimization
Add clear headers to clarify the table row objects. Leverage the header and subtext pattern seen on the dependency list and license compliance to make it more clear when the data was last updated. Additionally could use the text “Reported vulnerabilities” to explicitly state the inherent status of the vulns. Consider user needs to selected status, such as “confirmed” - explicitly stating "reported" establishes as baseline status and helps clarify the objects further.
Layout review: 1. Header clarifies i) what the objects are, ii) where the object results came from, iii) when the objects were last updated. Anchors: ? to documentation, “Latest pipeline” to pipeline page, “X security scans” to the configuration page, 2. Vulns prominence display objects at the top for data prioritization and optimization to display as many as possible in the viewport (data density), 3. Aside displays summary data (vulns count); can also display notification messaging (instead of banner) and future data points |
View with side drawer consideration(only to consider future possibilities) here the user can navigate from vuln-to-vuln without having to go to an object page (quick summary/action view). The layout helps achieves this with a smoother interaction with an overlay on 2nd column vs degradation of 1 column objects |
|---|---|
 |
 |
What does success look like, and how can we measure that?
- User describes the table objects as vulnerabilities
- User is able to identify what the source of the data is (per security scans)
- User is able to identify when the data was last updated
- When user describes the page, the first thing noticed in the vulnerabilities