DefenderX
Don't wanna read? Listen my story!!
DefenderX is Walmart's internal security monitoring platform. Two user types: Security Analysts who review scripts and raise allow/deny requests, and Application Security Engineers who act on those requests and manage applications. When I joined, the platform could display data but analysts had no way to act on it. As the only designer on the InfoSec pillar, I redesigned core workflows, added an action layer, and turned DefenderX from a passive dashboard into something people could actually use.
Role:
UX Designer II
Duration:
2-3 months
The Challenge
01
Two core problems when I joined.
Two core problems when I joined.
Users had no holistic view. Before seeing any data, they had to select a tenant, application, and host — one domain at a time, every session. Five applications across three hosts meant repeating that flow fifteen times for one monitoring pass.
And there was no way to act. Scripts could be viewed but not acted on. Every decision happened outside the platform.
Solutions
02
Navigation Redesign
The problem wasn't the selection. It was that users couldn't see it.
The platform auto-selected one tenant, one application, and one host by default. The selection UI existed but was placed in a way that was easy to miss. Users never realized they had access to other applications or other hosts within the same application. They thought they were seeing everything. They weren't.
I added a one-time onboarding step where first-time users explicitly select the applications and hosts they want to monitor. This makes their full access visible from day one and shows them exactly where to change it later. On every visit after that, users land directly on their dashboard — no reconfiguration, no starting over.
The Action Layer
From flagged to resolved. In one flow
When a script got flagged, analysts had nowhere to go inside the platform. No risk context, no clear actions, no escalation path. Every decision was made in a separate tool.
I designed an action layer that gives analysts everything they need without leaving DefenderX. Script context, risk signals, allow/deny actions, and an escalation path when needed. Every action is logged and traceable.
Read-only → fully actionable
By round four, users completed the full flow without errors. Approved for development.
Application Onboarding
A guided wizard that surfaces complexity step by step.
Onboarding a new application meant configuring three complex components with no clear starting point.
Four rounds of usability testing with analysts, engineers, and stakeholders, from initial wireframes through edge case refinement. Each round shaped a three-step wizard that builds on itself.
"If I can regenerate it in two minutes with any filters I want, I don't need to store old ones."
One page cut. Zero rework.
Reports
From three pages and a list to one guided flow
Stakeholders wanted a full reports system: three report types, a history page, download and share flows.
Research showed reports were generated once and never revisited. A history list would almost always be empty. I built a simplified flow in Figma and ran it live with stakeholders. Five steps, under two minutes.
Impact
03
Why this matters.
Hidden → Visible access
Users discovered their full application and host access through a one-time onboarding step.
Read-only → Actionable
Scripts went from view-only to fully manageable.
40% faster
Task completion on onboarding and action layer, measured through usability testing.
1 page removed
Reports history cut after research confirmed no one revisited old reports.
All domains visible
From one domain at a time to full application view on load.
2–4/5 → 4–5/5
Satisfaction scores across analysts, engineers, and stakeholders
Reflection
04
What I’d take forward.
Joining a project halfway means the most valuable thing you bring isn't design skill. It's the nerve to ask why.
DefenderX
Don't wanna read? Listen my story!!
DefenderX is Walmart's internal security monitoring platform. Two user types: Security Analysts who review scripts and raise allow/deny requests, and Application Security Engineers who act on those requests and manage applications. When I joined, the platform could display data but analysts had no way to act on it. As the only designer on the InfoSec pillar, I redesigned core workflows, added an action layer, and turned DefenderX from a passive dashboard into something people could actually use.
Role:
UX Designer II
Duration:
2-3 months
The Challenge
01
Two core problems when I joined.
Two core problems when I joined.
Users had no holistic view. Before seeing any data, they had to select a tenant, application, and host — one domain at a time, every session. Five applications across three hosts meant repeating that flow fifteen times for one monitoring pass.
And there was no way to act. Scripts could be viewed but not acted on. Every decision happened outside the platform.
Solutions
02
Navigation Redesign
The problem wasn't the selection. It was that users couldn't see it.
The platform auto-selected one tenant, one application, and one host by default. The selection UI existed but was placed in a way that was easy to miss. Users never realized they had access to other applications or other hosts within the same application. They thought they were seeing everything. They weren't.
I added a one-time onboarding step where first-time users explicitly select the applications and hosts they want to monitor. This makes their full access visible from day one and shows them exactly where to change it later. On every visit after that, users land directly on their dashboard — no reconfiguration, no starting over.
The Action Layer
From flagged to resolved. In one flow
When a script got flagged, analysts had nowhere to go inside the platform. No risk context, no clear actions, no escalation path. Every decision was made in a separate tool.
I designed an action layer that gives analysts everything they need without leaving DefenderX. Script context, risk signals, allow/deny actions, and an escalation path when needed. Every action is logged and traceable.
Read-only → fully actionable
Application Onboarding
A guided wizard that surfaces complexity step by step.
Onboarding a new application meant configuring three complex components with no clear starting point.
Four rounds of usability testing with analysts, engineers, and stakeholders, from initial wireframes through edge case refinement. Each round shaped a three-step wizard that builds on itself.
By round four, users completed the full flow without errors. Approved for development.
Reports
From three pages and a list to one guided flow
Stakeholders wanted a full reports system: three report types, a history page, download and share flows.
Research showed reports were generated once and never revisited. A history list would almost always be empty. I built a simplified flow in Figma and ran it live with stakeholders. Five steps, under two minutes.
"If I can regenerate it in two minutes with any filters I want, I don't need to store old ones."
One page cut. Zero rework.
Impact
03
Why this matters.
Hidden → Visible access
Users discovered their full application and host access through a one-time onboarding step.
Read-only → Actionable
Scripts went from view-only to fully manageable.
40% faster
Task completion on onboarding and action layer, measured through usability testing.
1 page removed
Reports history cut after research confirmed no one revisited old reports.
All domains visible
From one domain at a time to full application view on load.
2–4/5 → 4–5/5
Satisfaction scores across analysts, engineers, and stakeholders
Reflection
04
What I’d take forward.
Joining a project halfway means the most valuable thing you bring isn't design skill. It's the nerve to ask why.
DefenderX
Don't wanna read? Listen my story!!
DefenderX is Walmart's internal security monitoring platform. Two user types: Security Analysts who review scripts and raise allow/deny requests, and Application Security Engineers who act on those requests and manage applications. When I joined, the platform could display data but analysts had no way to act on it. As the only designer on the InfoSec pillar, I redesigned core workflows, added an action layer, and turned DefenderX from a passive dashboard into something people could actually use.
Role:
UX Designer II
Duration:
2-3 months
The Challenge
01
Two core problems when I joined.
Two core problems when I joined.
Users had no holistic view. Before seeing any data, they had to select a tenant, application, and host — one domain at a time, every session. Five applications across three hosts meant repeating that flow fifteen times for one monitoring pass.
And there was no way to act. Scripts could be viewed but not acted on. Every decision happened outside the platform.
Solutions
02
Navigation Redesign
The problem wasn't the selection. It was that users couldn't see it.
The platform auto-selected one tenant, one application, and one host by default. The selection UI existed but was placed in a way that was easy to miss. Users never realized they had access to other applications or other hosts within the same application. They thought they were seeing everything. They weren't.
I added a one-time onboarding step where first-time users explicitly select the applications and hosts they want to monitor. This makes their full access visible from day one and shows them exactly where to change it later. On every visit after that, users land directly on their dashboard — no reconfiguration, no starting over.
The Action Layer
From flagged to resolved. In one flow
When a script got flagged, analysts had nowhere to go inside the platform. No risk context, no clear actions, no escalation path. Every decision was made in a separate tool.
I designed an action layer that gives analysts everything they need without leaving DefenderX. Script context, risk signals, allow/deny actions, and an escalation path when needed. Every action is logged and traceable.
Read-only → fully actionable
Application Onboarding
A guided wizard that surfaces complexity step by step.
Onboarding a new application meant configuring three complex components with no clear starting point.
Four rounds of usability testing with analysts, engineers, and stakeholders, from initial wireframes through edge case refinement. Each round shaped a three-step wizard that builds on itself.
By round four, users completed the full flow without errors. Approved for development.
Reports
From three pages and a list to one guided flow
Stakeholders wanted a full reports system: three report types, a history page, download and share flows.
Research showed reports were generated once and never revisited. A history list would almost always be empty. I built a simplified flow in Figma and ran it live with stakeholders. Five steps, under two minutes.
"If I can regenerate it in two minutes with any filters I want, I don't need to store old ones."
One page cut. Zero rework.
Impact
03
Why this matters.
Hidden → Visible access
Users discovered their full application and host access through a one-time onboarding step.
Read-only → Actionable
Scripts went from view-only to fully manageable.
40% faster
Task completion on onboarding and action layer, measured through usability testing.
1 page removed
Reports history cut after research confirmed no one revisited old reports.
All domains visible
From one domain at a time to full application view on load.
2–4/5 → 4–5/5
Satisfaction scores across analysts, engineers, and stakeholders
Reflection
04
What I’d take forward.
Joining a project halfway means the most valuable thing you bring isn't design skill. It's the nerve to ask why.