Avila Design System
A fully connected design-to-code system. Rooted in Hispanic heritage. Built from scratch.
Project Details
Avila isn't just a project name, it's a tribute. A nod to Hispanic heritage, to the culture, the color, the craft that's always been part of who I am. Building something and naming it after that lineage felt like a small act of honoring where I come from.
The Avila Design System started as a personal challenge: could I build the thing I'd always wanted to work on but never had full ownership over at a job? A real design system. One where the design tokens in Figma actually matched the code. Where a developer could look up a component and trust what they found. Where the system had a point of view baked in from the start.
Role: Design Systems, Solo Designer & Developer
Platform: Figma, Storybook, Vercel
Industry: Design Systems / UI Engineering
Scope: Design Token Pipeline · Component Library · Dark Mode Theming · Documentation Site
The Problem
In most teams, design and code speak different languages. A designer names a color "Ink 100" in Figma. A developer calls it #1a1208 in a stylesheet. Those two things represent the same decision, but there's no connection between them. And every time something changes, someone has to manually sync the gap.
That gap has a cost. It shows up as inconsistency across screens. It shows up as components that look right in Figma but drift in production. It shows up as the quiet frustration of a team that's moving fast but never quite in sync.
Most design systems try to solve this after the fact, patching the disconnect once it's already painful. I wanted to build one where the connection was the foundation from the start. One source of truth that both design and code could point to. Where a token defined in Figma wasn't just a note for a developer to interpret, it was the actual value flowing into the component.
I wanted to solve that for myself before solving it for a team.
What I Built
The Avila Design System is a fully connected pipeline from design to code. Design tokens are defined once in Figma, exported as structured data, transformed into CSS variables, and consumed directly by components in Storybook. Change a color in Figma, it flows through. No manual syncing. No guessing. No drift.
The token layer is the foundation. Every color, spacing value, and typography decision lives as a named token, not a hardcoded value. That means the system has a shared vocabulary. A button's background isn't #e8195a, it's --avila-color-action-primary. That distinction matters because it makes the system intentional, not just consistent.
On top of that foundation sits a component library built in Storybook, a tool designers and developers both use to browse, test, and document UI components in isolation. Every component has its own page with live rendered examples, usage guidelines, and the actual code behind it. Nothing is a static mockup. Everything runs.
The system also ships with full dark mode support, not just a color inversion, but a proper semantic token layer where each value has a specific meaning in both light and dark contexts. Switching themes doesn't just change colors, it switches intent.
Finally, a dedicated documentation site sits alongside Storybook as the public face of the system, the place anyone on a team could land and understand what Avila DS is, what it includes, and how to use it.
What I Learned
The hardest part wasn't writing code, it was making decisions. Which tokens matter? How deep does a component API need to go? When is documentation helpful versus just noise?
I also learned that shipping something is the clearest form of thinking. The act of having to make it work, not just sketch it, forced me to resolve things that "planning" never would have.
Dark mode, which I assumed would be a two-hour job, turned into its own architecture lesson. It taught me that theming is really just a question of where you define meaning, and that getting the structure right from the start saves you from patching it forever.
In Closing
This project started as a personal challenge and ended as something I'm genuinely proud of. Not because it's perfect, it isn't, but because it's real. It runs. It's documented. It's deployed. And it has a point of view baked into every decision, from the token naming conventions down to the name on the cover.
“The hardest problems in design aren't visual, they're structural.”
Building a design system solo taught me that the hardest problems in design aren't visual, they're structural. How do you name things so they scale? How do you document without over-documenting? How do you build something today that a future version of your team can actually trust?
I don't have all the answers yet. But Avila DS is where I started working them out.