Persona
SOC Analyst
Monitors and responds to security incidents in real time.
"I need to know what to fix immediately, not after checking 3 screens."
OTORIO / OT Security Platform
Redesigning how security teams understand and act on risk
Designing the core investigation experience across Assets, Alerts, Cases, and Rules.
- No rules at allAlerts trigger an email automatically
- A sparse Cases pageCases open from any alert or asset
- Details inside a table rowA side panel that keeps the list in view
Overview
Over two years, I owned the design of these experiences.
OTORIO, later acquired by Armis in 2025.
My work spanned understanding user workflows, defining requirements, interaction design, UI, and collaboration with engineering. I joined the design team as a Product Designer and became the primary designer for the product after the senior designer left.
Problem
The challenge wasn't collecting the data. It was helping security teams understand what matters.
OT security platforms deal with enormous amounts of data: assets, alerts, vulnerabilities, insights, cases.
Drowning in information
- Risk scores appeared without enough context
- Moving between screens broke the investigation flow
- Terminology was inconsistent across the product
- Different users needed different levels of information from the same data
Move between related information and take action without losing the investigation context.
Two user types
Persona
Operations Manager
Oversees infrastructure and ensures safe, reliable, efficient operation.
"I need to plan remediation by business impact, not just urgency."
I uncovered that customers didn't understand the full picture, or weren't using the product the way we intended, so they weren't getting its full value. We knew the product served two user types, but we didn't fully understand how each worked within the system. I went to talk with users and worked with Research to understand how they investigate an incident.
Principles
Every decision came back to one question: does this move the investigation forward, or stop it?
I mapped how users move from detection to investigation to action, using risk as the thread connecting the product.
Investigation as a flow
A journey, not separate pages.
Risk lives on the asset
One source of truth for both user types. No context-switching.
Cases as connective tissue
Openable from anywhere. Users move from investigation to action without starting over.
How risk is built
Risk is made of the threat and the asset's exposure.
Detection Risk
Threat
LikelihoodSeverity (Threat)
- What are the chances of something happening?
- What is the risk level?
Exposure
VulnerabilityImpact
- How vulnerable is the asset?
- What is the asset's impact?
High Risk = High Impact + High Vulnerability
Design
Beyond the UI, the work was defining how the system should behave.
A rule defines what happens when an alert is created: which conditions it must meet, and which action follows.
Problem
Rules didn't exist in the product.
Decision
We first had to identify the foundation the feature could build on. I designed the first version from the ground up: a rule sends an email, built from a trigger, conditions and an action.
Why
So users can understand what would trigger a rule, which conditions applied, and what would happen next.
Add rule flow
- TriggerAdd rule
- Give name to the rule
- Set the trigger: alert creation
- ConditionsSelect condition
- Severity levelcritical / high / medium / low
- ShopShop names
- CellCell name / shop name
and Add another condition, with the same options
- ActionSelect action: send email
- Select from a list or add new email
- Save
Before defining the final interface, I worked through dependencies and system behavior.
Opening a case
Problem
The Cases page was sparse: no asset details, no way to add information to a case, and duplicate cases could appear when opening one.
Decision
I chose where the button lives so it is reachable from the investigation, defined what the system asks when a case is opened, added options at creation such as linking a site and assets, redesigned the case page to carry that information, and made duplicates recognizable to the user.
Why
I designed the case as part of the investigation flow, rather than a separate destination.
From row to panel: Assets and Alerts
Problem
Asset and alert details opened inside the table row, leaving little room for information and forcing users to lose context when investigating.
Decision
I explored three directions: an expandable table row, a side panel, and a full page. I moved asset and alert details into a side panel, keeping the table and investigation context visible while allowing the detail view to grow with the product.
Why
The side panel supported the way analysts moved between overview and deeper investigation without repeatedly navigating away from the main list.
Where they differ: risk lives on the asset.
Results
Turned alerts into action
Rules let alerts trigger an email automatically, and users can now open a case quickly from any alert or asset, moving from investigation to action without starting over. Both were developed and shipped, Rules as a first version.
Confirmed the flow with Sales
Sales, who are in frequent contact with customers, navigated a prototype I built and completed the task, and reported that it made the task easier. The VP Product's feedback was positive.
Strengthened the team's understanding of the product
The product team gained an understanding of how the product's parts connect, and Research were aligned that the design improved the flow of an incident and its analysis. The business impact of risk also became easier to understand.
Revealed a need for a business-side area
The research showed two stories, handling what is urgent now and the business story, and with them a need for a separate business-side area. We started planning it, but it was not ready.
What I learned
Good design starts with shared understanding
In a complex security product, that means building the understanding across users, Product, Engineering, and the business.
Map the flow before the screens
It helped me make better interaction decisions and keep the experience coherent as the product grew.
