Back to home

DefenderX — From Passive to Active

Walmart Global Tech

Shipped

2025

heroimage

DefenderX — From Passive to Active

Walmart Global Tech

Shipped

2025

heroimage
heroimage

DefenderX — From Passive to Active

Walmart Global Tech

Shipped

2025

Team

1 Designer (myself), the only designer on the InfoSec pillar, working alongside Engineering and Product Management.

Industry

Cybersecurity / Enterprise Security Tools

Overview

I'm a Software Engineer / UX Designer II at Walmart Global Tech, and the only designer on the InfoSec pillar for DefenderX, Walmart's internal security monitoring platform. Analysts review scripts and raise allow/deny requests; engineers act on them. When I joined, the platform already existed but analysts had no way to act on what it showed them. I ran a heuristic evaluation of the existing design, followed it with informal interviews across users and stakeholders, and used that to redesign core workflows and add an action layer, partnering closely with engineering to align each flow with the existing data model and codebase. Since the team wasn't looking to build off a live codebase yet, I used Figma Make AI to explore ideas quickly and get stakeholder alignment before moving into full design

Outcome

  • DefenderX moved from a platform that could only display security data to one built for action. Analysts went from a partial, easy-to-miss view of their own access to full visibility from day one, and from watching flagged scripts sit idle to resolving them, allow, deny, or escalate, without leaving the tool.

  • A reports page nobody used was cut before it was ever built. These results come from usability testing on the redesigned onboarding and action layer flows, not live production data yet.

Getting to know DefenderX

DefenderX is Walmart's internal security monitoring and compliance platform, built for the InfoSec pillar to track script activity, manage application-level access, and govern allow/deny decisions across Walmart Global Tech. It surfaces risk signals on flagged scripts, routes them through a structured review and action workflow, and maintains a logged, auditable record of every decision made on the platform.

brirf-image

Team

1 Designer (myself), the only designer on the InfoSec pillar, working alongside Engineering and Product Management.

Industry

Cybersecurity / Enterprise Security Tools

Overview

I'm a Software Engineer / UX Designer II at Walmart Global Tech, and the only designer on the InfoSec pillar for DefenderX, Walmart's internal security monitoring platform. Analysts review scripts and raise allow/deny requests; engineers act on them. When I joined, the platform already existed but analysts had no way to act on what it showed them. I ran a heuristic evaluation of the existing design, followed it with informal interviews across users and stakeholders, and used that to redesign core workflows and add an action layer, partnering closely with engineering to align each flow with the existing data model and codebase. Since the team wasn't looking to build off a live codebase yet, I used Figma Make AI to explore ideas quickly and get stakeholder alignment before moving into full design

Outcome

  • DefenderX moved from a platform that could only display security data to one built for action. Analysts went from a partial, easy-to-miss view of their own access to full visibility from day one, and from watching flagged scripts sit idle to resolving them, allow, deny, or escalate, without leaving the tool.

  • A reports page nobody used was cut before it was ever built. These results come from usability testing on the redesigned onboarding and action layer flows, not live production data yet.

Getting to know DefenderX

DefenderX is Walmart's internal security monitoring and compliance platform, built for the InfoSec pillar to track script activity, manage application-level access, and govern allow/deny decisions across Walmart Global Tech. It surfaces risk signals on flagged scripts, routes them through a structured review and action workflow, and maintains a logged, auditable record of every decision made on the platform.

brirf-image

The challenge

A Dashboard That Could Show You Everything, and Let You Do Nothing

Users landed on data by default for one application, but the filters to switch tenant, application, or host were easy to miss, so most analysts believed they were seeing everything when they weren't. Worse, scripts could be viewed but never acted on: every real decision, every allow or deny, happened outside the platform entirely, in a separate tool, disconnected from the data that justified it.

Who are we designing for?

Target Audience

Designed for two core user types on Walmart's InfoSec pillar:

APPLICATION SECURITY ENGINEERS

APPLICATION SECURITY ENGINEERS

SECURITY ANALYSTS

SECURITY ANALYSTS

Laying out the foundation

Affinity Mapping

Rather than a formal research study, this started with a heuristic evaluation of the existing product, and the questions that evaluation raised shaped a round of informal conversations with users and stakeholders. Those conversations focused on how people actually worked: how they function day to day, what information they look for, what they do after landing on the platform, how often they come back, and what their primary tasks are.

Users didn't know what they didn't know.

People assumed the default view was the full view, the filters to reveal more access were easy to miss.

The number of steps wasn't the real problem, discovering a gap mid-flow was.

Frustration spiked hardest when users realized they needed something external before they could continue.

Reports are read once, not maintained.

Generated once per cycle, shared over email, and rarely revisited unless an audit required it.

Solutions

This project ran about six months, with real constraints along the way: as the only designer on the pillar, getting time for usability testing meant personally recruiting participants, and even with real effort, only four people were available to test with. The other recurring constraint wasn't technical, it was alignment: a few of these solutions, especially Reports, meant convincing stakeholders to rethink a concept they'd already asked for.

01

Navigation Redesign

The problem wasn't the selection, it was that users couldn't see it. Partnered with engineering to understand how selection was stored and defaulted, then added a one-time onboarding step where users explicitly pick their apps and hosts, making full access visible from day one.

02

The Action Layer — From flagged to resolved, in one flow.

Flagged scripts had nowhere to go, no context, no path forward. Worked closely with engineering to map what data was available at flag time and how allow/deny, escalation, and logging needed to write back into the system. Now: context, risk, actions, and escalation, all in one place, fully logged.

03

Application Onboarding — A guided wizard that surfaces complexity step by step

Onboarding meant configuring three complex components with no clear start. Four rounds of usability testing, plus working with engineering to separate hard technical dependencies from flexible ordering, shaped a three-step wizard that builds on itself.

04

Reports — From three pages and a list to one guided flow.

Stakeholders wanted a full reports system, but research showed reports were generated once and never revisited. Confirmed with engineering that cutting the history page was safe and that on-demand regeneration was lightweight enough. Result: five steps, under two minutes. One page cut, zero rework.

01

Navigation Redesign

The problem wasn't the selection, it was that users couldn't see it. Partnered with engineering to understand how selection was stored and defaulted, then added a one-time onboarding step where users explicitly pick their apps and hosts, making full access visible from day one.

02

The Action Layer — From flagged to resolved, in one flow.

Flagged scripts had nowhere to go, no context, no path forward. Worked closely with engineering to map what data was available at flag time and how allow/deny, escalation, and logging needed to write back into the system. Now: context, risk, actions, and escalation, all in one place, fully logged.

03

Application Onboarding — A guided wizard that surfaces complexity step by step

Onboarding meant configuring three complex components with no clear start, and getting it wrong meant analysts couldn't monitor their applications at all. Four rounds of usability testing, run with a small pool of just four participants I had to personally recruit, showed the friction on an earlier 5-step version wasn't the step count, it was discovering an unmet prerequisite partway through. Rebuilt as a 3-step wizard that surfaces what's needed upfront, before the user starts.

04

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. Conversations about how the reports would actually be used surfaced that they're generated once a cycle and rarely revisited, so I made the case for cutting the history page entirely in favor of a fast generate-and-share flow. One page cut, zero rework.

Overall Project Impact

Faster resolution, validated in testing

40% faster task completion on onboarding and the action layer, cutting the time security decisions take to reach a conclusion.

Full visibility from day one.

All domains visible on load instead of one at a time, so analysts stop working with a partial picture of their own access.

Less operational overhead.

Cutting the reports history page removed a maintained feature nobody used, reducing what the team has to support.

Higher confidence, validated in testing.

Satisfaction scores moved from 2–4/5 to 4–5/5 across analysts, engineers, and stakeholders alike.

Learnings

  • Being the only designer means doing the unglamorous work too. Getting even four usability testing participants took real, personal effort, recruiting, convincing, scheduling, with no research team to lean on.

  • The right answer sometimes means unselling an idea. Reports shipped smaller than what stakeholders originally asked for, because the evidence, not just a design opinion, was strong enough to change their minds.