Forem: Quinton Jason

Systematically Not Following the Design System Is a System

Quinton Jason — Wed, 17 Sep 2025 18:29:23 +0000

Every organization swears by its design system. Few truly follow it.

The irony is that breaking the system isn’t neutral. It doesn’t vanish the moment you sidestep it. What actually happens is far more dangerous... you create a new system in its place.

This is how shadow systems are born. They don’t start with grand decisions or bold rebellions. They creep in quietly through small acts of "just this once." A color is hardcoded because a token feels inconvenient. A margin is adjusted by eye. A component is forked and slightly re-styled. None of these moments feel catastrophic. But together, they form a new pattern. And patterns, repeated at scale, become systems.

The shadow system is not written down. It has no owners. It doesn’t show up in the roadmap or the design tokens. But it rules all the same. It guides decisions, creates expectations, and shapes the product experience in ways that are inconsistent, confusing, and costly.

Here’s the truth most teams don’t want to admit: systematically not following the system is still a system. And it is always a worse one. It erodes consistency. It slows down development. It breaks scalability. It undermines trust. It doesn’t just coexist with the official system; it replaces it.

The fix is not heavier policing or louder preaching. The fix is cultural. A design system is not a Figma file or a code repository. It is a contract. It’s a shared understanding of how we build, scale, and engage with our users. When that agreement is honored, it accelerates everything. When it’s ignored, the cost compounds in ways teams only realize much later.

So the next time someone suggests "just this once," remember: you are not bending the system. You are creating another one. And the only question worth asking is this, "Do you want to build on the system you chose, or the system you let happen by accident?"

Because either way, you’re building a system. The difference is whether it works for you, or against you.

Figma Variables vs Tokens Studio: Why Both Matter

Quinton Jason — Wed, 10 Sep 2025 16:08:23 +0000

Figma Variables vs Tokens Studio: Why Both Matter

As a developer, I love working closely with designers. We share the same goal of creating consistent, scalable products that feel great to use. But the tools we each lean on aren’t always the same.
One question that often comes up is: "If Figma Variables let us manage colors, spacing, and typography directly in Figma, why do we need Tokens Studio as well?"

It’s a thoughtful question. The short answer is that Figma Variables and Tokens Studio serve different roles. They aren't interchangeable, but they complement each other extremely well when used together.

What Figma Variables Are Good At

Figma Variables are fantastic for designers because they bring tokens directly into the canvas. They can be applied to components, layers, and prototypes immediately, which makes them practical for day-to-day work. A button background can be set to color/primary/500 and reused everywhere. Changing the value of a variable updates the entire design file instantly, giving designers immediate visual feedback. Figma also makes it straightforward to preview different modes, like light and dark themes, without leaving the canvas.

In other words, Variables are optimized for the design workflow. They make tokens tangible, visible, and easy to use in everyday design.

What Tokens Studio Adds

Tokens Studio, by contrast, is designed with system integrity and developer workflows in mind. It allows tokens to be organized into sets such as core, semantic, components, and product, while themes define which sets provide the source values and which sets serve as the target for export. This organization makes it possible to maintain semantic relationships like:

{
  "button.background": "{color.blue.500}",
  "color.blue.500": "#1D4ED8"
}

References, or aliases, are another strength. Instead of duplicating values, one token can point to another. If a base color changes, every semantic token that references it updates automatically. Tokens are stored in JSON, a format that development teams can consume across platforms like CSS, JavaScript, etc. And because that JSON can live in Git, tokens can be versioned, reviewed in pull requests, deployed with CI/CD pipelines, etc.

In short, Tokens Studio is optimized for system management. It ensures your design decisions travel beyond Figma and into actual codebases.

"Why Not Make Variables the Source?"

It's very enticing. I understand the sentiment when I get the question: "If we can update values right inside Figma, why not just control the system there and skip Tokens Studio?"

It feels natural. Designers live in Figma every day, so why not make it the single source? The catch is that while you can technically go from Figma Variables back into Tokens Studio, it’s not a safe foundation for a design system. Variables flatten the data, so sets, themes, and references are lost when the data is imported. If edits happen only in Figma, development tokens in JSON and Git will quickly drift out of sync. And imports from Figma into Tokens Studio usually arrive in bulk, with little clarity on why something changed, which makes review difficult.

Reverse sync can help bootstrap or capture emergency edits, but it's not sustainable as a long-term workflow. AT. ALL.

Why They're Not Interchangeable

Figma Variables are excellent for using tokens directly in design work, but Tokens Studio is essential for managing tokens as a system of record. If a team relies only on Variables, it loses semantic mappings, theme logic, portability to code, and versioning. If a team relies only on Tokens Studio without Variables, designers lose the immediacy of working directly in the canvas.

The healthiest workflow is forward flow by default, with reverse flow reserved only for exceptions.

A Practical Workflow

The process starts in Tokens Studio, where designers and developers collaborate on token definitions. Tokens are organized, referenced, and exported as JSON. From there, they're exported into Figma Variables, where they become immediately usable in the canvas. Designers apply them to components and layouts and see instant results when values change.

The key point is that Figma Variables should be used, not edited. They are the output of the system, not the place where the system is maintained. If a color, type scale, or spacing value needs to change, that change should be made in Tokens Studio and then re-exported. This keeps the design system stable, avoids drift between design and code, and ensures that every token has the right structure and references behind it.

Exploratory tweaks inside Variables might seem tempting, but they create inconsistencies and broken references if they don't flow back through Tokens Studio. A healthier pattern is for designers to surface those requests, "what if this blue was lighter?", and let the change be reviewed and applied in the source, so it’s preserved everywhere.

In this model, designers stay in flow, developers maintain system stability, and the product remains consistent across both design and code without encouraging parallel sources of truth.

Example: A Button Background

In Tokens Studio, a button background might be defined as:

{
  "button.background": "{color.blue.500}",
  "color.blue.500": "#1D4ED8"
}

When exported, Figma receives a variable collection called product. Inside it, color.blue.500 is defined as #1D4ED8, while button.background is an alias that points back to color.blue.500.

A designer in Figma applies button.background to a component, sees the correct color, and can switch modes if needed. If the value of button.background really needs to change, that request should go back into Tokens Studio so the update is applied at the source and re-exported. That way, the change carries forward into both design and development without breaking consistency.

Outro

Figma Variables and Tokens Studio are not competing tools. They're complementary. Variables make tokens usable and immediate for designers, while Tokens Studio makes them structured, portable, and reliable across teams and platforms.

Yes, you can technically run the flow backwards by importing Variables into Tokens Studio, but that should remain the exception, not the rule. Tokens Studio is the source of truth, while Figma Variables are the canvas-friendly output.

When both tools are respected for what they do best, designers feel empowered to work with real tokens, developers can trust that tokens are consistent and versioned, and products benefit from a single system that stays aligned from design to production. The healthiest design systems thrive not by spreading ownership everywhere, but by keeping Tokens Studio as the system of record and treating Variables as the practical, consumable output. So the real question is: are we using each tool for what it does best?

The Plight of the UXD

Quinton Jason — Fri, 20 Sep 2024 22:08:44 +0000

As a User Experience Developer (UXD), I often find myself in a unique position within the tech industry. While my role encompasses aspects of UI development, front-end web development, and UX engineering, the title can be ambiguous, leading to many misconceptions and challenges. In this post, I want to shed light on the realities of being a UXD, addressing the struggles, misconceptions, and unique experiences that come with the territory.

The Identity Crisis
Let's address the elephant in the room: job titles. Whether it's UI Developer, Front End Web Developer, or UX Engineer, the nomenclature surrounding our role can be confusing. We often find ourselves explaining what we do and why it matters, facing the challenge of being seen as developers without the "JavaScript guru" label.

The Invisible Developers
Despite our expertise in HTML and CSS, we're often overlooked in favor of those who excel in JavaScript. The perception that HTML and CSS are "easy" tasks undermines the complexity and importance of our work. We're constantly advocating for ourselves, proving our worth in a landscape that values JavaScript-centric development.

The Jack-of-All-Trades Dilemma
As UXDs, we're expected to be generalists while excelling in specific areas. We bridge relationships between stakeholders, advocate for user-centric design, and navigate the delicate balance between design and engineering. However, this versatility often leads to a lack of recognition and respect from both sides.

The Battle for Influence
In an industry dominated by JavaScript-focused development, our expertise in HTML and CSS is often overshadowed. We find ourselves constantly justifying the importance of our work, pushing back against the notion that JavaScript is the sole measure of technical proficiency.

Measuring the Immeasurable
One of the greatest challenges we face is quantifying the impact of our HTML/CSS work compared to JavaScript. While JavaScript changes lend themselves to quantifiable metrics, the effects of HTML/CSS decisions are more nuanced and subjective. User-centric metrics and qualitative feedback become our compass, guiding us through the intricacies of user experience evaluation and validation. Unlike JavaScript changes, which may directly influence user interactions or functionality, the impact of HTML/CSS on user experience is often more subtle but equally significant in shaping perceptions and behaviors over time.

The Uphill Struggle
Despite our challenges, we're driven by our passion for what we do. We love crafting seamless user experiences, even in the face of adversity. However, it's crucial to acknowledge the industry's systemic issues that perpetuate our skills' undervaluation.

Conclusion
Being a User Experience Developer is more than just a job title—it's a constant battle for recognition, respect, and influence. As we navigate the ever-evolving landscape of web development, it's essential to advocate for ourselves, educate others about the importance of our work, and strive for a more inclusive and equitable industry. By sharing our experiences and amplifying our voices, we can work towards a future where the contributions of UXDs are truly valued and celebrated.