Building a design system from zero for enterprise logistics software
McLeod Software
Design System Lead
McLeod Software
Design System Lead
When I joined the team at McLeod, the product ecosystem spanned multiple logistics applications with a small design system already in place. The existing system provided a starting point — there were some base components to build from — but it lacked the token architecture, naming conventions, documentation, and cross-product consistency needed to scale across the full product suite. Designers were often rebuilding patterns that already existed in slightly different forms, development didn't always have clear design specs to work from, and Product Owners and BAs didn't have a single source of truth for UI decisions. The foundation was there, but it needed structure, governance, and a strategy to grow into something the entire organization could rely on. I led the initiative to take what existed and build it into a proper, scalable design system.
This case study covers the full arc: auditing the existing ecosystem, establishing foundational principles, building a scalable token and component architecture, partnering with engineering on implementation, and creating the governance model that keeps the system alive.
I started with a cross-product audit to understand what we were working with — both what the existing system covered and where the gaps were. The audit revealed over seven versions of the same patterns across products, with tables, modals, buttons, and form elements all built slightly differently depending on the product and who had designed them. The base components gave us a starting point, but there was significant inconsistency layered on top. The audit helped identify high-frequency components that needed standardization first, gaps where no patterns existed at all, inconsistencies causing dev rework, and the areas where UX debt was highest.
I also interviewed designers, developers, POs, and BAs to understand workflow pain points. This turned out to be critical context — logistics software is operationally complex, and the people closest to the product had strong opinions about what was and wasn't working. Their input shaped the prioritization from day one.
Tokens
I built foundational tokens for color, typography, spacing, elevation, and icon/icon states — the consistency layer McLeod had never had. This included a WCAG AA-compliant color system with semantic colors, seven-shade scales, and dark mode variants anchored to primary Blue.
Component Architecture
This is the area I'm most proud of. Every component is built with systemized naming (kebab-case), clear variants and properties, responsive considerations, and documented usage guidelines. I took hundreds of inconsistent, mismatched icons into a single token-aligned library with consistent stroke, grid, sizing, and naming conventions.
Documentation
This was the MVP of the project. Every component ships with documentation including usage, behavior, content guidance, edge cases, dos and don'ts, and live component embedding. This became the reference point for designers, PMs, and BAs — and it fundamentally changed how cross-functional teams made decisions. Before the system, every conversation about UI was a negotiation. After, it was a reference check.
Engineering Partnership
I worked closely with devs to align our Internal Component Demo architecture alongside Figma. We reviewed components together, made decisions together, and validated behavior before anything was finalized. This partnership is one of the system's biggest strengths — even though adoption is still a work in progress, the alignment and trust are strong.
We created a governance model that was lightweight enough to actually work: designers or teams submit component requests, we evaluate based on frequency, need, and feasibility, decisions run through a design committee, and approved components are added to the system. We also run quarterly design brainstorms for ongoing support and alignment. We didn't want a heavyweight process — but we needed clarity and consistency.
Even with adoption still growing, the results have been clear: Designers move significantly faster. There's far less time spent recreating UI from scratch. Consistency across products has improved dramatically. The UX team has stronger foundational trust with stakeholders. Dev rework and handoff friction has decreased. And PMs and BAs finally have one place to reference patterns and decisions.
Most importantly, we shifted the organization from everyone designing separately to teams working from a shared system and language. That's not a Figma library — that's a culture change.
Increase developer adoption by building more components into the code library, embed accessibility standards deeper into the token structure, build more pattern-level documentation beyond individual components, expand mobile support as products evolve, and build out a consistent approach to accessibility and dark mode. The system is strong, but there is significant room for continued maturity.
