Walmart Global Tech

Project Greenhouse

Home team: AXCF, Walmart
Role: Product designer and builder, end to end, solo with Claude Code
Timeline: Jul–Oct 2026 · 4 phases · 24 merged PRs · v1.5.0
Platform: Claude Code, run in Wibey · Living Design · React + React Native

Design systems
AI tooling
Handoff
Content design

TL;DR

AI tools let designers across Walmart build working prototypes in minutes. But the output drifted off Living Design, and engineering threw it away and rebuilt from scratch. I designed and built Greenhouse on my own, with Claude Code, as a guardrail and handoff toolkit for the whole design organization.

01Teaches the AI the design system's rules.
02Catches drift without the designer reading code.
03Hands engineering a prototype they can merge, not rebuild.

26.8 → 0

Design-system violations

Same prompt, 5 runs each

Research result

Merged PRs

Realized

Releases in the hardening phase

Realized

Platforms, web and mobile, from one toolkit

Realized

The starter prototype every Greenhouse project begins from

01 · Context

Built in AXCF, designed for the whole org

Greenhouse is for every designer in Walmart's design organization: commerce, associate tools, internal operations, web and mobile. It couldn't assume a product, a platform, or a backend. I stress-tested it in my home team, Associate Experience Corporate Functions, which designs the internal tools that keep corporate functions running.

Associate tools
ReimburseMe (expense reimbursement)
Procurement
GNFR Invoicing, GNFR Ordering, iCatalog
Claims
Claim Services: incidents involving associates and customers
Finance
Digital accounting, financial reporting, corporate reporting

Data-dense, high-stakes

A missing error state means a reimbursement is not filed or a claim stalls.

A broad audience

From every associate to claim managers and accountants. Accessibility and plain language are requirements.

Many backends

A prototype that assumes one backend is useless to the other teams.

Consistency compounds

Associates move between these tools in one week. Every off-system button erodes trust.

02 · Problem

Fast prototypes, wrong foundations

AI coding tools changed who can build UI. Designers began producing real, running prototypes in Claude Code, which Walmart runs through its internal tool, Wibey. Greenhouse runs there too. Three things broke.

01
The output wasn't on-system
Raw HTML controls, hardcoded colors, and components that don't exist in LD, like a FilterChip or a Ghost button. Inline style= on LD components is silently stripped: the styling vanished, with no error.
02
The builders couldn't see it
Designers can't review a diff for "is this a real LD Button?" Drift reached the screen unnoticed, then reached engineering.
03
Handoff was a dead end
Even good-looking prototypes faked data, skipped loading and error states, and guessed at a backend. Engineering's only option was to rebuild.

Unguarded AI code with off-system lines highlighted, beside the Greenhouse drift-check output that flags each one — What an unguarded AI writes, and what the checker says about it

Reframing

How might we make the on-system path the default, make drift visible to someone who can't read code, and make a designer's prototype something engineering can merge?

03 · Audiences

Three audiences, one tool

Most design tools have one user. Greenhouse has three, and each needed a different interface. Treating the AI as a user changed the content design: the rules had to be written for a reader that is confident, fast, and prone to inventing things.

Non-coders

Designers

Needs

Set up without a terminal, know when something is wrong, know when they are done.

Designed

A plain-language guide, one-command setup, a 0–100 readiness score.

Claude Code

The AI

Needs

Accurate, current rules, and something that fails when it ignores them.

Designed

A generated rulebook in its context, plus lint and drift checks.

Receiving teams

Engineers

Needs

A prototype that matches their stack and does not pretend to be the backend.

Designed

Version parity with their repo, a backend-neutral data contract, a handoff doc.

04 · Process

Four phases, July to October

01
Scaffold
July
A script that installs LD, writes a rulebook into the AI's context, and checks for drift. Setup routed through Claude Code, not the terminal.
02
Encode judgment
September
A Badge used as a status label is on-system but wrong. Added a tier of judgment rules ported from the internal design kit.
03
Production parity
October
React Native, a data layer, navigation, an accessibility scan, the Handoff Readiness score, and a moderated pilot kit.
04
Harden & release
October
11 versioned releases in two days, driven by Apple silicon, yarn and pnpm repos, and corporate security policy.

05 · Decisions

Ten key design decisions

Decision 01 / 10

Generate the rules, don't write them

Problem: A hand-written list of allowed components goes stale with the next upgrade, and the AI confidently uses props that no longer exist.
Decision: Greenhouse reads the installed package's own types at setup and generates the component inventory, deprecated props, required props and allowed values. Running setup again rewrites the block in place.
Why it matters: The rulebook is always true for the exact version installed. That accuracy is what makes the AI, and engineering, trust the output.

Decision 01 / 10

Generate the rules, don't write them

Problem: A hand-written list of allowed components goes stale with the next upgrade, and the AI confidently uses props that no longer exist.
Decision: Greenhouse reads the installed package's own types at setup and generates the component inventory, deprecated props, required props and allowed values. Running setup again rewrites the block in place.
Why it matters: The rulebook is always true for the exact version installed. That accuracy is what makes the AI, and engineering, trust the output.

Decision 02 / 10

Separate facts from judgment

Problem: Mixing "this prop doesn't exist" with "this layout feels off" weakens both. The AI treats everything as a suggestion.
Decision: Two tiers. The first is labeled correctness fact. Then four judgment calls: choose components by meaning; start at the highest composition level that fits; keep vertical rhythm on fixed tokens (32 / 48 / 24 / 16px); check media at the narrowest column.
Why it matters: "Everything above this section is a correctness fact… These four are judgment calls."

Decision 03 / 10

Make the AI disclose, not improvise

Problem: A silent repurpose looks fine in the prototype and breaks in production. TabNavigation as bottom nav renders with page-navigation tokens.
Decision: Before repurposing any component, the AI has to raise the mismatch unprompted.
Why it matters: The designer stays in charge of design decisions. The tool surfaces trade-offs instead of hiding them.

Decision 04 / 10

Resolve the look-alikes

Problem: The common mistakes were confusable real components: Alert vs. Banner vs. Snackbar, Button vs. Link vs. IconButton, Tag vs. Chip.
Decision: Seven component-choice groups, each worded from that component's own LD documentation. Three common misuses fail lint: an Alert with a close button, a clickable Tag, a Link with nowhere to go.
Why it matters: Choosing by meaning is enforced, not suggested.

Decision 05 / 10

Hold a higher accessibility bar

Problem: Passing contrast is a floor, not a standard.
Decision: On Walmart blue, text is always white, even where the ratio technically passes. Rulebook, drift check and the axe-core scan (WCAG 2.1 A/AA) all enforce it, across every screen in normal, empty and error states. It reuses the browser already on the Mac.
Why it matters: A violation blocks handoff.

Decision 06 / 10

Show the states real apps have

Problem: Prototypes only show the happy path. Real apps load slowly, fail, and sometimes have nothing to show.
Decision: Add ?scenario=slow, error, empty or save-error to the preview URL to see each state without a backend. Errors are written in plain language and chosen by HTTP status.
Why it matters: An associate with no pending reimbursements, an invoice that failed to submit, a claim list that is slow to load: all visible before engineering starts.

The starter prototype in four states: normal list, slow loading spinner, empty state, and an error banner with a retry link — ?scenario=slow, empty or error, no backend needed

Decision 07 / 10

Never pretend to be the backend

Problem: Every team's backend is different. A prototype that guesses endpoints and auth creates work to undo.
Decision: All data flows through one services layer. Its API file is the contract, with a documented method per call. Sign-in is deliberately not built. The drift check fails on direct network calls or mock-data imports. Before handoff, Greenhouse syncs LD versions, package manager and data libraries with the receiving repo.
Why it matters: "The prototype never pretends to be the backend. It hands over a contract."

Decision 08 / 10

One number for "am I done?"

Problem: Designers had no way to know a prototype was ready without asking an engineer.
Decision: The Handoff Readiness score, out of 100, with hard blockers that stop a handoff whatever the score.
Why it matters: 90+ with no blockers is Ready for handoff.

Hard blockers: No sync with engineering, Failing build, Drift-check failures, Non-white text on blue.

Handoff Readiness terminal output: 90 out of 100, one blocker for version sync, and a bar for each scored category — Real ld-score output from a freshly created project

Decision 09 / 10

Preview mobile in the browser

Problem: Designers should not need a simulator.
Decision: Real React Native screens render in a 430px phone frame. All browser plumbing lives in preview-only files engineering never merges. Even the back-button color was adjusted because the platform default fails WCAG contrast.
Why it matters: Web and mobile from one toolkit.

The React Native starter's item list in a phone frame — The untouched mobile starter in the browser preview

Decision 10 / 10

Content design for non-coders

Problem: Every touchpoint is read by someone who has never opened a terminal.
Decision: "Think of it as handing your AI a rulebook so it doesn't go off-script." 15 troubleshooting rows, symptom to plain fix. IT request text ready to paste. On a security block: "that's the security policy doing its job."
Why it matters: No workaround offered. Routed to IT.

06 · Validation

Does the rulebook work?

Same UI prompt, 5 runs without guardrails and 5 with, using a public design system so the test is reproducible outside Walmart.

Violations per run, without guardrails: 24, 30, 24, 32, 24 (avg 26.8)
Violations per run, with guardrails: 0, 0, 0, 0, 0
Components imported: 7–8 without, 9 with
File length: 305–334 lines without, 287–312 lines with

The guarded runs used more real design-system components in less code.

What I'm careful not to claim

This shows presence, not magnitude. Violations clustered on 5–9 lines per file, and the guarded agent could see the checker. The guarded runs also didn't deliver the custom pill colors the prompt asked for. The rules won over the request: a trade-off to surface to designers, not hide.

Engineering validation

An engineer reviewed a real Greenhouse handoff, built around his own table use case, and confirmed it works. That handoff scored 90/100 on Greenhouse's readiness check. The only gap was syncing with engineering's package versions. His table needs shaped the next two releases, so engineering feedback is already in the product. I also tested it end to end against a production engineering repo. A clean-room smoke test runs before every merge, checking web and mobile: lint, drift, build, version notices, accessibility, a starter score of 90+, and the handoff document.

Moderated pilot (designed)

3 designers, 75-minute think-aloud sessions, from machines with nothing installed.
7 timed tasks: setup, an expense-report list and detail page, screen states, drift check, mobile, handoff interview.
Hint ladder: 2 min "What would you try next?", 5 min scripted hint, then do the step.
Pass bar: 2 of 3 pass core tasks, confidence 4+/5, every project passes drift and build.

"We're testing the tool, not you."

07 · Outcomes

What shipped

design-system violations across all guarded runs, down from an average of 26.8

releases in the final hardening phase, each from a real edge case

platforms, web and mobile, from one toolkit

readiness score that answers "am I done?" without an engineer

08 · Reflection

What I'd carry forward

Designing for an AI reader is content design.

The gains came from making rules accurate (generated, never stale), tiered (fact vs. judgment), and paired with a gate. A rule the AI can ignore without consequence is just a suggestion.

Cut what doesn't earn its place.

I added CI and removed it a release later: with one maintainer and a pre-merge smoke test, it "adds setup without catching anything new." I renamed the project from my initials to Greenhouse so it read as org-wide, and avoided an "LD" prefix so it wouldn't be mistaken for an official design-system product.

Respect the constraints users live in.

Managed Macs, security policy, and no terminal experience were the design brief. Design for the least-configured machine and the least technical user, not the average one.

What I'd do next

Run the pilot and publish results, then roll out beyond AXCF.
Measure a real merged handoff with the receiving engineer.
Run the controlled experiment against Living Design itself, not a public stand-in.