Disable accounts workflow
The workflow allowed a new remediation action to be created in parallel with an existing remediation analysts were already in the habit of creating.
Overview
Impact
90%
use cases covered while
saving 6 clicks per instance
The problem
The problem was that adoption of the feature was at risk, since the new workflow created additional decision points for Expel SOC analysts.
Biggest research insight
A SOC manager raised a concern around the adoption for a new feature, in a moment of high stress for the analyst, when there’s a security incident.
My role
Lead UX designer
Usability testing
Prototyping
Lean UX
The users
Expel SOC analysts
Persona quote - “I always ask myself, how could this bite us in the ass if we’re wrong?”
Internal user who spends 10 hours per day in Workbench
Customer analysts
Persona quote - “I want to get Expel more context so they make the right decision”
External user who monitors numerous security products beyond Workbench
| Remediation action | To-do items assigned to a customer's security team when a customer's compromised (ex. "Reset credentials") |
| Disabling an account | Blocking a user from logging into their account, a type of remediation action |
| SOC | Acronym: "security operations center" |
| Investigations/incidents | Deliverables for customers when they might have had a security breach |
Terminology
Timeframe
3 weeks - UX work
2.5 months - UX + Eng/QA work
Contributors
Paul Diebold - Eng
Patrick Duffy - PM
Nabeel Zafar - Lead Eng
Fred Mottey - QA
Final concept
Automatic system check
When nudging the analyst to create an auto disable account remediation action, the UI indicates what that the remediation action will be automated and that the customer is opted into the feature.
Workflow time comparison
The remediation action workflow was significantly streamlined, and most importantly, it removed a decision for the analyst during a stressful situation, when a customer is compromised.
The process
User concern
I met with Ray, a SOC manager, to discuss the release of the auto disable accounts feature, a continuation of automated remediation actions we had rolled out as a team.
After understanding his concern with the workflow I communicated it out to the team.
Generating workflow options
I worked directly with an engineer to quickly diagram a handful of solutions ranging in complexity and engineering LOE, presenting the options to the PM.
Usability testing for UI choice
This was the first time a user could create 2 remediation actions within a single remediation action, so I wanted to usability test the UI.
Both prototypes caused enough confusion with analysts that I decided to go with a 3rd option, limiting the degree of user control, while still covering over 90% of all use cases.
Usability testing recording
Responding to engineering questions
While discussing requirements with engineers, I would often field questions about design decisions or use cases I hadn’t covered.
I became accustomed to sharing my reasoning, usually based on design principles, value to the users, or company values. At times though, I admitted I hadn’t considered that and would need to think about it, asking for clarification to ensure I understood the question.
My reflection
What was I right about?
While I did remove flexibility in the workflow, I successfully covered 90% of the use cases, leading to high adoption of the feature.
What was I wrong about?
With the prototypes I usability tested, I thought one of the prototypes, the one that I believed was a more elegant solution, would easily be understood by analysts.
What would I do differently?
Addressing this workflow issue, while successful, delayed the release of the feature by 2.5 months. I think an A/B release would’ve helped to prove the value of the work. Or, I think I could’ve advocated for releasing the feature for a beta set of Expel SOC analysts and customers to test the assumption about the workflow issue, while limiting the potential risk.