Zonar Design System

A design system for Zonar

CASE REVIEW

I designed Zonar's design system in 2020–2021 as a UX consultant. Five years later, the same design-system primitives — typography hierarchy, color palette, button and form treatments, navigation patterns — are still in production at zonar.my on the web and on iOS / Android.

I don't have hard usage metrics to share. What I have is durability: a system that survived from a small early-stage project to a live product with apps in both stores and third-party validation (MDEC certification, Business Today and Disruptr press features). When you can't quote DAUs, the next-best impact statement is: *the work was good enough that nobody had to redo it.*

TIMELINE

Apr 2020 — Mar 2021

BRAND

Zonar (zonar.my)

ROLE

UX Consultant — Design System

TOOLS

Figma · Confluence (later folded into Figma)

METHODS

Component audit · Token foundations · Cross-functional alignment · Accessibility · Documentation

STILL SHIPPING

5+ years in production · iOS + Android apps · MDEC certification

Why Zonar needed a design system

Zonar was an early-stage product when I joined. The team needed structure to design, iterate, and test efficiently — but also wanted to avoid the trap of locking in too much too early. The brief was a design system that would survive the product's growth: scalable, accessible, and consistent enough that any future contributor could pick up a component without re-deriving its rules.

What I built

A design-system foundation, not a finished UI library. The deliverables were the primitives that anything else would be built on top of:

Typography

Urbanist as the primary face — open letterforms, wide weight range, broad language coverage for future expansion.

Zonar typography hierarchy: type scale, weights, and language support

Color

A blue / grey / yellow / white foundation with brand blue reserved for primary actions; reds for errors, yellows for warnings, greens for success, lighter blues for informational. Contrast ratios checked against WCAG so the same tokens worked for users with reduced visual acuity.

Zonar color palette: brand, semantic, and neutral tokens

Buttons

Primary, Secondary, Ghost, Link — each with default, hover, focus, and disabled states, in regular and large sizes. The smallest set that covered every interaction surface.

Zonar button system: variants, states, and sizes

Form fields

Field titles stay visible after selection; errors aren't conveyed by color alone. Dropdowns, checkboxes, radios, and the rest follow the same rules. Accessibility was the constraint, not an afterthought.

Zonar form-field system: states, validation, and accessibility patterns

Documentation

Started in Confluence per company tradition, then centralised in Figma after a review — Confluence pages kept as redirects to the canonical Figma files. The shorter handoff path mattered more than the policy compliance.

What survived: the live product five years later

The product evolved (a services marketplace today, with handyman / household / health & beauty / education / and more categories), but the bones of the design system I established are still the bones of zonar.my and the apps:

  • The same typography hierarchy and weight rhythm.
  • The same blue accent + neutral foundation.
  • The same rounded CTA treatment.
  • Icon-based category grids built from the same primitives I documented.

You can verify the continuity by opening zonar.my alongside the screenshots above.

How I'd ship Zonar's design system in 2026

The 2020 version was Figma-first and human-maintained. The 2026 version would be:

  • Tokens-as-code from day one (Tokens Studio → JSON → multi-platform output) so the design system isn't a source of drift between Figma and production.
  • AI-driven component documentation that reads the Figma file and the codebase and writes (and rewrites) the docs whenever either changes — instead of the manual quarterly sync I did.
  • Auto-generated Code Connect mappings via an MCP tool that proposes Figma↔React/React-Native bindings on every component change.
  • A semantic-versioned design-system release pipeline so app teams can opt in to breaking changes on their schedule, not the design team's.