Automated traffic filter for Runtime Security
PROBLEM STATEMENT
The early adopters of Contrast's runtime security product Protect were getting value from the product, but not easily. Users had to sift through all the attack traffic being reported to figure out which ones were known pen testers, and which required further action.
ROLE
As the UX lead for this product, I identified this user need, and several others, by observing customers using the product in their day-to-day work.
Based on what I learned, I created an experience map to document the pain points in context with the user's workflow. There were some pain points that were higher priority, like performance. While engineering was working on those issues, we had runway to work on the "low signal to noise" problem.
DESIGN WORKSHOP
Once we identified the problem of needing to identify known pen testers and internal traffic, there were still many ways we could approach the solution. I solicited ideas from across engineering and customer-facing roles, and used those as input to a cross-functional design workshop.
The goal of the design workshop was to evaluate each potential solution by diving into how well they solved the need and any potential barriers to implementation. I designed the workshop to allow for both individual reflection as well as group discussion to get a wide range of ideas.
At the end of the design workshop, we had identified the best solution to pursue, along with great questions to evaluate any design against.
CONCEPTS
The next step was to figure out how users would configure the settings for the automated filter and how it would behave in a variety of situations. At this point the Product Designer and I worked in parallel on solving these problems through whiteboard sketching and discussion. She transferred these ideas into digital mockups in Sketch, which we were able to share for feedback with InVision.
One major change we made early on was to simplify the scope of our first iteration. We originally planned to allow users to set any time range, which would apply the filters to existing traffic, but decided that the most important thing was to apply the filters going forward.
Once we had worked through some of the bigger questions, we had a prototype ready to test with users.
PROTOTYPE TESTING
We made several changes to the prototype based on the tests, and noted several more for future iterations. Instead of allowing users to configure the filters based on multiple criteria, including IPs and headers, we started with IPs as the only criteria. We also tried new icons, since the first ones were not immediately clear.
RESEARCH INSIGHTS
One of our biggest questions was around terminology - the classic "naming is hard" problem. We purposefully left the feature unnamed in the prototype test so that users would talk about it in their own words.
At one point we were using "Attacker Nametags" as a placeholder but we learned that users didn't think of the known pen testers as "attackers". Based on this, and another internal survey, we were able to narrow in on a more neutral, yet descriptive term: "Source Names".
One of the users described the capability exactly as we'd envisioned it:
“I need to differentiate bad guys from the people I know about.”
DELIVERY
After sharing a summary of the research, updating the mockups and descriptions, my role was to support the engineering team throughout the development process. The product designer and I both attended all agile ceremonies to make sure engineering always had what they needed. We also revised the plan into a phased approach that would allow us to deliver value to the customer sooner.
Overall this project served as a great model in the company for how UX provides value throughout the entire product development lifecycle.