Role | Lead Product Designer, Design System Owner |
|---|---|
Team | Design Systems Team — 1 Designer, 3 Engineers, 1 Product Manager |
Duration | 2.5 years |
Platforms | Web + Android |
Modalities | Visual UI + Voice |
Scope | 7 Applications |
System | 70+ Components, Design Tokens, Storybook, Documentation |
As the sole product designer on the initiative, I identified the need for a dedicated design systems team and made the case for investing in one. After demonstrating the value of a shared system, I established the design system practice and defined the processes, planning, and ways of working that would support the new cross-functional team.
The work required navigating established visual direction, engineering architecture, and a preselected UI library while creating a reusable system that unified design and development across products.
Established the design systems practice, defining team processes, planning, governance, and ways of working.
Architected the system foundation, creating reusable components and interaction patterns across web, Android, and voice.
Aligned design and engineering architecture, partnering with engineering on a component model that could scale independently across products.
This wasn’t a greenfield design system effort. LinOS needed to introduce a scalable foundation without disrupting an established product ecosystem.
Business Challenge
Product experiences had evolved independently.
Designers and engineers were recreating solutions.
There was no shared language or scalable foundation.
Constraints
Existing visual language
Preselected UI library
Existing engineering architecture
Sketch → Figma migration
Products already in production
One System, Multiple Products
LinOS provided the shared foundation for seven applications spanning responsive web and Android experiences.
These products served different logistics workflows and device contexts—including voice-enabled, hands-busy experiences—but shared the same visual language, interaction patterns, and component foundation.

Automated Receiving - Android mobile

Manual Case Picking - Android mobile

LinOS Dashboard - Responsive web

LinOS Dashboard - Responsive web
Architecture Research & Discovery
I studied established enterprise design systems and evaluated their approaches against LinOS's product and engineering constraints.
Key Challenges Identified
Fragmented ownership | Components lived within individual product repositories. |
|---|---|
Design-development gaps | Design specs and coded behavior frequently diverged. |
Limited cross-platform reuse | Components required significant rework across web and Android. |
Tooling couldn't scale | Sketch lacked the collaboration and governance the growing system needed. |
These findings ruled out a tightly coupled, one-size-fits-all system. Instead, the architecture needed to solve three competing needs: reuse components across web and Android, maintain a shared system foundation, and give product teams flexibility over when they adopted system updates.
Strategic Approach
I defined an approach centered on a shared foundation, cross-platform reuse, and flexible adoption—creating consistency without tightly coupling product teams or their development cycles.

LinOS system strategy: shared foundations with independently evolving components and products.
Cross-Platform Architecture & Flexible Adoption
Working with my engineering partner, we moved shared UI components out of the existing monorepo and into a dedicated pipeline where components could be individually packaged and versioned.
Building on the existing React Native Web UI library allowed the same coded components to support web and Android applications from a shared foundation.
Designing for Cross-Platform Behavior
Components needed to accommodate platform-specific interaction patterns, states, and modalities while maintaining a shared foundation.
The Card List Item illustrates that flexibility: a shared structure supported different interaction models, content configurations, and states while allowing individual elements to adapt to each product.

Card List Item component variants

Card List Item variants in production across web and Android
Designing for Voice Interaction
The voice interactions shown throughout LinOS products were also part of the design system, supporting hands-busy logistics workflows. As part of the design system, I created reusable components and interaction guidance for voice-enabled workflows, defining how visual interfaces communicated listening, speaking, detected input, idle, and unavailable states.

LinOS Voice Indicator component
Scaling Adoption & Governance
As LinOS evolved, I established lightweight governance that helped teams distinguish between product-specific needs, opportunities to improve existing components, and patterns worth adding to the system.

Reusable needs evolved the system; product-specific needs stayed with individual products.
Design reviews and a dedicated Slack intake surfaced emerging needs while keeping the system from accumulating unnecessary one-off components.
Documentation Ecosystem
I established guidance across Figma, Storybook, Confluence, and Slack so teams could access system information within their existing workflows. Maintaining alignment between Figma and Storybook created a shared reference from design through implementation.

Internal documentation standards covering component architecture and coded implementation.
Results & Impact
LinOS established a shared foundation across seven enterprise applications, improving reuse, consistency, and the way product teams adopted and maintained UI components. Through governance, documentation, education, and reusable architecture, teams were able to work more consistently while reducing the operational overhead of maintaining independent UI solutions.
Area | Before | After |
|---|---|---|
Cross-platform reuse | Significant rework across web and Android | Shared components supported both platforms |
Product consistency | Similar patterns varied across products | Shared foundations created more cohesive experiences |
Design QA | Frequent clarification and implementation corrections | Shared guidance reduced implementation ambiguity |
Adoption | Shared UI changes were tightly coupled | Independent versioning gave teams control over updates |
Reduced repetitive work
Reusable patterns replaced product-by-product solutions.
Reduced ambiguity
Shared guidance aligned design and implementation.
Enabled independent action
Versioned components let teams adopt updates on their own timelines.
LinOS evolved from a collection of loosely connected UI patterns into a scalable cross-platform system supporting seven enterprise applications.











