Latitude Design System
@Flexport
(De facto Product Owner)
I joined Flexport as the sole design systems designer, reporting directly to the Head of Design. I was brought in to assume ownership of Latitude, Flexport's internal design system, following the departure of the founding designer who originally built it.
Over time, I led Latitude through a period of rapid organizational growth, re-established it as a reliable source of truth, built a small design systems team, and positioned the system for its next phase, including expansion to mobile.
Overview
When I joined Flexport, the company was experiencing exponential growth. The design organization alone grew from 34 designers to over 70, with new director-level leadership and product teams forming rapidly. Teams were moving at different speeds, with different levels of design systems maturity.
Latitude, the internal design system, had been foundational to Flexport since the company's early days. However, by the time I arrived:
Many products had already shipped using earlier versions of Latitude, which meant drift was already present and migration required careful planning. At the same time, leadership was openly questioning whether it made sense to continue investing in an internal design system at all, given the availability of third-party alternatives.
The Core Challenge
The challenge was not just to improve Latitude, but to prove its long-term value during a period when its future was uncertain.
Goals
My mandate was to:
- Re-establish Latitude as a single, trusted source of truth
- Align the Figma component library with production code
- Define clear usage guidelines and documentation standards
- Support adoption across fast-moving product teams
- Stabilize the system while setting a credible long-term vision
Ultimate Goal
Enable teams to rely on Latitude for 80% of their needs, so they could focus bespoke design and engineering effort on the remaining 20%.
Approach
Stabilization Before Expansion
Drawing on my experience leading design system adoption at Wells Fargo, where system trust had to be built under heavy constraints, I started with a stabilization-first strategy.
Rather than adding new components immediately, I focused on redefining Latitude at the most foundational level: typography scales were clarified, spatial systems were formalized, inconsistent tokens were audited, and component parity between design and code was re-established.
This "2.0 reset" reframed Latitude as a system with clear rules, not just a collection of components.
Parity Before Innovation
Because many products were already in production, innovation had to be balanced with continuity. I applied a parity-before-innovation principle:
- Visual and behavioral parity came first
- Engineers retained flexibility in implementation as long as specs were met
- Migration paths were prioritized over hard deprecations
This reduced friction and helped regain trust with both designers and engineers.
Designing for Autonomy, Not Control
A core philosophy guided every decision:
"Latitude should empower teams to move faster, not require permission to do their work."
I explicitly avoided turning Latitude into a rigid UI kit. Instead, success meant variable-backed tokens informing both Figma and code, composable components that teams could adapt without breaking system rules, and clear guidance rather than enforced gatekeeping.
Process & Execution
Audit & Definition
I conducted a manual audit of the existing system using shared spreadsheets to track component inventory and status, design-code parity, known gaps and inconsistencies, and real-world usage examples from product teams.
This audit made the scope of work visible and grounded roadmap decisions in reality.
Roadmap & Delivery
Milestone 1
Foundational elements: typography tokens, spacing and layout primitives, core inputs, buttons, dropdowns
• 2 months
Milestone 2
Complex components: tables (the most challenging to standardize), forms and modals, navigation patterns
• 3 months
Stretch Work
Advanced patterns, product-specific components, expanded documentation and examples
• Ongoing
Challenges
Attrition & Leadership Change
During my tenure, the founding design system lead left, and the Head of Design departed roughly a year later.
This created a leadership gap and loss of historical knowledge. It also forced the design systems team to advocate for itself more directly across product and engineering orgs.
Engineering Constraints
The hardest "no" I encountered was the lack of a dedicated engineer for Latitude.
Engineering support fluctuated, requiring careful prioritization and constant relationship management.
Adoption Risk
Latitude came close to being sunset when a team successfully launched a mobile app using Shopify's Polaris design system. While Polaris worked, it lacked the domain-specific depth Latitude already supported.
By proactively aligning Latitude with the emerging mobile initiative, and demonstrating how it could extend to mobile while preserving shared tokens and architecture, I helped shift the narrative from "replace" to reinvest.
Results
What Changed
- Latitude was stabilized and repositioned as a long-term investment
- Trust in the system increased across product teams
- Designers increasingly relied on core components rather than rebuilding from scratch
- Engagement rose through office hours and component workshops
Cultural Impact
Velocity Gains
Example: Table component workflow
Before
Designers built tables by assembling individual columns and manually customizing cells.
After
Designers started with fully composed tables that exposed configurable properties, saving hours or days per feature and allowing immediate iteration.
What Didn't Go Perfectly
Pushing for a third-party design token management tool was controversial due to cost. While it would have accelerated alignment between Figma and code before Figma Variables existed, it required more organizational buy-in than was available at the time.
The lesson reinforced that technical readiness and organizational readiness must align for tooling decisions to succeed.
Follow-Up & Legacy
When I left Flexport, Latitude was:
- Actively supported
- Positioned for expansion into mobile
- Backed by a broad base of designer and engineering advocates
While I wasn't present for its next phase, the groundwork, technical, cultural, and educational, was firmly in place.
Reflection
This project deepened my understanding that design systems succeed or fail socially before they fail technically.
At Wells Fargo, adoption required methodical, top-down influence in a regulated enterprise.
At Flexport, success depended on education, trust, and grassroots advocacy during rapid growth.
In Both Cases
My role was the same: build systems that scale teams, not just interfaces.
Visual Artifacts
.png)
.png)
.png)
