A design system as an operating agreement, not a component library
WM’s internal tools span corporate career portals, dispatcher command centers and tablet apps used by drivers mid-route. Holding all of that together with one designer meant building a system that made the right decision the easy one.
Architect, owner, and maintainer
6+ product teams, 40+ engineers
4 years, continuous
Web, tablet, mobile
Increase in developer efficiency, measured against pre-system delivery baselines.
Designers covering the suite, with no drop in coverage or quality.
Contrast and interaction baselines built into components rather than reviewed after the fact.
Different users, different devices, one company’s worth of drift.
A dispatcher on a 27-inch monitor and a driver on a tablet in a truck cab are not the same user, and internal software is exactly where that gets ignored. Every product team had solved buttons, tables and empty states on its own. Users moving between tools paid for it in relearning; engineers paid for it in rebuild time.
By early 2022 I was the only product designer on the suite. Personally reviewing every screen was not a plan so much as a slow-motion problem. The system had to become the thing that scaled — not me.
Componentize the arguments, not just the UI.
Most internal design systems die as documentation projects — gorgeous libraries nobody adopts. So I treated this as a governance problem first. The system’s real job was to take decisions off the table, so a team could ship a data-dense table without relitigating density, sort behavior and focus states from scratch.
That meant being explicit about what the system had opinions on and where teams stayed free, and publishing that boundary rather than letting people guess. Foundations and interaction behavior: locked. Layout and domain-specific composition: yours.
Foundations before components.
Type scale, spacing, color and states resolved first, with accessibility baselines built in rather than audited later and patched in a panic.
Patterns for the genuinely hard cases.
Data-dense tables, bulk selection, live-updating rows, empty and error states — the components internal tools actually live or die on.
Situational testing.
Components validated in real product contexts instead of on a swatch page, which is what earned engineers’ trust and got them reused.
Adoption is a service, not an announcement.
I ran office hours, a contribution path for teams who needed something the library didn’t have yet, and Figma-to-code parity checks with engineering leads so that a component meant the same thing in both places. Contributions came back into the system instead of quietly forking away from it.
I also mentored the designers who came through the org on system thinking — how to extend a pattern instead of drawing a brand new one, and how to make a design argument in engineering’s terms. That turned out to be the part that let the system survive team changes.
A system nobody contributes to is a system that dies the first time somebody needs something it doesn’t have.
21% faster delivery, and a suite that finally reads as one product.
Standardized components and situational testing produced a measured 21% increase in developer efficiency across consuming teams. Just as satisfying: the suite started to feel like one company’s software, so a dispatcher moving from Resource Center to Gantt no longer had to relearn the basics.
The system is the reason a single designer could hold a portfolio this wide, and the reason the ML dispatch work shipped on the timeline it did. Leverage, not decoration.