Policy Visualiser
Don't wanna read? Listen my story!!
Policy Visualiser is Walmart's internal platform for understanding who has access to which Linux machines. It surfaces every policy, hostgroup, and user assignment from a single hostname search.
Role:
UX Designer II
Duration:
3-4 months
The Challenge
01
Two core problems when I joined.
Linux access at Walmart flows through layers: machines belong to hostgroups, hostgroups inherit access policies, and policies define which AD groups and individual users can log in. The model was complete and accurate. It just wasn't readable by anyone except the engineers who built it.
Every access question required a ServiceNow ticket, an assigned LIDS engineer, and up to 30 minutes of manual config parsing. Three teams had read access and no path to answers. One team had all the answers and no time to keep giving them.
Solutions
02
Hostname search
One input. No ticket, no wait.
Every user had the hostname. Nothing else could be assumed, so nothing else was required. This was the entry point that made everything else possible.
Host Details Page
All policies for a host in one place, each showing its hostgroup assignment and status. What used to take 30 minutes of manual parsing now took a glance.
Spot Common Users Across Policies
Auditors were manually cross-referencing SNOW responses to find over-permissioned accounts, a process that took multiple lookup cycles and introduced reconciliation errors. This feature surfaces that view in a single click. The work that once required a ticket queue now requires a row selection.
Map View
The access hierarchy (host, hostgroup, policy, user) is abstract until it is spatial. The map view was not added for visual appeal. It was added because non-specialists needed a way to hold the entire system in their head at once, without needing a LIDS engineer to explain it to them.
Jump to Another Host
Access investigations rarely stop at one machine. Users can search a new hostname directly from the detail page, without navigating back or losing context. The tool stays out of the way of the investigation.
Impact
03
Why this matters.
Average investigation time
~30 min via SNOW
~2 min
SNOW tickets for access lookups
Ongoing
Zero
Teams able to self-serve
1 (LIDS only)
3 (Auditors, DevOps, App Security)
Linux access visibility
Config files + specialists
1 platform, all layers
Reflection
04
What I’d take forward.
Security tools don't fail because the data is wrong. They fail because the interface assumes you
already know. Self-service in enterprise tools isn't a UX goal. It's a trust problem. The platform
has to be confident enough that users stop second-guessing the answer and reach for the tool
instead of a ticket. Getting there meant not just exposing the data, but designing how it would be
understood by someone encountering it for the first time.
Policy Visualiser
Don't wanna read? Listen my story!!
Policy Visualiser is Walmart's internal platform for understanding who has access to which Linux machines. It surfaces every policy, hostgroup, and user assignment from a single hostname search.
Role:
UX Designer II
Duration:
3-4 months
The Challenge
01
Two core problems when I joined.
Linux access at Walmart flows through layers: machines belong to hostgroups, hostgroups inherit access policies, and policies define which AD groups and individual users can log in. The model was complete and accurate. It just wasn't readable by anyone except the engineers who built it.
Every access question required a ServiceNow ticket, an assigned LIDS engineer, and up to 30 minutes of manual config parsing. Three teams had read access and no path to answers. One team had all the answers and no time to keep giving them.
Solutions
02
Hostname search
One input. No ticket, no wait.
Every user had the hostname. Nothing else could be assumed, so nothing else was required. This was the entry point that made everything else possible.
Host Details Page
All policies for a host in one place, each showing its hostgroup assignment and status. What used to take 30 minutes of manual parsing now took a glance.
Spot Common Users Across Policies
Auditors were manually cross-referencing SNOW responses to find over-permissioned accounts, a process that took multiple lookup cycles and introduced reconciliation errors. This feature surfaces that view in a single click. The work that once required a ticket queue now requires a row selection.
Map View
The access hierarchy (host, hostgroup, policy, user) is abstract until it is spatial. The map view was not added for visual appeal. It was added because non-specialists needed a way to hold the entire system in their head at once, without needing a LIDS engineer to explain it to them.
Access investigations rarely stop at one machine. Users can search a new hostname directly from the detail page, without navigating back or losing context. The tool stays out of the way of the investigation.
Jump to Another Host
Impact
03
Why this matters.
Metric
Before
Projected
Average investigation time
~30 min via SNOW
~2 min
SNOW tickets for access lookups
Ongoing
Zero
Teams able to self-serve
1 (LIDS only)
3 (Auditors, DevOps, App Security)
Linux access visibility
Config files + specialists
1 platform, all layers
Reflection
04
What I’d take forward.
Security tools don't fail because the data is wrong. They fail because the interface assumes you
already know. Self-service in enterprise tools isn't a UX goal. It's a trust problem. The platform
has to be confident enough that users stop second-guessing the answer and reach for the tool
instead of a ticket. Getting there meant not just exposing the data, but designing how it would be
understood by someone encountering it for the first time.
Policy Visualiser
Don't wanna read? Listen my story!!
Policy Visualiser is Walmart's internal platform for understanding who has access to which Linux machines. It surfaces every policy, hostgroup, and user assignment from a single hostname search.
Role:
UX Designer II
Duration:
3-4 months
The Challenge
01
How might we make Linux access visible to everyone, without requiring a security expert?
Linux access at Walmart flows through layers: machines belong to hostgroups, hostgroups inherit access policies, and policies define which AD groups and individual users can log in. The model was complete and accurate. It just wasn't readable by anyone except the engineers who built it.
Every access question required a ServiceNow ticket, an assigned LIDS engineer, and up to 30 minutes of manual config parsing. Three teams had read access and no path to answers. One team had all the answers and no time to keep giving them.
Solutions
02
Hostname search
One input. No ticket, no wait.
Every user had the hostname. Nothing else could be assumed, so nothing else was required. This was the entry point that made everything else possible.
Host Details Page
All policies for a host in one place, each showing its hostgroup assignment and status. What used to take 30 minutes of manual parsing now took a glance.
Spot Common Users Across Policies
Auditors were manually cross-referencing SNOW responses to find over-permissioned accounts, a process that took multiple lookup cycles and introduced reconciliation errors. This feature surfaces that view in a single click. The work that once required a ticket queue now requires a row selection.
Map View
The access hierarchy (host, hostgroup, policy, user) is abstract until it is spatial. The map view was not added for visual appeal. It was added because non-specialists needed a way to hold the entire system in their head at once, without needing a LIDS engineer to explain it to them.
Jump to Another Host
Access investigations rarely stop at one machine. Users can search a new hostname directly from the detail page, without navigating back or losing context. The tool stays out of the way of the investigation.
Impact
03
Why this matters.
Metric
Before
Projected
Average investigation time
~30 min via SNOW
~2 min
SNOW tickets for access lookups
Ongoing
Zero
Teams able to self-serve
1 (LIDS only)
3 (Auditors, DevOps, App Security)
Linux access visibility
Config files + specialists
1 platform, all layers
Reflection
04
What I’d take forward.
Security tools don't fail because the data is wrong. They fail because the interface assumes you
already know. Self-service in enterprise tools isn't a UX goal. It's a trust problem. The platform
has to be confident enough that users stop second-guessing the answer and reach for the tool
instead of a ticket. Getting there meant not just exposing the data, but designing how it would be
understood by someone encountering it for the first time.