Chevron Design System
Reduced new-module ship time from ~1 month to ~1 week by rebuilding a design system fragmented across 14 modules through selection, not invention.
Company
Locus
Timeline
6 months
Role
Lead Product Designer
Chevron Design System
Team
2 Designers1 Product Manager2 Engineers (FE+BE)
At a glance
Problem
14 modules. 14 codebases. 86 components duplicated across them. Every new module reinvented the same patterns, taking roughly a month to ship.
Solution
Rebuild on a shared foundation through pattern selection, not invention. Anchor the system on the data table, the central interaction surface for the operations dashboard.
Outcome
Fast Retailing went live with 6 of 14 modules migrated. New modules now ship in roughly a week.
~4.5x
Faster new-module ship time (team estimate)
6/14
Modules migrated, with 8 in progress
Context
Locus is an enterprise logistics platform for route optimization. The product runs on a micro-frontend architecture: 14 modules, each with its own codebase, owned by different feature teams. Customers include IKEA and Fast Retailing (Uniqlo).
The architecture was deliberate. It let teams ship independently. The component duplication was not part of the architecture's intent. It was a side effect of having no shared foundation underneath.
Scale at the time
14
Modules across the platform
86
Components duplicated across codebases
Trust had to be earned in seconds, and could be lost in one.
What users were doing
I went out to warehouses with the team. Asked dispatchers about the actions they took every day. The recurring answer surprised me.
"We don't want to break the system, so we don't try what we weren't taught."
Operations teams were not exploring the interface. They were repeating exactly what they had been onboarded on, even when the screen offered a faster path.
The fragmentation had taught them caution.
Same job. Fourteen answers.
The problem
Each module's UI had grown organically. Selection was placed on the toolbar in one module, on the row in another, in a hover menu in a third. Filters appeared as column chips, as a sidebar, as a header dropdown. Even the data table, the highest-use interaction surface in the entire dashboard, was rendered 14 different ways.
The cost was not just visual inconsistency. It was operational. Onboarding TAMs took weeks. Every new module forced the team to redocument and retrain. Users who moved between modules within a single workflow had to relearn how to do the same task in each one.
What we saw
14
Implementations of the same data table
~1 month
To ship a new module, most of it spent reinventing patterns
Permanent
TAM dependency for onboarding
Implementation note:
The micro-frontend architecture was deliberate. The component duplication was the side effect we set out to fix.
The reframe
The instinct in fragmentation is to unify. Pick one button. Pick one date picker. Kill the rest.
We did not do that.
Unification forces the worst-fitting team to suffer. A button picked because it averages well across modules will fit none of them well. Worse, it discards the actual learning encoded in the variants. The reason team A built its button differently from team B is often that team A's workflow demanded it.
We chose to select, not invent. The best version of each pattern, scaled to the rest. Not the average. The winner.
Consistency is selection, not invention.
This shifted the scope of the work. The design system team's job was not to design new components. It was to look across the 14 modules, find the strongest implementations of each common pattern, and elevate them.
Design principles
Select, don't invent
Find the best existing pattern. Scale it. Don't redesign for novelty.
Anchor on the best, not the average
A pattern picked because it averages across modules fits none of them. Anchor on the highest-capability default.
Lock the chrome, free the content
Toolbar, headers, pagination, DS-locked. Cell types, filters, action affordances, module-flexible.
Document as you ship, govern as it grows
Documentation is not a deliverable at the end. It is the contract that lets the next person ship without breaking what is already there.
The MUI bet got harder
We picked MUI for the component layer. Material Design 2 had a robust Figma library, broad React adoption, and an ecosystem of third-party extensions.
Three problems surfaced.
Token mixing. MUI's tokens conflated primitive, semantic, and component layers. A change to "primary" cascaded through the system in ways we couldn't predict. We rebuilt the token architecture as a strict three-layer hierarchy: primitive → semantic → component.
Component anatomy mismatches. MUI's button used a negative margin to make icon-only states center correctly. The moment we tried to use it in toolbar contexts, it pushed neighboring elements out of alignment. We rebuilt the button from scratch.
Figma library divergence. MUI's Figma library did not match the React implementation. Designers were building from one source, engineers from another. We rebuilt the Figma library to mirror the React library byte for byte.
Same intent. Different cascade behaviour.
Implementation note:
We considered Ant Design and Mantine first. MUI won on Figma library coverage and React ecosystem depth, despite the rework cost.
What got built
By March 2026, the system was four layers:
Tokens — 3-tier hierarchy across primitive, semantic, and component.
Components — 106 components across 2 Storybooks. 61 customized MUI, 45 from other libraries or built from scratch.
Patterns — selection rules across modules: this is the search pattern, this is the selection pattern, this is the filter pattern, here is when to override.
Frameworks — composite system-level patterns. The data table framework is the central one.
Four layers. Each one earns its place.
The data table
Locus's dashboard revolves around the data table. Every module uses it. So the framework that defines the table sets the tone for the entire system.
[GATE 1 — table anatomy. I need 2–3 specific decisions where you have a reject/select story to fill this section. Once you send them, this beat becomes the case study's central craft moment. Until then, the placeholder text below stands.]
The framework distinguishes between parts that stay locked at DS level and parts that stay flexible at module level. The locked parts make the table recognizable across modules — the same chrome, the same scanning rhythm, the same affordances in the same places. The flexible parts let teams encode the workflow specifics that make their module work.
Locked at DS level: toolbar structure, column headers, row scaffolding, pagination, empty / loading / error states.
Flexible per module: cell types, filter content, action affordances, density default.
[The 2–3 specific decisions go here. Each one needs the picked pattern, the rejected alternative, and the reason. For example: row-level vs toolbar-level selection. Or column-level filter chips vs sidebar filter panel vs toolbar dropdown. Or persistent vs three-dot inline actions. Pick the ones with the cleanest reject/select story to defend in an interview.]
Some parts are picked, frozen, and shared.
Others are intentionally left flexible because they encode workflow.
Pattern selection: a worked example
The cleanest example of "consistency through selection" was search.
Three search patterns existed across the modules. Page-header search, where a global search bar sat above the table. Toolbar search, where search lived alongside filters and density controls. Column-level search, where each column carried its own search chip.
We picked column-level.
The reasoning: column-level scales as a default while accommodating module-level simplification. Modules with simple data can hide the chips and surface a single toolbar search. Modules with complex data — most of Locus, in practice — get the granular control inline.
The rejected alternatives didn't scale the same way. Page-header search wins on visibility but loses on column-specific queries. Toolbar search wins on tidiness but adds a click. Column-level wins as a highest-capability default with the option to simplify down.
Three patterns. One won.
Ship first, tool second
We shipped the system to production before integrating AI tooling into the design workflow. Engineering used Cursor and Claude Code during the build for component refactoring, but the design side ran on Figma until the system was stable in production.
The system needed to be a known thing before AI could safely change it.
Claude Code on the design side
I integrated Claude Code on the design side in February 2026.
[GATE 2 — Claude Code captures. I need inventory of what you actually have: real prompts, real diffs, the Docusaurus pages that sourced the prompts, and any capture of the Storybook misfire moment. The weight of this section depends on what's available. If you have rich captures across all four, this beat carries 4–5 visuals and ~200 words of connective prose. If material is thinner, this beat compresses back into prose.]
The workflow as it stabilized: update the Docusaurus documentation with the new specification. Prompt Claude Code to apply the change to the affected components, using the documentation as the source. Review the diff. Ship.
Implementation note:
Documentation became the contract. If the docs are wrong, the AI produces wrong code. The skill is in keeping documentation precise enough that the AI can use it as a contract — and reviewing its output as if a junior designer had written it.
Documentation as contract.
The misfire
An early skill landed a variant in the MUI-customized Storybook when it should have gone in the custom one. The diff looked clean. The Storybook misrouted. We caught it in review. The skill was updated to check the target library explicitly.
The skill knew which Storybook the variant belonged in. Until it didn't.
The pushback that came earlier mattered here. Backend engineers had been cautious about design touching the codebase. They had reason — the DS was new, the skills were new, mistakes in the wrong layer would propagate across 14 modules and 5 client tenants. I started in their workflow. Pull requests with diffs they could review line by line. Documentation updates that mirrored their existing review process. Once a handful of refactors landed cleanly, the trust calibration moved.
AI didn't replace the system. It enforced it.
Result
Fast Retailing went live on the new design system in February 2026, with 6 of 14 modules migrated. The team estimate is that new modules now ship in roughly a week, down from roughly a month before the system.
Impact measured
~4.5%
Faster ship time (team estimate, not instrumented)
1
Client live in production
6/14
Modules migrated, 8 in progress
A note on the data:
This is a team estimate based on observed ship time across the most recent modules. We did not instrument adoption from day one — see what I'd do differently. The ~4x is directional, not measured.
Same workflow. Different cognitive load.
Key moment
In February 2026, Fast Retailing went live with 6 of 14 modules migrated. The first operational team running production workflows on the rebuilt system.
No module-specific frontend rebuilds. No deviations from the locked chrome. The system held in production.
This was the moment the rebuild stopped being a design system project and started being infrastructure.
What's next
8 of the remaining 14 modules are in production migration, targeted for completion through Q3 2026.
13 more clients are pending rollout. Multi-tenant configurations not yet tested will surface in the next wave.
The system expands next: deeper governance frameworks, formal contribution model, and adoption instrumentation — the team-estimate ship time becomes a measured ship time.
What I'd do differently
Validate pattern selection with users
The warehouse visits showed the problem — the caution behavior, the fragmentation cost. They did not validate which patterns should win. I picked winners based on architectural reasoning. Direct testing with dispatchers would have either confirmed or sharpened the choices.
Instrument adoption from the start
Ship time is a team estimate. Adoption rate, override rate, contribution rate — all instrumentable. We didn't set up the dashboards on day one. By the time we needed them, we were already a few months in.
Spike on the base library before committing
MUI's token mixing surfaced after we had already built on it. A two-week spike before committing would have surfaced the rebuild cost earlier and changed our cost-benefit calculus on the library choice.
Define minimum governance triggers earlier
We defined governance after the first few client integrations. By then, expectations had calcified. Earlier governance, even minimal, would have prevented some of the patterns we later had to undo.
The takeaway
The most expensive cost of fragmentation is not the duplicated code. It is the users we train into caution.
Consistency is selection, not invention.