Material Security is a cybersecurity software company focused on email attacks (like the product I worked on, which is called Phishing Protection). They offer various other products as well, including Posture Management (an overview of your security risks), Data Protection (security monitoring for your files), and Identity Protection (security monitoring for your accounts).
In Material's software, the primary function for the users (primarily IT admins) to manage a list of cases created based on what the software has detected as a security risk. To manage these cases, they might need to adjust the severity of the case, or apply remediations to them. In this context, a remediation is an action applied to the case to resolve, or remediate, the security risk.
The starting point for this project was pretty vague. One of our customers requested this functionality, but how to implement it was still unclear.
“We should add a setting that allows Admins to define the default remediation actions we apply when they select a given classification in Case Detailsˮ
The existing experience was nested under "User Reporting", with a related section next to it. I learned later on that the scope I was advised on wasn't the actual scope of this work—the functionality spanned several settings containers and required modifications to some adjacent features that shared characteristics with this functionality. Below is the "Existing" view of the page I began working on.
I started by exploring similar apps. Since it’s not easy to find security software competitors, I took a step back and looked instead for apps that “have a list of things you need to act on”. That might sound overly simplistic at first, but searching for such a general type of application allowed me to go wide with my understanding of the actions the user would need to take. This led me to identifying a set of heuristics based on what I found in common with those applications.
After that, I wanted to understand when and why these settings were being altered.
This helped me understand the entrypoints I might need to consider, and where these settings should fit in the hierarchy of the information architecture.
I started looking at what we had in the product today, so that we could consider that in our roadmap. Here’s a few questions I asked:
This led me to some early explorations of the hierarchy where I sought to understand how users relate these features to their settings.
Pros: The remediations are enacted based on what action is taken on the cases, so this feels logical
Cons: Requires reworking the interaction patterns and structure of this functionality
Pros: We'd mostly be able to maintain the existing layout, meaning fewer changes
Cons: The classifications that these remediations would apply to would be buried, requiring multiple clicks to view them
Pros: The layout is somewhat chronological, which may be easier for users to follow
Cons: User report acknowledgements aren't always required, so this fuzzies the interaction for all the other settings the remediations apply to, and it assumes that there are no other remediations that we'd want to apply to "Safe" cases
Pros: This layout follows an actual chronological pattern of how these steps get initiated, which may be easier for users to follow
Cons: The report acknowledgements are a very separate process structurally and would sizably increase the scope to rearrange it in this way
I continued to explore these when I moved to mid-fidelity wireframes and visual explorations, and eventually landed on Option 1, as through all the iterations, the design is very oriented around a cause and effect relationship to better indicate how settings will affect the content in the admin's case list.
Coming out of the initial explorations, I discovered that there were several areas where these settings lived, and a lot of confusion across the team around what happens when and how much would need to change for us to be able to rethink this layout.
After talking to one of our tenured engineers, our team joked that the functionality of remediations was so complicated that we need a guide like the Slack diagram (linked here) for notifications, so I chatted with various members of the engineering team to build a diagram that we could use to explain remediation functionality and to guide future developments to this workflow. This would allow us to better align on what we would propose, and also could live on as a reference for future edits to this surface.
The gist of the diagram below is that the path of either a case that's “manually classified by Adminˮ or the source of the case's detection both lead to remediations. One is set first (based on the source of the detection), and the other can override it (manual case classification by admins).
Getting a clear understanding of this across the team was super helpful because early in the process, we kept running into issues that would emerge because of how these different settings intersect.
In my exploration of different ideas, I explored variations on the information architecture, ran through several mid-fidelity mocks to figure out what functionality would go where, and played with a multitude of tiny visual tweaks to see what was most effective in achieving the legibility and ease of use we were striving for.
Below is a collection of a few specific developments of the visual design as I made rounds between working alone, sharing work with my engineer and PM, and bringing it back to frequent design jam sessions with my team to make sure this aligned with the design system and any intersecting features.
This was when I really started closing in on the final design, but even though this was my ideal design, it required a lot of engineering lift and I couldn't justify prioritizing all of this work above the original feature request. From here, I started reverse-engineering the design plan.
While this initially seemed like an easy thing to implement (I really thought I was almost done several times), I discovered some deeper complexity in the way that we’d set up our product interface, and unearthed several usability issues that made our current settings layout really difficult to use.
In the security industry, our customers are using our product for really urgent situations, and some seemingly small changes can be the difference between efficiency and our users having to deal with dire consequences to their product’s security. The way my PM phrased it to me was “Is this change worth our user having a really bad day?”, and that kind of stuck with me through this project. We needed to implement these changes in a way that didn’t disrupt our users through work that is really fast-paced with painful consequences if they’re not able to act quickly.
This meant that, while we found a lot of usability issues that we needed to revise, we needed to be thoughtful and strategic about implementing this work in a few milestones.
To address the need to make small changes to reduce thrash for our users, I broke the project down into a few milestones to address the urgent feature request, and to make sure we address the usability issues we found in our earlier explorations. The main area I was working on needed revisions to allow for this new functionality, but this area was redundant across various settings, and there were adjacent settings that needed to be revised for consistency, but weren't necessarily the most important issue to solve for when we had limited front-end bandwidth. Across all of that, the removal of the redundant settings would leave a lot of small settings spread across various entry points, so the navigation would also need some work.
Here's the milestones I delivered to the team in partnership with my PM and through collaborations with engineering:
Deliver the basic functionality that was asked for—our customers need a way to edit the settings that are set by default when you change a classification.
Example: Maurice is reviewing his cases list. They have a user named Jim who is always reporting false stuff. Jim is the worst. I want to automatically mark most malicious things as malicious and remediate them maliciously UNLESS it's a user report.
Now that so much is changing in settings, and some content is outdated, can we make settings simpler to navigate?
TBD
While lower priority, Reporter Acknowledgements should still be revised to reflect the small visual and clarity improvements that weʼve designed.
