ZONAR DESIGN SYSTEM (ZUI)

Over the span of 7+ years, I led the creation, growth, and maintenance of our company’s design system. What began as a simple Material Design-based stickersheet evolved into a robust, scalable design system that supported an entire product ecosystem. This long-term initiative dramatically improved consistency, efficiency, and collaboration.

Principal Product Designer — Lead Designer & Researcher
ZONAR SYSTEMS, DESIGN SYSTEM

The Problem

Over the years, the suite of products had grown organically, with each designer shipping isolated interfaces that didn’t align visually or behaviorally. Users were forced to relearn interactions from one tool to the next, and designers spent excessive time rebuilding UI components from scratch. This fragmentation was both frustrating and inefficient.

Process & Evolution

The design system evolved over several distinct phases as both our product suite and team matured:

Phase 1: Material Sticker Sheet

In the early stages, I was the sole designer working on the system. I created a Sketch-based sticker sheet leveraging Material Design components as a lightweight, centralized resource. This served as a quick-start toolkit, enabling basic visual consistency across our product UI. You can view more about this phase at Ground Traffic Control Pattern Library.

Phase 2: Company-Branded Component Library

As the company’s design needs grew, I partnered with another designer to evolve the system. We adapted the foundational Material components to better reflect the company’s brand, product voice & tone, and platform requirements. This phase focused on refining typography, color, spacing, and interaction patterns to create a consistent visual identity tailored to our domain. We also moved away from Sketch and adopted Figma and its advanced component capabilities.

Phase 3: Team Expansion & Continuous Iteration

With a formal design team of five now contributing, we entered a new phase of refinement. The system was no longer just a visual toolkit, it became an operational backbone supporting design, engineering, and product teams.

I continuously audited the system to identify usability issues, interaction inconsistencies, and visual gaps. These were added to a Jira backlog, prioritized, and addressed systematically.

Workflow & Governance

To ensure the design system remained scalable, consistent, and effective, I created a structured workflow, as seen below. This approach kept the system aligned with product goals, fostered cross-team collaboration, and ensured ongoing, sustainable adoption.

Documentation

A well-documented design system isn’t just a reference, it’s a product in itself. I treated documentation as a critical pillar of system adoption, usability, and scalability. The approach was to meet each audience where they work, using tailored documentation across design, product, and engineering touchpoints.

Design Specs

Designers worked directly within Figma, so it was critical to embed documentation where the work happened.

• Component-Level Notes: Each component in the design library included clear, embedded usage guidelines. These covered:

  • Do/don’t examples

  • Intended behaviors

  • Variants and use cases

  • Responsive considerations

  • Accessibility annotations

• Design Tokens: Typography scales, color palettes, spacing rules, and elevation systems were documented as components themselves, making the design language more discoverable and usable.

• In-Context Learning: Because this documentation lived side-by-side with design files, it supported quick decision-making and minimized friction during the design process.

Benefit: Designers didn’t need to leave Figma to get answers, accelerating workflows and reducing inconsistencies across teams.

Design Principles

To support broader visibility and governance, we created centralized documentation in Confluence for all teams, designers, engineers, product managers, marketing, QA, and leadership.

• System Principles & Guidelines: We outlined the foundational values of the system and how they guided component decisions.

• Change Logs: Major updates and deprecations were logged and communicated to ensure teams could plan accordingly.

• Design System Overview: For non-design audiences, we created overviews explaining what the system is, who it serves, and why it matters.

Benefit: This served as the “source of truth” for cross-functional partners, ensuring alignment without needing deep design or engineering context.

Engineering Implementation

For implementation accuracy, developer enablement, and ease of maintenance, we housed engineering documentation alongside the codebase in GitLab.

• Installation Guides: Clear steps to integrate design system packages into apps.

• Component API Docs: Technical specs, inputs/outputs, available variants, and usage examples.

• Code Samples: Ready-to-use snippets showing correct implementation patterns.

• Versioning & Deprecation: We used release notes to communicate breaking changes or phase-outs, helping dev teams stay up-to-date.

Benefit: Engineers had direct, in-repo access to the information they needed, reducing handoff friction and avoiding misinterpretation of design intent.

Interactive Sandboxes

To bridge the gap between static documentation and real-world usage, I created interactive “sandboxes” in Figma. These were prototypes designed to show how users would interact with components in context.

Each sandbox served two key purposes:

• Demonstrating Behavior: Instead of relying solely on specs or notes, these sandboxes visually demonstrated real user flows, such as how components responded to hover states, clicks, inputs, errors, and transitions. This gave both designers and developers a more intuitive understanding of interaction expectations.

• Showcasing Variants: Components often had multiple states and configurations (e.g., filled vs. outlined, with/without icons, enabled vs. disabled). I included toggles and controls within the prototypes that allowed viewers to switch between these options and explore all supported variants easily.

This approach was especially helpful for:

• Designers, who could copy and reuse pre-configured components with confidence.

• Engineers, who gained clarity on behavior without needing additional clarification.

• QA and PMs, who could reference the prototypes to validate behavior against specs.

Benefit: These sandboxes turned passive documentation into an interactive, exploratory tool, improving comprehension, reducing implementation errors, and speeding up handoffs.

Outcomes

Unified Product Ecosystem

Before the design system, each product within our ecosystem felt disconnected, both visually and behaviorally. After implementation, users experienced a seamless, familiar interface no matter which tool they were using. Interaction patterns, typography, button styles, and component behavior became standardized, reducing the cognitive load for users and improving task efficiency.

Accelerated Design & Development

The design system significantly reduced time spent on repetitive design and development tasks. Designers no longer had to build UI elements from scratch, and engineers could implement shared components without starting from zero. This allowed more time for innovation and problem-solving rather than execution.

Scalable Collaboration

As our team grew, the design system served as a shared language between designers, engineers, and product managers. This improved collaboration, reduced ambiguity in handoffs, and made onboarding new team members faster and more intuitive.

• Designers could rapidly build complex flows using pre-approved components.

• Engineers trusted the system to reflect accessibility and interaction standards.

• PMs used the system to better understand scope and feasibility when proposing new features.

System Adoption & Validation

To ensure the design system was not only built but also embraced, we implemented multiple methods of tracking adoption and impact:

• Figma Analytics: Pendo was used to track component usage across all design files, helping us identify which components were most valuable and which designers weren’t utilizing the library.

• GitLab Monitoring: Codebase assessments ensured engineering teams were pulling from the correct component libraries. Usage patterns informed versioning strategy and future updates.

• Qualitative Feedback: Regular syncs with designers and engineers gave insight into what was working, what was missing, and where further refinement was needed.