Data Collectors and Sources
Secureworks | UX and Interaction Design
January 2021 - Two Weeks
Role: Lead Designer
Additional Team Members: Product manager, UX designer, software engineer
Data Collector Details
The Problem
Taegis XDR relies on telemetry from data collectors, which collect data from various appliances such as firewalls. Taegis XDR uses the data collector to ingest the data and translates it to events and alerts. Customer support was receiving various complaints from customers about not knowing if their data collectors were working properly. Once set up, they could not tell if data was getting ingested or if it was ingesting the data properly. This was a major problem for customers because if data collectors are not ingesting the right data, analysts will not receive timely alerts and events and cannot do their jobs.
Process
To address the data collector problem, I worked with another designer in a modified design sprint. While a typical design sprint takes place over 5 days, due to the structure of the team and other projects, this exercise took place over two weeks.
Although we diverged from the typical timeline, all stages of the design sprint were completed. The design sprint also took place 100% remote, and the Miro Design Sprint template was used to facilitate the process.
Design Sprint Stages
Map
Long-Term Goal and Sprint Questions
Using the Miro board, myself and another designer discussed possible long-term goals for this project. Using the design sprint framework, we asked ourselves, “if everything goes right, what will we have accomplished in 12-18 months?”
Customers are confident in their security posture
After deciding a long-term goal, we moved on to the sprint question, where we had to figure out what we need to accomplish in order to meet our long-term goal, or put in another way, we needed to think of ways this project could go wrong.
Can customers trust the information in the product?
We settled on these two things because they address the core problem. Customers weren’t confident in their security posture because they couldn’t tell if their environment was ingesting data properly. Even though they technically set up the data collector, there was no way for them to confirm everything was working, unless they reached out to customer support. We realized that the only way customers will trust the information in Taegis XDR will be if they can solve the problems themselves, instead of relying on customer support to translate and solve issues for them.
User Flow
Taegis XDR has two primary users. The first is the security analyst, who spends most of their time triaging events and alerts. The second key user is the IT admin, whose main responsibility is setting up XDR and making sure it is ingesting the right data sources so that analysts can do their jobs. Based on our understanding of these two users, the other design and I mapped out the basic user flow for these two users. See image below for the user flows.
Ask the Experts
We interviews 6 Taegis XDR experts to get a better understanding of how data collectors are set up and managed.
2 product managers
2 solutions engineers
2 customer support managers
We learned that once the customer set up the data collector, very few customers knew how to confirm if their data collector was working properly. While the data collectors in XDR had simple status messages like “healthy” or “unhealthy”, users did not know what that meant or how those statuses were derived. Because of this, customers would reach out to customer support, who would then create an advanced search query to see if the data collectors were pushing events to XDR.
The Target
Most important customer: IT Admin
Key moment: data collector setup confirmation
Based on our conversations with the experts, we defined our target as the IT admin when they are confirming the data collector was set up properly. We knew the IT admins did not want to have to rely on customer support to troubleshoot their data collectors, but at the same time, the IT admins also didn’t want to learn a complex query language to do the troubleshooting themselves.
Remix and Improve
“The day starts with inspiration: a review of existing ideas to remix and improve” - Design Sprint
During this phase, I was looking for onboarding inspiration. Looking outside the field of cybersecurity, I found examples of how different products addressed first-time experiences, onboarding and status messages.
Design inspiration
Sketch and Decide
In my sketches, I tried to think of ways to show complex status messages that a data collector might have. I thought about in-app notifications and how to move beyond tables to show data collector information. I also thought about different onboarding ideas like a checklist, or ways to include helpful integration setup details.
After the other designer and I finished our sketches, we discussed and decided we wanted to move forward with exploring different types of widgets and details pages since in the current product, users were shown a table with 1-2 rows and had a hard time interpreting that information.
Prototype and Test
I created a Figma prototype that detailed four key data collector screens
An index page of data collectors
Data collector details page
An index of data sources
Data source details
We tested this prototype with 2 internal users and 2 external users. We wanted to identify if users could tell if a data collector was working properly, and if a data collector needed troubleshooting, we wanted to see if they knew what next steps to take.
Conclusion
Based on our prototype test, customers responded well to the data collector index page. They felt a lot of important information was conveyed in the cards and once on the detail pages, they liked the widgets that showed the data source counts and their corresponding statuses. On the data source detail page, customers also really liked having a button that linked to Advanced Search, since they assumed it would take them to a pre-populated query and they would not have to write the query themselves.
While we didn’t follow the traditional design sprint framework, this activity was still helpful in that it was able to help us identify customers’ frustration with the data collector workflow, and was well received by customer support once it was released.
