Co-architecting a unified design language across DCLI's entire product suite — bringing coherence, speed, and scale to a fragmented enterprise UI landscape.
01 — CHALLENGE
DCLI operates a complex suite of enterprise tools spanning logistics management, container tracking, fleet operations, and customer-facing portals. Each product had evolved independently over years, resulting in a fragmented UI landscape with inconsistent patterns, duplicated components, and significant design-to-development friction. New features took longer to ship because teams had to rebuild common patterns from scratch, and visual inconsistency was eroding user trust across the platform.
The engineering and product teams were scaling rapidly, and without a shared design language, onboarding new designers and developers was becoming exponentially harder. The absence of a system wasn't just a design problem — it was a business velocity problem. DCLI needed a foundational design system that could scale with the organization and become a genuine product asset.
"Every product team is solving the same problems in different ways. We're spending time reinventing rather than innovating."— VP of Product, DCLI
02 — RESEARCH
Before designing a single component, we needed to understand what existed. We ran a comprehensive UI audit across all active product surfaces, cataloging every unique button, form state, color value, and typographic style in use. This groundwork was tedious but essential — it gave us the foundation to make principled decisions about what to standardize, what to retire, and what to build from scratch.
8 product surfaces
Cataloged every UI pattern across active products — identifying duplication, inconsistency, and gaps in the existing pattern library.
14 participants
Spoke with designers, engineers, and product managers across teams to understand pain points, workflow blockers, and hopes for a unified system.
Sprint cycle data
Analyzed engineering tickets to quantify how much time was spent rebuilding common patterns — creating a business case for the investment in systematization.
03 — PROCESS
We started with foundations — color, typography, spacing, elevation, and motion — establishing a token-based architecture that could adapt across Salesforce's platform constraints and DCLI's brand requirements. From there we moved to core components: inputs, buttons, data tables, navigation, and modals. Each component was designed in parallel with the engineering team to ensure feasibility and to establish shared naming conventions that aligned Figma variables with code tokens.
04 — SOLUTION
The resulting system — branded internally as myDCLI Design System — is a token-first, component-driven library built to operate within Salesforce's Lightning Design System while extending it with DCLI's brand identity and product-specific patterns. It covers 60+ components, full dark/light mode support, accessibility compliance at WCAG 2.1 AA, and an integrated documentation site that allows developers to copy production-ready code directly from component specs.
The system lives as a published Figma library with Tokens Studio integration, enabling design changes to propagate to code through a structured variable pipeline. Teams across logistics, operations, and customer portals now build from the same foundation — with the flexibility to compose custom patterns from base primitives when product requirements demand it.
Semantic design tokens map brand decisions to implementation — enabling global theme changes to propagate instantly across all products with a single variable update.
A comprehensive component library covering all core UI patterns — from simple inputs to complex data tables — with full interactive state coverage and documented usage guidelines.
Every component links directly to its Salesforce LWC implementation, with copy-ready code snippets and accessibility annotations baked into the spec documentation.
05 — RESULTS
Since adopting the system, product teams have reported a significant reduction in time spent on UI scaffolding. New features that previously required a full sprint of design and engineering setup now launch in days. The system has also become a communication tool — design, engineering, and product now share a common vocabulary, reducing misinterpretation and rework during the handoff phase.
06 — LEARNINGS
A design system only succeeds if it's treated with the same rigor as the products it supports — with a roadmap, versioning strategy, and genuine ownership. Without that commitment, systems get built and abandoned. With it, they become the highest-leverage investment a product org can make.
The temptation is to start designing components immediately. The more durable approach is to spend more time than you think necessary on token architecture first. Every downstream decision becomes easier and more consistent when the foundation is solid.
Building the system was only half the work. Getting teams to use it required documentation, evangelism, and embedding the system into how teams already worked — not asking them to change their workflows to accommodate it.