Walmart Associate Experience · 2024–2025

From One Reviewer to a Quality Decision System

UX Operations Design Governance Quality Systems Accessibility Leadership Operating Models

I turned a one-specialist design-quality bottleneck into a repeatable decision system for routing risk — helping my product group triage severity, route remediation through a shared severity structure, and turn recurring accessibility issues into shared standards and training, instead of routing every judgment call through one person.

What Ran Through the Model

4: Review tiers
44: Defects remediated · point-in-time
6 grew to 8: Training sessions from real defects
1: Decision system

From a Single Queue to a Routing System

From one review queue to a risk-routing system. On the left, many design-quality items all funnel into a single specialist and pile up in one backlog queue. On the right, the same items are routed by risk across four review tiers - self-review for low-risk work, peer or champion review, design review by the SME team, and leadership escalation for high risk - feeding a loop where defects become standards and training and then better reviews. — The same quality work stopped piling up in one queue and started moving through a risk-matched routing system that fed its own improvement loop.

One Specialist Can’t Be the Whole Quality System

As accessibility adoption grew across my product group — three product teams and sixteen designers — the biggest risk was no longer a missed defect. It was organizational: every review, every question, and every judgment call routed through one specialist. That model hides quality risk until late in delivery, slows teams down, and keeps hard-won knowledge locked in one person’s head.

The visible problem looked like a review backlog. The real problem was that the organization had no shared way to decide which issues were urgent, which were pattern problems, and which needed a leadership tradeoff — and no way to hold quality steady if it kept depending on me. That’s a governance problem, not a throughput problem.

I Reframed “Review More Work” Into “Design How Quality Decisions Move”

Instead of trying to review my way out of a backlog, I designed the decision system that quality work should move through: who looks at what, how much scrutiny each piece earns, how severity gets named, and how a recurring issue becomes a permanent fix. The goal was to match review depth to risk — let low-risk work move quickly, and reserve expert and leadership attention for ambiguity, cross-system impact, and real tradeoffs.

That reframe is the whole shift: from a specialist doing more reviews to an operating model that could route risk without me sitting in the middle of every call.

The Loop Was the Product

The value wasn’t any single artifact — it was how they reinforced each other. Reviews surfaced defects. Defects got a shared severity language. Recurring themes drove documentation, patterns, and training. Training improved the next round of reviews. A tiered path decided how far each issue traveled, and standards lived in Figma and Confluence — the team’s go-to places for information — so guidance sat where designers actually worked.

The design-quality feedback loop: a repeating five-stage cycle. Tiered reviews surface defects; defects get a shared severity language; recurring themes are identified; themes drive standards and training; and that produces better next reviews - which feeds back into the start of the cycle. — Reviews → defects → recurring themes → standards and training → better reviews. The loop, not any one document, was the real deliverable.

The two mechanisms inside the loop: tiered review and shared severity

A four-level review path matched depth to risk. Self-review ran anytime, AI-assisted. Peer review happened inside each team, where an embedded accessibility champion took the first pass — answering what they could and routing harder calls to me as SME — before work reached the design review (SME team), where design and accessibility experts critiqued together against a shared rubric — design heuristics, UX laws, accessibility, and copy standards — and leadership escalation when risk or tradeoffs were significant. Building and training those champions is its own effort — see the Accessibility Champions Program.

A shared severity language made triage less personal. A defect-severity model with P1/P2 prioritization standards let teams classify and route issues consistently, instead of negotiating urgency by personal judgment. At a point-in-time snapshot, 34 of the 44 tracked defects were documented through this consistent structure.

An explicit AI line. AI could draft findings and Jira-ready structure; humans validated priority, owner, and final acceptance. Exercised on real defects, never a scaled production workflow.

The Proof Was the Loop Closing on Itself

The clearest evidence the system worked wasn’t a review count — it was the loop feeding forward. The system’s own defect data showed which issues recurred most, and I built training directly from them: a focused series of six sessions in 2024, structured around the five most common accessibility defects, expanded to eight sessions in 2025 as the patterns evolved. That’s the mechanism closing — recurring defects becoming prevention, not just another round of one-off cleanup.

In one review, the same shared language stopped a team from building a new pattern to solve a local problem, redirecting them to an existing component instead — preventing design-system debt before it shipped.

What I Designed and Led

I was the accessibility design lead, and I authored the system hands-on — not by delegation:

the four-level review path and its escalation criteria
the defect-severity model and the P1/P2 prioritization standards used in triage
the standards hub — annotation expectations, review guidance, and pattern documentation — in Figma and Confluence, the team’s go-to places for information
a reusable standards corpus — taxonomy, checklists, remediation guidance, templates, and verification protocol — that externalized the judgment behind the reviews
the AI-intake governance rule: AI drafts, humans validate priority, ownership, and acceptance
the KPI framework’s categories, built to measure earlier detection, prevention, and ownership rather than raw bug counts
the annotation and QA reviews counted in the operating snapshot

What Changed, and What I’d Measure Next

The strongest outcome was a durable capability, not a cost or defect-reduction figure: the group gained a repeatable way to route design-quality risk, name severity in a shared language, and turn recurring issues into standards and training — instead of depending on one specialist to hold quality together.

Measured, point-in-time: 27 design handoffs, 25 annotation reviews, and 3 formal QA reviews ran through the model; 44 audited defects were tracked and remediated, 34 documented through the shared severity structure; and the defect data generated a training series that grew from six sessions to eight. Uptake: the severity structure was actually applied to most tracked defects, and the loop produced curriculum that was delivered and expanded — the system was reached for, not just built.

An honest boundary: Distribution started where I could verify it: on the 16-designer team, two accessibility champions took the first pass on reviews and eventually owned the accessibility-annotation review I used to run. What I held onto was SME judgment and escalation — I hadn’t yet built a way to trace review quality and correct drift across the whole model, so I wasn’t going to release that part into invisible risk.

What I’d operationalize next: I designed the measurement model around the questions that matter — were defects caught earlier, did severity decisions stay consistent across reviewers, which recurring issues fell after documentation or training, and did high-risk issues reach leadership before tradeoffs got expensive. It never reached a live reporting cycle before I rolled off; that’s the first thing I’d stand up taking it forward.