About

Elara Reyes

Design Systems Designer & Developer

I started as a product designer at a ten-person startup, building features and shipping screens. It was good work, but I kept finding myself more interested in the substrate than the surface — the token system, the component API, the documentation that lets a team of thirty designers move as one. Five years later, that's my whole job.

I've built design systems from zero, inherited ones at scale, and migrated legacy products through complete token overhauls. The common thread: the hardest parts are never the design decisions. They're the organizational ones.

My view is that the best design systems are 30% design, 30% engineering, and 40% organizational change management. I care about all three equally, which puts me in an unusual and useful position between disciplines.

Based in San Francisco. Available for senior individual contributor or lead roles focused on design systems. I write occasionally about tokens, governance, and the organizational dynamics of cross-functional systems work.

Philosophy

Tokens are contracts

Before a single component is built, design and engineering must agree on what 'primary text' means, what 'interactive background' means, and what 'danger' means. Token naming is not a CSS concern — it's a shared vocabulary. A token system that designers don't understand is just a variable file. A token system that engineers don't contribute to is just Figma styles.

Governance is a product

A design system without a contribution model is just a library. Libraries go stale. Products evolve. The governance model — how things get proposed, reviewed, merged, and deprecated — determines whether the system stays alive after V1. I spend as much time designing the process as I do designing the components.

Consistency enables creativity

A common objection to design systems is that they constrain creativity. The opposite is true. When a team doesn't have to re-solve 'what color is this button' or 'how wide is this modal', they have more attention for the hard problems — the ones that actually require creative judgment. Constraints that are understood create freedom.

Documentation is the product

The component is what gets shipped. The documentation is what gets used. A well-built component with no guidance on when to use it, when not to use it, and what accessibility considerations apply is still a failure. I treat documentation as a first-class deliverable, not an afterthought. The usage guide gets written before the PR is opened.

Skills

Design Systems

  • Token Architecture
  • Component API Design
  • Figma Variables
  • Design–Dev Handoff
  • Storybook
  • Style Dictionary

Governance & Process

  • RFC Processes
  • Contribution Models
  • Semantic Versioning
  • Audit Methodology
  • Roadmapping
  • Stakeholder Alignment

Code

  • React
  • TypeScript
  • CSS Custom Properties
  • CSS Modules
  • HTML / Accessibility
  • Git

Documentation

  • MDX / Notion
  • Usage Guidelines
  • Decision Logs
  • Workshop Facilitation
  • Migration Guides
  • Deprecation Strategy