Two years in, we'd built a UX Practice from scratch — but scaling it exposed a deeper problem. Every new product our designers touched created collisions between legacy UI and modern patterns, making standardization nearly impossible.
- Role
- Product Owner & Design Lead
- Category
- Design Leadership
- Year
- 2018

How do we create a unified design language across fragmented product teams and a complex vendor ecosystem?
Why this mattered
Teams across JLL were building products independently, resulting in inconsistent experiences for internal users. Each team maintained their own component libraries, design patterns, and development standards. The lack of a shared system meant duplicated effort, slower delivery, and a fragmented user experience that eroded trust in internal tools.
Behaviors to support
Product teams should be able to find, understand, and implement components from a central repository rather than building from scratch.
Limiting factors
Development was split between internal teams and third-party vendors, making governance and adoption of shared standards more complex.
“Every team was reinventing the wheel. We had five different date pickers across four products.”
North star metric
The creation of an accessible repository of components, principles, and operations for teams to reference, leverage, and support.
how might we
Build a centralized Sketch/Abstract library and React component system that all product teams can adopt.
my impact
Drafted the business proposal and secured executive sponsorship
Created the case for investment in a design system, presenting ROI projections and adoption roadmaps to the CTO and Head of Product.
Led the steering committee and cross-team governance
Facilitated regular reviews with stakeholders from product, design, and engineering to prioritize components and resolve conflicts.
Managed vendor negotiations and budget allocation
Coordinated with third-party development vendors to ensure alignment with the design system standards and managed the $500k budget.
Defined the system strategy and component roadmap
Prioritized which components to build first based on usage data, team needs, and implementation complexity.
team + stakeholders
Alex Chen
Product Owner & Design Lead
Jordan Lee
Development Lead
Sam Rivera
Program Manager
Avery Sato
Vendor Developer
Reported to CTO and Head of Product; reviewed with Product, Design, Engineering, and internal teams.
how we approached the work
Discovery
Auditing the existing landscape
Conducted a comprehensive audit of existing component libraries, design patterns, and development practices across all product teams to understand the scope of fragmentation.
Strategy
Building the business case and governance model
Drafted the investment proposal with ROI projections, defined the governance model for component contribution and review, and secured executive sponsorship from the CTO.
Build
Component library development and documentation
Developed the Sketch/Abstract library, React component system in StoryBook, and ReadMe.IO documentation wiki in parallel workstreams with internal and vendor teams.
Rollout
Adoption program and team enablement
Ran enablement sessions with each product team, provided migration support for existing codebases, and established ongoing component review cadences.
Our Audience
Teams building JLL internal products and services
The primary audience comprised hybrid product teams—a mix of internal employees and vendor contractors—responsible for building and maintaining JLL's internal digital products.
- —Product teams spanning multiple offices and time zones
- —Mix of internal designers/developers and vendor contractors
- —Codebases using varying tech stacks and component approaches
Brokers are slow to adopt new services because they don't trust them to work. Every tool looks and feels different—there's no consistency.
a summarization of the process, effort, and output
What we delivered
The design system launched with three core deliverables that formed the foundation for consistent product development across JLL.
Sketch/Abstract Component Library
A comprehensive design library with shared symbols, text styles, and color tokens. Designers could pull components directly into their files with confidence that they matched the production implementation.
The Sketch/Abstract library with shared symbols, text styles, and color tokens
StoryBook Development Environment
An interactive component playground where developers could browse, test, and copy implementation code. Each component included usage guidelines, prop documentation, and accessibility notes.
Interactive component playground with prop documentation and accessibility notes
ReadMe.IO Documentation Wiki
A central knowledge base covering design principles, component specifications, contribution guidelines, and operational processes for the design system.
The design system was adopted by 8 product teams within the first quarter, with a 95% satisfaction rate from designers and developers.
Impact measured at the end of Q2 2019 following the full rollout of the design system across all product teams.
of teams had submitted pull requests
All 8 product teams actively contributing
'Extremely Satisfied'
Internal team satisfaction survey
Projected: 45 components
components available at launch (+ 44% increase from projected)
products had adopted components from the Design System
($500k) Launched 2 weeks early
blended efficiency rate, designers + developers
key learnings
what I took away from this work
Governance is as important as the components themselves
Without a clear contribution and review process, teams will fork components or build their own. The governance model we established was the key to sustained adoption.
Vendor alignment requires explicit shared standards
Third-party vendors need more explicit guidance than internal teams. We learned to over-document expectations and create vendor-specific onboarding for the design system.
Early adopters become your best advocates
The teams that adopted the system first became internal champions, pulling in skeptical teams through peer influence rather than top-down mandates.
What I'd do differently
I would have invested more in automated visual regression testing from day one. We caught several production inconsistencies late that could have been caught earlier with better tooling.