Walmart Experience Quality Strategy · 2024–2026

Touchpoint portfolio strategy

I built one decision system for roughly 80 touchpoints, so accessibility support could follow risk rather than visibility. A reorganization had just put all of them under one organization, and the support model that came with them had been built for a fraction of the work.

Two phones at an angle, each showing a Walmart product. On careers.walmart.com, a staff pharmacist posting in Palm Springs Village, Florida, with an Apply now control. On walmart.com, the Spark Good page headed "Organization resources designed for you", describing local grants and a space request tool for nonprofits.

Snapshot

70+: Designers in the new organization
5: Portfolio directors, each interviewed
2: Support lanes

Role: Accessibility lead for the Associate Experience portfolio, working against limited budget and limited specialist capacity.
Team: A contracted accessibility service did most of the manual testing, documented defects, and joined design reviews. The product, design and engineering teams across the portfolio did the work itself.
I owned: The touchpoint inventory, the first-pass assessment, the comparison criteria, the two support lanes, the rules that moved work between them, and the leadership readout.

Problem

The portfolio grew faster than the support model

After a reorganization, Associate Experience became one portfolio. Many of its products were newly combined into it, and some were entirely new to the teams now responsible for them. Working out what was actually in the catalog took a while.

~10 grew to ~80: Touchpoints, before and after the reorg

Leaders had no way to compare one product to another

Risk, timing, ownership and investment need were all knowable one product at a time. Across the portfolio there was no way to say which mattered more, so no way to decide where help should go.

Associates could not opt out of required workflows

Associates depended on workflows with uneven accessibility visibility, including required and high-stakes experiences. When a journey is required and has no alternate path, a problem inside it is not something a person can route around.

There was no route from a risk to help

Support was fragmented. Some teams had it, some had never been assessed, and there was no clear way to escalate when something changed.

None of that is a defect problem. The portfolio needed a way to decide.

Two products from the portfolio open in a phone browser, side by side. On the left, careers.walmart.com, headed "Cashiers wanted. Next move, yours." over a search field and a carousel of associates. On the right, walmartsustainabilityhub.com, a photograph of a wind farm above a panel headed "Together our future is bright" and a paragraph about supply-chain sustainability.

Success

A director had to be able to choose between two products

The work was still in progress when business circumstances changed, so I set the bar at whether the organization could see, compare and route risk more clearly than it could before. The test was concrete: could a director look at a careers site and a claims workflow and say which one needed support first, and give a reason for it.

Reduction was not available as a measure. No accessibility-defect baseline existed across the portfolio, the first pass was deliberately high level, and the automated checks I ran were directional input into the current-state picture. What the strategy could do was make risk visible and give planning something to work from. It had not completed a remediation or risk-reduction cycle.

Figure: Two of the portfolio’s products, both public. A careers site and a supplier sustainability hub have different audiences and different stakes, and nothing in common to rank them by until the inventory asked both the same questions.

Role

My manager suggested a gap analysis; I built the model

The prompt was one sentence from a new manager: run a gap analysis. I scoped and drove everything past that, because a gap analysis across this many products would have produced a list nobody could act on. What was missing was not a list of gaps. It was a way to rank them.

Built the touchpoint inventory in Airtable myself and ran the first-pass assessment across all of it.
Interviewed each portfolio director about the work they might own after the reorg, what it reached, and how exposed it was.
Defined the criteria for comparing accessibility risk across products, workflows, public surfaces and shared systems.
Owned most next actions as the accessibility lead, with joint ownership where the next step needed product, design, engineering, or broader accessibility support.

I built the route from scattered products to an actionable list

Walmart Touchpoints: Flow Wireframe. Nine stages, from collecting every touchpoint to the prioritized list.

Touchpoint Inventory

Every touchpoint had to answer the same questions

A shared design sub-system, a public careers site and an internal claims workflow have almost nothing in common. They become comparable the moment you ask all three the same questions.

So the inventory asked the same ones of everything: what type of touchpoint it is, where it sits in its lifecycle, who uses it and how many of them, whether it contains an essential journey with no alternate path, what remediation was already running, what redesign was coming, and what design system and stack it was built on.

I kept a fuller version behind the scenes and put only the decision-relevant fields in front of designers. The whole model would have been more information than anyone needed to answer the question actually in front of them.

Touchpoint inventory table. Each row is one touchpoint; the columns are audience and reach, journey protection, risk signals, risk-and-impact result, lifecycle, accessibility support lane, active intervention, and next action. — The inventory as a working view. The fields on screen are the ones a support decision actually turned on. Links to the Associate Experience portfolio prototype.

Collaboration

Director interviews moved the list further than the inventory had

I started from the inventory and then checked it against people. Each portfolio director met with me one on one and talked through the work they might own after the reorg, what it reached, and how exposed it was. Their portfolios were not final yet, which is exactly why the conversations were worth having early.

One touchpoint could not wait and could not be skipped

A director flagged the Workplace incident and claims touchpoint. Someone reports an incident when it happens, not when it suits them, and the whole point of the tool is that it cannot be routed around. My inventory had a field for whether a journey was required. It had none for what the person filing was going through. It was also preparing for high-impact new functionality, which made it a good moment to build accessibility into the work rather than after it. In months of project discussions, that product had never once come up.

The group director set which public products came first

I ranked by what the inventory could see. The group director’s guidance on which public products should be pulled up came from context the fields did not carry, and it decided the top of the list.

Approach

I protected essential journeys before scoring anything else

The model has two layers. First, anything that is a required journey with no alternate path is protected. Then all the rest get compared on the same seven factors.

A single severity ranking would have been simpler to build and easier to explain in a meeting. It would also have made a legal floor negotiable against a score, and sooner or later something required loses that argument to something visible. The two layers cost me that single ranking. They buy a floor nothing has to argue with.

Two-layer prioritization

Layer 1 · the gate

Is it a required journey with no alternate path?

This layer does not take arguments.

Funded support, without being scored
Layer 2 · the score

All the rest get compared on the same factors.
- reach
- reusable patterns
- shared-system impact
- complexity
- known history
- leadership priority
- upcoming redesign timing
funding capacity draws the line

Above the line, funded support. Below it, nothing moves.

Underneath both layers

Nothing falls out of the model.

Baseline support.

The gate comes before the score. Everything below the gate is comparable; nothing above it is.

Every product got a floor; risk decided who got more

Baseline support: The default lane for every product.

minimum expectations

designer training and reusable guidance

lightweight checks

tools for finding problems earlier

office hours

a route to escalate
Funded support: The deeper lane for higher-risk or higher-impact work.

deeper design review

third-party annotation review

manual or assistive-technology testing where it was proportionate

remediation follow-through with checkpoints

One team asked for the other model outright: audit us, hand us a fix list. I did not do it. An audit fixes a snapshot, and everything in this portfolio was still being built, so the same defects come back in the next release with a different line number. The tradeoff is real, though. A fix list is something a team can finish. Capability is something they have to keep doing.

Changing a priority had to leave a record

Executive priority, a major initiative, an upcoming redesign, immediate need or shared-system impact could all move a touchpoint. I wrote those triggers into the model rather than leaving them as exceptions someone made quietly. A priority that changes because a leader wants it changed is ordinary in an organization this size. A priority that changes with nobody able to see that it changed is how a model stops being trusted.

Product teams and designers could pull the same lever when a new flow changed the risk picture.

A single touchpoint record. A signals and assessment panel lists the risk signals, the risk-and-impact result, a written risk rationale, a risk override field, an override rationale field, and the final risk assessment. A support decision panel lists the support lane, the funding rationale, the named decision owner, the delivery window, and the next checkpoint. — Every support decision recorded its reason, its owner, and the place where someone could argue with it.

The model had to work without me in every review

The first pass itself was deliberately light. I ran selected web touchpoints through automated checks for directional signal about current state and team maturity, and it mostly confirmed what was already known about the highest-priority projects. Audience, reach, support volume and journey evidence went in the same way, as a check on the model rather than as its input, so the largest and loudest surfaces did not win by default. That was enough to sort a portfolio.

Net-new work entered the model by default. Baseline items could be remediated over a few sprints, a later release, or a future planning window, depending on risk and timing.

Designers could hold most of the baseline themselves because of earlier work. Inclusive Design Before Development had already put the common accessibility risks into their hands before handoff, so the model did not depend on one specialist being in every review.

Tradeoffs

The deep columns stayed empty on purpose

The choices worth writing down are the ones about proportion: how much structure the portfolio needed to guide investment, without pretending the inventory was a fixed roadmap or a machine that produced funding.

The inventory’s deeper columns, the full signal set, the risk scores and the support decision, were left unfilled on purpose. Leadership was still assembling its post-reorg project list, and portfolios were still moving between directors. Any depth I added before that landed was depth I would have had to redo. The database looked spotty for months. That was cheaper than being precise about the wrong products.

I aimed the deepest support at work not yet built

If a touchpoint was going to be completely redesigned or restructured in the coming fiscal year, deeper support was planned for that window rather than spent on the current-state experience. Accessibility built into a rebuild stays. Accessibility retrofitted into something about to be replaced goes out with it.

The cost is that current-state risk sits there longer, and on a workflow people use every day that is a real cost. It is also why the essential-journey layer sits above this rule and not under it.

I planned against priorities that were still forming

The new organization had not finished deciding what it was working on. Waiting for that would have meant arriving with a plan after the planning was over, so I used what was already knowable: work in flight, context from the teams that had owned these products before, director input, and active change windows.

It is a first draft and it says so. I would rather defend a first draft than present a finished-looking plan built on guesses.

Leadership Readout

I gave leaders a ranking they could argue with

The working inventory was the tool I maintained. The readout was the version leadership saw: one page, updated as things moved. It named the priority focus areas, tracked projects against budget coverage, hours and status, and carried a design gate as the floor every project had to clear whether or not it was on the list.

It framed accessibility as an experience-quality problem at the platform level rather than a queue of defects inside individual products. Three principles held it together:

Accessibility is experience quality.
It gets operationalized by design rather than by specialists.
Design systems are where you solve something once for everything downstream.

The third one needed its counterweight stated in the same breath, because an accessible component library was being read as an accessible product. Flow-level accessibility breaks in the joins: icon choices, missing labels, patterns adapted past what they were built for, components combined in ways nobody tested, and sub-systems the main design system never accounted for.

The readout did not decide anything. Leadership already understood that the combined organization would need more accessibility support than it had, and that was true before I wrote a line of this. What the readout did was put the whole landscape on one page in a defensible order, so the argument about where support should go could happen over something specific.

A one-page leadership readout. A portfolio composition band gives the touchpoint total and splits support capacity between funded and baseline, with a watchlist count. A decision signals band counts public-facing surfaces, essential journeys, surfaces with no alternate path, and upcoming redesigns, plus audience reach at three levels. A planned funded work table lists each funded touchpoint with its current support context and planning treatment. A closing band lists the leadership decisions the view is meant to surface. — The leadership view: portfolio composition, support capacity, decision signals, planned funded work, and what was on the watchlist. Links to the AX accessibility support report.

Outcome

One item on the list moved because of the model

The scattered projects became one ordered list people could point at. One item is a small result. It is also the part that proves it worked.

A touchpoint my first read underweighted reached the funded list

First read

In the early group-design view, the incident and claims touchpoint did not get much weight, because it was not one of the visible priorities.
New context

The director conversation added the legal and associate-impact context the inventory had no field for.
Confirmation

A follow-up design review confirmed the concern.
Mechanism

The movement rules gave me a defined way to move it into funded support rather than an exception to argue for.
What changed

It entered funded support.

The risk was made visible and routed. It was not reduced or avoided.

Every team had a floor, funded or not

Baseline expectations, practical guidance and a route to escalate applied across the portfolio, not only to the funded part of it. That is the piece I would defend hardest, because it is the part that does not depend on anyone’s budget surviving a planning cycle.

Evidence

Demand showed up before the model was finished. Teams already in the funded lane asked for material they could hand to peers who were not, and for help making the case that accessibility takes more time before handoff rather than after it. Nobody asked for that material before the model gave them a lane to point at.

Limit

Leadership’s post-reorg project list never landed before my involvement ended. The deeper half of the assessment was never completed, and the model never ran at full portfolio scale. What existed at the end was the inventory, the two lanes, the movement rules, the readout, and one touchpoint routed through all four.

If I were setting this up again

I would fix the first-pass rubric to a small number of factors and publish it before collecting anything, so the criteria were arguable on their own before any product was scored against them. The prioritization logic is the part I took with me: it is how I define per-product accessibility support in the system I am building now.