Irys
Design System

Two products. One language.

"Two products built in parallel can't speak two different design languages."

The Irys mobile app and the Irys Government Dashboard were being designed and developed at the same time, by different teams, with limited time and a large surface to cover. Without a shared system, each interface risked drifting — different spacing, inconsistent components, divergent accessibility patterns — leaving the brand fragmented and the team paying technical debt for years to come.

The bottleneck wasn't design — it was repetition.

Every screen rebuilt patterns from scratch. Every fix was multiplied by two.

Buttons, forms, navigation, color tokens, typography — each surface re-invented the same primitives, slightly differently. Designers spent hours aligning spacing across files. Developers translated one-off mockups into bespoke CSS. Accessibility checks were repeated case by case. Without a shared library, scaling new features meant re-litigating the basics every time. The fix had to be structural: a single, opinionated system, built once and consumed by both products.

Built once, consumed everywhere.

With limited development time, the system had to be opinionated, lean, and ready to ship. I built it on Tailwind CSS for speed and React for component reusability, then evolved it surface by surface as the mobile and dashboard products grew.

Foundations

01

Define the tokens

Established the foundational layer first: color scales, typography ramp (Inter), spacing units, radii, and elevation. Wired these to Tailwind's config so every value had a single source of truth across products and engineering.

Component Library

02

Build the primitives

Designed and built the core component set in React: buttons (primary, secondary, outline, disabled), form fields (input, checkbox, radio, dropdown), cards, badges, and overlays. Each component shipped with variants, states, and accessibility baked in.

Patterns

03

Codify the patterns

Composed primitives into recurring patterns: sidebar navigation, tab and breadcrumb systems, empty states, and data-table layouts. Documented each pattern's rationale so designers and engineers could pull from them without re-deciding.

Accessibility

04

Bake in accessibility

Audited every component against WCAG 2.1 AA: contrast ratios, keyboard navigation, ARIA labels, and visible focus states. Made accessibility a property of the system, not an afterthought of each feature — so teams inherit it for free.

Four principles holding the system together.

The system was built around four principles: consistency across products, accessibility by default, efficiency for teams, and scalability for what comes next. Every token, component, and pattern serves at least one of them.

What I learned.

Building this system reinforced that a design system is infrastructure, not decoration. Its real value isn't in the polished components — it's in the decisions that no longer need to be re-litigated, the accessibility that no longer needs to be re-checked, and the speed teams gain when the basics are solved once and shared. The lesson stuck: invest early in the foundation, and every product on top of it gets faster, more consistent, and more humane to use.