L-B.

The user

Vulnerabilities are an inherent part of the compliance equation, but they’re also very technical and require external management. Because Drata is a holistic compliance tool, customers want to see an overview of their organization’s vulnerabilities without addressing them. For larger customers this is especially relevant as the Drata user is a compliance manager while the person dealing with vulnerabilities is more technical in nature.

The role

As the sole designer from inception to release, I was able to represent the user along every step of the way from initial discovery all the way to release. Starting on the project while being unfamiliar with the technical data and its usage, I had to do enough background research to separate the Drata user needs from that of a technical user.

Background research

Firstly, I gathered as much information as possible through customer call transcripts and Productboard feature requests. I also broke down data such as vulnerability ID and resource ID through directly observing AWS Inspector data in Drata’s own dashboard (stock screenshot provided for privacy).

Opportunity solution trees

Based on my research, I created an opportunity solution tree to segment different problem subspaces and their respective solutions. Primarily, I focused on two use cases:

• Reactive vulnerability management: dealing with vulnerabilities already in a critical state
• Proactive vulnerability management: wanting to understand performance over time

During a product planning session, I gathered with the entire feature team to reorganize the tree based on additional technical and compliance input. We agreed to focus the first iteration of the feature on reactive management.

Prioritizing data

This project already had demanding technical requirements such as accommodating for an unprecedented scale of data pulling. Therefore, the team pushed for minimizing scope by educating and encouraging users to only pull in the most pertinent types of vulnerabilities. I paired with the content designer to create educational messaging, and with the engineering team to deliberate on default inputs.

Global vs local settings

At the same time this effort was underway, the organization as a whole was undergoing a shift towards using our new design system. It was still in development and not fully completed, but key components such as the font system, field inputs, and tables were already published. As part of keeping work minimal, I added the new automated tests to the current table, but the development team raised concerns the work would have to be scrapped and redone later.

Guidance

Because many Drata users tend to have newer and less mature compliance programs, they benefit greatly from added guidance. Serving up the right information is only helpful if they know what to do with it, but we did not have the resources or plans for a larger instructional design or journey effort. I opted to reuse existing card patterns to highlight and pre-filter the most pressing information as an intermediary step.

Simplified tables, data-rich drawers

In terms of data display, filtering, and sorting, there was a lot of back and forth among the feature team about the level of control and granularity we expected users to exert. Without the time for longer interviews and observation, I could only base my initial designs with the non-technical user in mind. Secondary information I relegated to the details drawer.

Many of the technical data points are nonsensical without referencing codes and indices, but I did not focus on translating these because the main purpose for the Drata user is to identify and relay the information to someone in their organization who can address the issues. To that end, I also separated out the two factors of importance for a vulnerability: due date and severity.

Key takeaways

One of the biggest struggles I faced with this project was sharing often in different formats, fielding feedback and requests from different parties and having difficulty juggling different (and often conflicting) opinions. I think by establishing key stakeholders earlier on and sharing in more controlled intervals, I could have prevented less back-and-forth frustration among the feature team.

Future status

The team definitely wanted to pursue vulnerability exceptions (for the user to maintain compliance), but this was tabled not only for scope but also because exception management was already being worked on by another team. We would need to conduct extensive research and exercise particular care with adding another exception type, so it could definitely be on the roadmap in the future.