Aragon Open Design System (ODS)
Aragon Open Design System (ODS)
Aragon Open Design System (ODS)
Figma · Storybook · React · 2023
Figma · Storybook · React · 2023
Figma · Storybook · React · 2023
Co-led the creation of Aragon's open source design system — a fully accessible, component-first library built in Figma that served the Aragon's core product and became the single source of truth for design and engineering across the Aragon ecosystem.
Co-led the creation of Aragon's open source design system — a fully accessible, component-first library built in Figma that served the Aragon's core product and became the single source of truth for design and engineering across the Aragon ecosystem.
Co-led the creation of Aragon's open source design system — a fully accessible, component-first library built in Figma that served the Aragon's core product and became the single source of truth for design and engineering across the Aragon ecosystem.

Role
Design System Manager
Design System Manager
Design System Manager
Components creation
Components testing
WCAG contrast guidelines
Documentation
Components creation
Components testing
WCAG contrast guidelines
Documentation
Team
Myself (Senior Product Designer)
Lead Product Designer
Brand Designer
Myself (Senior Product Designer)
Lead Product Designer
Brand Designer
Tools
Figma
Storybook
Radix
React
Figma
Storybook
Radix
React
Context
Context
One system to design governance
One system to design governance
One system to design governance
Aragon is the leading DAO governance platform on Web3. As the product grew across multiple surfaces, design and development were accumulating the inevitable cost of working without a shared system — inconsistent components, duplicated decisions, slow handoffs, and no single source of truth.
I co-led the creation of the Aragon Open Design System alongside 1–2 other designers. ODS was built entirely in Figma, designed to be open source and human-centric — serving internal product teams and the wider Aragon developer community simultaneously.
Aragon is the leading DAO governance platform on Web3. As the product grew across multiple surfaces, design and development were accumulating the inevitable cost of working without a shared system — inconsistent components, duplicated decisions, slow handoffs, and no single source of truth.
I co-led the creation of the Aragon Open Design System alongside 1–2 other designers. ODS was built entirely in Figma, designed to be open source and human-centric — serving internal product teams and the wider Aragon developer community simultaneously.
The Problem
The Problem
Scale Breaks What Craft Can't Hold
Scale Breaks What Craft Can't Hold
Scale Breaks What Craft Can't Hold
Without a system, every new feature started from scratch. Designers rebuilt similar components independently, engineers interpreted specs differently across products, and accessibility decisions were made inconsistently. The cost wasn't visible in any single screen — it accumulated across every sprint.
The goal wasn't just a component library. It was a shared language — one that let designers move faster, gave engineers unambiguous specifications, and ensured every user-facing surface met the same accessibility standard regardless of which team built it.
Without a system, every new feature started from scratch. Designers rebuilt similar components independently, engineers interpreted specs differently across products, and accessibility decisions were made inconsistently. The cost wasn't visible in any single screen — it accumulated across every sprint.
The goal wasn't just a component library. It was a shared language — one that let designers move faster, gave engineers unambiguous specifications, and ensured every user-facing surface met the same accessibility standard regardless of which team built it.
What we built
What we built
Foundations First, Components Second
Foundations First, Components Second
Foundations First, Components Second
The system was structured in layers. Colour tokens, typography scale, spacing, and accessibility standards were defined at the foundation level before a single component was built. This meant every component inherited the same accessible colour contrast, the same spacing logic, and the same type scale — by default, not by convention.
Core components covered the full product surface: buttons, inputs, modals, navigation, cards, action items, empty states, error states, and loading states. Each was built with clearly named component properties — variants, states, sizes, and boolean toggles for icons and optional elements — so any designer could configure a component without needing to dig into its construction.
The system was structured in layers. Colour tokens, typography scale, spacing, and accessibility standards were defined at the foundation level before a single component was built. This meant every component inherited the same accessible colour contrast, the same spacing logic, and the same type scale — by default, not by convention.
Core components covered the full product surface: buttons, inputs, modals, navigation, cards, action items, empty states, error states, and loading states. Each was built with clearly named component properties — variants, states, sizes, and boolean toggles for icons and optional elements — so any designer could configure a component without needing to dig into its construction.

The detail
The detail
Component Properties & DCP Nesting
It Started as a Visual Problem.
It Wasn't.
Component Properties & DCP Nesting
Every component was prepared with properties clearly identified and ready to test across all variants, states, and sizes. Boolean properties handled optional elements — icons, labels, trailing actions — keeping variant counts lean while maximising flexibility.
For complex components like Cards and Action Items, we introduced a nesting architecture using Design Component Properties (DCPs). Rather than building dozens of rigid variants, each base component was constructed to be assembled like building blocks — changing a nested DCP to match a specific breakpoint, toggle a header title, or swap a footer CTA required a single property change, not a new component.
Eventually, this is where Figma's Slots feature would just now in 2026 become a reality to avoid all the nesting manual adaption.
Slots define nested areas within a component where any content can be placed without breaking the component's constraints or layout rules. A Card component with defined slot areas for its header, body, and action zone can serve a DAO summary, a governance proposal, a token listing, or an onboarding step — all from a single component, with zero structural changes. Without Slots, the same coverage would have required maintaining a sprawling variant matrix that grew with every new product context. With Slots, the component stays singular and the context becomes the variable.
Every component was prepared with properties clearly identified and ready to test across all variants, states, and sizes. Boolean properties handled optional elements — icons, labels, trailing actions — keeping variant counts lean while maximising flexibility.
For complex components like Cards and Action Items, we introduced a nesting architecture using Design Component Properties (DCPs). Rather than building dozens of rigid variants, each base component was constructed to be assembled like building blocks — changing a nested DCP to match a specific breakpoint, toggle a header title, or swap a footer CTA required a single property change, not a new component.
Eventually, this is where Figma's Slots feature would just now in 2026 become a reality to avoid all the nesting manual adaption.
Slots define nested areas within a component where any content can be placed without breaking the component's constraints or layout rules. A Card component with defined slot areas for its header, body, and action zone can serve a DAO summary, a governance proposal, a token listing, or an onboarding step — all from a single component, with zero structural changes. Without Slots, the same coverage would have required maintaining a sprawling variant matrix that grew with every new product context. With Slots, the component stays singular and the context becomes the variable.

All states documented
All states documented
Frictionless by Default
Frictionless by Default
Frictionless by Default
Every base component with interactive behaviour was built to showcase all states — default, hover, focus, disabled, error, loading, and empty. This wasn't decoration. Fully documented states meant that when a designer handed off a flow, every interaction the product was capable of was already specified. Engineers weren't making UX decisions at implementation time. Edge cases were caught in Figma, not in QA.
Accessibility was built into the foundation, not applied on top. Colour contrast was optimised across every component at the token level — so compliance wasn't a checklist item at the end of a project, it was a property of the system itself.
Every base component with interactive behaviour was built to showcase all states — default, hover, focus, disabled, error, loading, and empty. This wasn't decoration. Fully documented states meant that when a designer handed off a flow, every interaction the product was capable of was already specified. Engineers weren't making UX decisions at implementation time. Edge cases were caught in Figma, not in QA.
Accessibility was built into the foundation, not applied on top. Colour contrast was optimised across every component at the token level — so compliance wasn't a checklist item at the end of a project, it was a property of the system itself.
