Walmart Experience Quality Strategy • 2024-2026
Associate Experience Portfolio Strategy
I turned a fragmented, roughly 80-touchpoint associate-experience portfolio into a visible decision system, helping teams prioritize accessibility risk while giving leadership a scalable model for where deeper support and investment would create the most value.
One Reorg and a Portfolio That Grew Overnight
- 3 grew to 5
- Teams
- 16 grew to 70+
- Designers
- ~10 grew to ~80
- Touchpoints
- 1
- Decision system
Problem
The portfolio grew faster than the support model.
After a reorganization, Associate Experience became one large portfolio with roughly 80 digital touchpoints, 70+ designers, and no shared view of accessibility risk.
Business Problem
Leadership could not compare risk, timing, ownership, or investment needs across the portfolio.
User Problem
Associates depended on workflows with uneven accessibility visibility, including required and high-stakes experiences.
Operating Problem
Support was fragmented: some teams had help, some had never been assessed, and the escalation path was unclear.
The real issue: this was not a compliance backlog. It was a decision-system problem.
Role
I built the system that made the portfolio visible and actionable.
I was responsible for creating an accessibility strategy for a newly expanded Associate Experience portfolio with limited budget, limited specialist capacity, and little consistent accessibility coverage in place.
- Built the roughly 80-touchpoint inventory and first-pass assessment model so leadership could see the portfolio as a system.
- Interviewed portfolio directors to surface ownership, timing, risk, and business context that the inventory could not show on its own.
- Defined criteria for comparing accessibility risk across unlike products, workflows, public surfaces, and shared systems.
- Created baseline and funded support lanes so every team had a floor, and higher-risk work had a path to deeper help.
- Mapped the triggers that could move work between lanes: executive priority, major initiative timing, immediate need, shared-system impact, or elevated user and legal risk.
- Owned most next actions as the accessibility lead, with joint ownership when the next step required product, design, engineering, or broader accessibility support.
- Framed the strategy in language leaders and teams could use to understand why support was going deeper in some places and staying lighter in others.
Success
Better decisions, not a bigger audit report.
The work was still in progress when business circumstances changed, so I measured success by whether the organization could see, compare, and route risk more clearly. The strategy made risk visible and actionable for planning; it had not yet completed a long-term remediation or risk-reduction cycle.
Visible Portfolio
Roughly 80 touchpoints became one decision surface instead of scattered requests and partial memory.
Capacity Signals
Leadership gained shared criteria for seeing where future budget or specialist capacity would be needed.
Support Floor
Every team had baseline expectations, practical design guidance, and a route to escalate when risk changed.
Early Signal
Workplace incident and claims moved into funded support after a director conversation and design review surfaced risk the first portfolio read had missed.
Proof point: In the early group-design view, Workplace incident and claims did not get much weight because it was not one of the most visible priorities. A later director conversation added context the inventory and prior design discussions had not surfaced: the flow carried higher legal and associate-impact risk than its visibility suggested.
A follow-up design review confirmed the concern, and the model gave me a way to move the touchpoint into funded support. The risk was made visible and routed; it had not yet been reduced or avoided.
Approach
Make the landscape visible, then make the choices discussable.
I used a deliberately lightweight assessment to find the signals that should change attention, support, or funding. Director conversations added the context the inventory could not show on its own.
See it in action
The original tool lived in Airtable. The file below is a representative 19-row, portfolio-safe reconstruction of the larger roughly 80-touchpoint model.
Explore the touchpoint inventory and linked views
Leadership Report
The report made the portfolio easier to discuss.
The working inventory helped me maintain the model. The report was the leadership view: one page for portfolio composition, support capacity, decision signals, planned funded work, and watchlist decisions.
This public-safe version is more polished than the working report I had at the time, but it uses the same model and planning logic. It shows the next step for the work: raw inventory data becoming a report leaders could use in planning conversations.
The wireframe shows the operating tool. The report shows what leadership needed to see.
Tradeoffs
The model had to be useful before it was perfect.
The important choices were about proportional effort: enough structure to guide investment, without pretending the inventory was a full audit, a fixed roadmap, or an automatic funding engine.
Broad First Pass vs. Deep Audit
I chose breadth first. A deep audit of 80 touchpoints would have stalled; a first-pass inventory made the portfolio actionable.
Provisional Roadmap vs. Perfect Plan
The new organization's priorities were still forming, so I used known work, prior team context, director input, and active change windows as planning signals.
Public-Safe Story vs. Internal Detail
The case study uses reconstructed artifacts and representative examples so the method is visible without exposing confidential portfolio data.
Two-Lane Support Model
I separated the portfolio into two lanes so every product had a floor, while higher-risk work had a path to deeper help.
Baseline Support
The default lane for every product.
- minimum accessibility expectations
- designer training, reusable guidance, and lightweight checks
- tools and resources for diagnosing issues earlier
- office hours and an escalation route
Funded Support
Deeper help for higher-risk or higher-impact work.
- deeper design review and third-party annotation review
- manual testing or assistive-technology review when proportionate
- remediation follow-through and checkpoints
What moved work: risk or timing changed the lane: public exposure, required journeys, elevated user or legal risk, major initiative timing, shared-system impact, or leadership priority. Product teams and designers could also escalate when a new flow changed the risk picture.
What changed over time: net-new work would enter the model by default, and baseline items could be remediated over a few sprints, a later release, or a future planning window depending on risk and timing.
How scale stayed possible: this built on the accessibility champions program, which moved first-pass knowledge and escalation awareness into teams instead of depending on one specialist to hold every decision.
Collaboration
The model got better when partner context changed the picture.
I used the inventory as the starting point, then checked it against partner conversations and evidence the data could not explain on its own.
Business
Used the portfolio view to show where priority decisions would need budget or specialist capacity. When priorities reset, the model still made the tradeoffs visible.
Product
Tied risk to roadmap timing, ownership, active change windows, and escalation triggers while the new organization's priorities were still forming.
Design
Turned accessibility expectations into design practice: training, annotation guidance, reusable patterns, and review criteria designers could use before handoff.
Engineering
Showed where engineering would likely need clearer requirements, training, and the right level of testing or third-party review.
Research and Data Signals
Used audience, reach, support, and journey evidence as a check on volume and visibility, so the model did not prioritize the loudest or largest surface by default.
Why that mattered: the highest-risk signal in the work came from a director conversation, not the initial inventory.