AutoZone Z-net

One platform, running the whole store

Z-net is the actual platform AutoZone's stores run on, not a single app, but a hub for the parts catalog (both DIY and commercial, covering store floor and back of store commercial customers), point of sale, returns, repair and installation guides, diagnostics, shop referrals, free services like battery charging and vehicle scanning, and warranty. It also serves as the entry point to an externally built employee scheduling tool and to the store management system (the one piece of the full store systems suite that isn't mine).

During my first year, AutoZone was migrating its proprietary parts catalog to ACES and PIES, the automotive industry's standard data format. That migration drove a full version change of Z-net, both to accommodate the new data model and to improve the experience for store employees. I didn't lead that redesign, but I spent over a year designing features, refining flows, and researching change management ahead of its full rollout in December 2025. Since then, I've owned ongoing feature work and maintenance across the platform.

Some of Z-net's systems are decades old, a few haven't changed meaningfully in 40 years.

Designing for thousands of stores at once

Research here isn't about any one method, it's about gathering enough signal from thousands of stores to make decisions with confidence. Early discovery happens through 1:1 guided interviews and behavioral data pulled directly from the software. Once a concept is ready to test, I build fully functional interactive prototypes myself and the UXR team run 1:1 interviews and task based exercises, followed by usability testing; analytics review is typically owned by the research team, and A/B testing comes up occasionally but isn't common given how store floor workflows are structured. I try to be in all of threm to have firsthand access to the data, as a listener, note taking or conducting the research, in any case it always end up driving my work.

The biggest research lever is the National Sales Meeting (NSM), an annual week long event bringing roughly 3,000 store AutoZoners together, where I show interactive prototypes across most active initiatives and gather feedback in bulk.

From 20+ steps to around 7

One clear example: part of Z-net's commercial side still runs on a decades old green screen, DOS style terminal, used for outside buy parts orders. The original flow took more than 20 steps, including leaving the system entirely to copy information in from an external vendor portal. I redesigned it to live natively inside Z-net, connected to the vendors through an API, cutting it down to around 7 steps. It's fully designed and prototyped, ready for testing at this year's NSM.

I'm also currently designing two larger initiatives:

• An AI assistant for Z-net: uses generative AI to answer employee questions about parts, symptoms, and diagnostic codes. Fully designed and in review ahead of a development decision.
• Kits: lets an employee sell an entire job (every part a repair needs) in as little as one click, reducing time per customer while making sure they leave with everything they need. Currently in development.

Scale, and what we're solving for

There's no single scoreboard for a platform this size, so the goals that guide every initiative are consistent: reduce task time, increase accuracy (giving the customer the right part the first time reduces returns), make the system self explanatory so onboarding is faster, and keep every module consistent so skills transfer between them.

In August 2026, after AutoZone's Store Operations SVP and VP spent a month working the counter alongside associates in several New York stores, the CEO asked for their honest read on Z-net. Their feedback, relayed back to the broader team: Z-net is “very, very good”, with real opportunities to improve, but a reminder that what's live in stores today is working.

What this role has reinforced

Designing for thousands of users across thousands of stores has taught me there's no single right answer, only a path that gets you closer to the outcome you want. Most of my users are store employees, often with the customer looking over their shoulder at the same screen, even though the employee is the one operating it. The hardest part is balancing three things at once: what the employee needs, what the business needs, and what the technology can actually support. Once those three are in balance, the actual design problem gets much easier to solve.