Walmart Global Sourcing · QC-x
Checking thousands of supplier quotes without reading them
Walmart’s sourcing teams validated supplier quotes and line reviews by hand — analysts eyeballing spreadsheets for pricing errors, missing certifications, and policy violations across six international markets. I led design for QC-x, the tool that turned that manual review into rule-based, scheduled, auditable checking. Less a screen redesign than a workflow redesign: compliance and exception management for people whose mistakes ship in containers.
- Role
- Lead Product Designer — QC-x, end to end
- Team
- 1 designer · 1 PM · 5 engineers
- Duration
- 2019 – 2021 · within Walmart Global Sourcing
- Platform
- Web · internal enterprise tooling
6
international sourcing markets running on one ruleset tool*
75%
review time saved per line review vs. the manual process*
100%
of checks documented and repeatable, replacing ad-hoc review*
* Measured against the manual spreadsheet baseline across sourcing line reviews; the automated process replaced roughly four full-time employees' worth of manual checking.
Manual review doesn’t scale, and it doesn’t defend itself
A line review can run thousands of rows: unit costs, freight terms, certification fields, packaging specs. Analysts checked them in spreadsheets, each with private heuristics about what to scan first. The volume guaranteed misses, and every miss had a shape — a pricing error that survives into a purchase order, a missing cert discovered at customs.
The deeper problem was accountability. When a check lives in someone’s head, you can’t prove it happened. Sourcing operates under audit, and “our best analyst usually catches that” is not an answer a compliance review accepts. The tool had to make checking faster — but just as importantly, it had to make checking demonstrable.
What made it hard
Three kinds of users, one tool
Merchants submitting data, sourcing analysts running checks, and managers answering for the results. Each needed a different slice — submission clarity, exception speed, audit reporting — without the tool fragmenting into three products.
Rules written by non-engineers
The people who knew the policies were analysts, not developers. If creating a rule required a ticket to engineering, the tool would die — rulesets had to be composable in business language by the people who own the policy.
Every department’s data looked different
Six markets, dozens of departments, each with its own line-review format. The checking engine needed structured input from a world of unstructured spreadsheets — the central tension the whole design hung on.
The decisions that made it stick
Fixed templates first — flexibility was the enemy of v1
We considered accepting each department’s native spreadsheet and parsing it — maximally friendly, and we killed it: the variance was unparseable, and silent mis-parsing in a compliance tool is worse than no tool. We shipped fixed downloadable templates instead, accepting real onboarding friction and grumbling. Once checking proved its value, I designed template customization in v2 — letting departments adapt fields within constraints the engine could still validate. Sequencing the flexibility, rather than promising it upfront, is why the engine stayed trustworthy.
Rules read like policy, not like code
The ruleset builder composes conditions the way an analyst states them — field, comparison, threshold, severity — so the person accountable for a policy is the person who encodes it. No engineering ticket, no translation loss, and when a regulation changes, the rule changes the same day.
Reports became scheduled infrastructure, not requests
V1 made checking possible; the rhythm of sourcing made it repetitive. I designed scheduled reports against previously uploaded files — checks that run on cadence and land in inboxes with violations grouped by severity. The exception-management pattern again: the system does the sweep, humans handle only what it flags.
Outcome: checking as a system property
Review went from hours of spreadsheet scanning per line review to minutes of exception handling*, and — the part the compliance organization cared about most — every check became documented and repeatable. “Did we verify this?” changed from an interview question into a query.
QC-x also outgrew its origin: the ruleset-plus-exceptions pattern I designed became the reference for how other Global Sourcing tools approached validation, and the v2 template customization work pointed toward retiring the download-a-template step entirely. It’s the project where I learned the shape of enterprise trust — boring, auditable, and earned in v1 before you ask users to absorb flexibility in v2.
“Did we verify this?” changed from an interview question into a query.
What this project taught me
In compliance tools, false confidence is the worst failure
A missed check is bad; a wrongly passed check is worse, because it carries the system’s endorsement. That asymmetry drove the fixed-template decision and most severity design — when in doubt, the tool flags rather than passes.
Sequence flexibility, don’t promise it
Shipping the rigid version first felt user-hostile and was right. Users forgave v1 friction once the value was proven, and v2 customization landed on an engine that had earned the trust to absorb it.
The audit trail is a user need, not a checkbox
I went in thinking documentation requirements were bureaucratic overhead to minimize. The managers taught me otherwise — provability was the product for them. Designing for the person who answers the auditor changed how I weigh invisible requirements everywhere.