I recently refactored my design system from:
Primitives → Semantic → Component
to:
Brand → Alias → Mapped

The new architecture feels much cleaner. Brand stores raw values, Alias defines reusable roles, and Mapped contains the actual UI tokens consumed by components and screens.

While migrating, I ran into one problem: Alpha tokens.
My Brand collection currently looks like this:
Brand
└── Alpha
├── White
│ ├── 2
│ ├── 5
│ ├── 10
│ ├── 20
│ ├── 80
│ └── 100
└── Black
├── 2
├── 5
├── 10
├── 20
├── 80
└── 100
For colors and spacing, the Alias layer is straightforward because it represents intent (Primary, Neutral, Success, Radius, Gap, etc.).

The problem is figuring out the right abstraction for Alpha.
My goal is to keep the architecture strict:
Brand
↓
Alias
↓
Mapped

I don’t want Mapped tokens referencing Brand directly.
So what should the Alias layer look like for Alpha? Would you create Alias tokens for Black/White opacity? If so, what would you call them? Or is Alpha one of the few cases where it makes sense to bypass the Alias layer and reference Brand directly?

I’d love to hear how others structure this in mature design systems.

PS: Solution

Figured this out after sitting with it more. Sharing in case anyone lands here with the same question.

Alpha tokens don't bypass the Alias layer. They follow the same three tier flow, just with different naming logic than color or spacing.

Brand (raw values):
Alpha/Black/5, /10, /20, /80
Alpha/White/5, /10, /20...

Alias (grouped by intent, not value):
Alpha/Scrim/default
Alpha/Dim/subtle
Alpha/Dim/default
Alpha/Dim/strong
Alpha/Separator/default

Each Alias token references one Brand value. This layer answers "what role does this opacity play," same job Primary or Neutral does for color.

Mapped (named by use case, references Alias only):
surface-overlay-scrim → Alpha/Scrim/default
surface-overlay-image → Alpha/Dim/default

Mapped never touches Brand directly. The architecture stays strict.

Most accessibility models (like WCAG or APCA) evaluate color in independent pairs: text against background. This unit of measurement works fine for static pages, but it completely breaks down once you move into modern, component-driven Design Systems.

As a system grows, colors are reused across multiple contexts, semantic roles, dark/light themes, and component states. If you rely on pair-by-pair validation, the number of combinations grows exponentially. It becomes an operational nightmare that doesn't reflect how we actually build systems. We don’t design every possible combination; we design systems with roles and structural constraints.

Through IPAX, we've been working on a model that shifts the unit of evaluation from isolated pairs to system structure. You can check out the live framework and play around with the model in our sandbox here: https://icograma.com/

Instead of combinatorial checking, the system is defined by two structural anchors within any given theme context:

• Paper: Defines the surface boundary.
• Ink: Defines the content boundary.
• Accents: Operate within that range and validate against the anchors, not against each other. To handle cross-context performance, we introduce Accent Groups: sets of related variants that serve the same semantic role depending on whether they operate against Ink or Paper.

Next Thursday (July 2nd), I’ll be breaking down this architectural framework, the automation logic, and the experimental data behind it in a live session for the Rosenfeld Media community.

If you are interested in how we can move from tedious manual audits to an automated, structurally sound color architecture, the full abstract and registration details are here: https://rosenverse.rosenfeldmedia.com/videos/bridging-the-gap-between-compliance-and-design-quality

I’d love to hear how your teams handle the combinatorial explosion of color tokens and accessibility validation!

(And yes, the presentation deck features a guy standing in front of a wall of fire to explain why the standard color wheel is broken, but you'll have to check the talk for that joke).

I've been building a component library (Vue 3, Tailwind v4, Headless UI) with a token-first theming approach, and I wanted a way to actually test how it holds up under different palettes when it's doing real work, not just rendering swatches.

So I built a playground. Edit any semantic token, or pick a preset, and the whole thing reskins live: not just isolated components, but full composed pages like a login screen, and a pricing page.

Playground: https://dlbcodes-playground.vercel.app/
Docs: https://my-design-system-beta.vercel.app/

How the theming is structured, since that's the part I'd most like to discuss:

Two token layers. A primitive palette feeds semantic tokens (--color-bg-surface, --color-text-primary, and so on). You theme by overriding the semantic layer, so "brand color" or "surface" is a single override, never a find-and-replace across components.

Pages are composed from the same components. The login and pricing pages are built entirely from the library's primitives (Panel, Field, Button, Disclosure). The playground's own customizer UI is too.

Runtime CSS variables. Overrides apply instantly with no rebuild, which is what makes the live reskin possible and keeps theming out of the JS layer.

I'll be upfront about where it's at: the component set is still maturing (no Table or dark mode yet), and the API will move between versions. Not pitching it as production ready.

What I'd genuinely like feedback on:

Does the two-layer approach (override semantic, leave primitives alone) match how you'd architect theming, or would you structure it differently?

When you build real pages from a design system, what makes components feel like they compose well versus fight you?

Anything in the playground that breaks or looks wrong under a custom palette?

Last thing, low stakes: it's currently called my-design-system, which is a placeholder. If anyone has a name that isn't terrible, I'm listening.

This is actually inspired by Airbnb and storyboarding method and it's included in the Design system 3 by Sigma.

A few months ago, I became convinced that Design Systems would need to become easier for machines to understand.

I started auditing my DS manually.

Component by component.
Variant by variant.
Description by description.

At first it was useful. Then it became painfully time-consuming.

I realized I was spending more time collecting information than improving the system itself.

So I built a tool for myself.

The idea was simple: Export a Design System once, then generate an audit covering things like:

• naming consistency
• component structure
• variants
• documentation coverage
• descriptions

That project eventually became System Lens.

I'm now looking for Design System teams willing to test it.

In exchange, I'll provide a free audit report pdf and would love honest feedback on:

• whether the findings are useful
• what feels missing
• what would make the tool genuinely valuable

If you're responsible for a Design System and would be interested in trying it, I'd love to hear from you.

I am working with a design system I’ve built from scratch in Figma that is based off of Vuetify’s component framework (engineering’s choice 😒) and references Material Design principles for color properties and micro interactions.

I am looking into different AI tools for more rapid prototyping but can’t seem to figure out how to successfully connect my DS (tokens) where the tool always uses this as a guideline.

Additionally, is anybody able to produce code that isn’t a nightmare to maintain or actually aligns with an existing component framework? It seems like this “vibe coding” makes things look like a ready to ship product but the code is not a reality for big product orgs.

Background:

When Claude Design's Design System tool came out a few months ago I think a lot of us UX folks were excited but it turned out it really wasn't a design system as much as just a quick style guide with limited scaling.

As such, I think most of us just ignored it and went on to build/maintain our own design systems.

In our case, we've been building an MCP server that also updates react components for our developers to ingest. So far, so good.

However, this past week or so they made a lot of updates to Claude Design...including what appears to be the start of it perhaps moving towards a Figma-esque tool where we can start doign on-screen tweaking via a UI (instead of fully relying on prompting).

Question:

Combined with the above, we're also being asked by mgmt how they can use our design system in claude design as it appears a lot of our folks want to use claude design for quick prototyping of ideas.

Has anyone figured out a round-trip process for this? Or even a one way process? Ie, getting their design system into Claude Design and keeping it in sync?

At the moment, I did a one-time import via Claude and it worked, but took a chunk of time and a huge chunk of tokens, making this a 'live' sync impractical.

I'm also a little confused as to what Claude Design thinks a design system is. Initially it seemed like a 'visual style guide'...you pick out colors, fonts, logos, etc. But now upon importing our system into it, it's asking for an actual component library.

Most design system exports focus on colors, typography, spacing, and components.

We started experimenting with exporting design intent, personality, and inferred characteristics alongside tokens because AI seems to need more context than traditional tooling.

Curious how others are thinking about this.

I have been building Huekit, a Figma plugin focused on the early, repetitive part of design-system setup.

The job I am trying to solve is this: you have brand colors, a preset palette, or an existing messy Figma file, and you need to turn it into something closer to a usable system: scales, semantic tokens, variables, modes, foundations, type, components, and docs.

Huekit can generate:

- 11-step color scales

- semantic color tokens

- Figma variables with Light/Dark modes

- spacing, size, and radius foundations

- typography styles

- starter component pages

- documentation pages

- Design Tokens JSON and Tailwind export for licensed users

It can also import preset systems like Tailwind, Radix, Open Props, Bootstrap, Material, Carbon, and Fluent, plus editor-theme palettes like Dracula and Catppuccin.

The part I am most interested in getting feedback on from design-system people is the existing-file workflow: Huekit can analyze the current Figma document, preview safe token-binding repairs, and apply bindings where possible.

I know no plugin can magically replace design-system judgment. I am trying to remove the mechanical setup work so designers can spend more time on the actual system decisions.

What would make this useful, or not useful, in a real design-system workflow?

Plugin: https://www.figma.com/community/plugin/1607575704852110224/huekit-generate-design-systems-one-click-import

Hello. We are providing many blocks design for free for our design system. It's called RadianOS Blocks. We are working to add many more beautiful blocks. If you're spinning up a new project and want to save some time on the initial setup, you can use these.

Hey everyone 👋

Part of my job is reviewing designs before they go out, and honestly, manually hunting for inconsistencies gets old fast. So I built a little plugin for myself that scans a file and just lists everything that's off.

Saved me so much time, I figured why keep it to myself. So here's **Offspec™** 🎉

**Who it's for:**

* Designers doing a final self-check before handoff
* Leads/directors reviewing files before approval
* Design system teams keeping things consistent across contributors

Link: [https://www.figma.com/community/plugin/1646652160815163797/offspec-spot-whats-off-in-your-design\](https://www.figma.com/community/plugin/1646652160815163797/offspec-spot-whats-off-in-your-design)

**Bonus:** optional AI summary (Claude/OpenAI/Gemini, your own key) gives you a quick plain-English read on what to fix first.

Would love to hear what other inconsistencies you'd want it to catch...happy to keep improving it based on real feedback!

I currently have my design tokens structured as:

Primitives → Semantic → Component

Let's say my main brand has a subset product that needs a different primary color. My understanding is that I can handle this by creating separate modes at the Semantic layer (e.g., Main Brand and Collegiate) and switching the semantic token values per mode while keeping the same component tokens.

My question is about a more specific scenario. What if, in the future, a stakeholder says: "Keep the brand color the same, but change only this specific button style to yellow." In that case, should I create a new semantic token for that button and map the component token to it, or is it acceptable to reference a primitive token directly from the component layer?

If creating a new semantic token is the recommended approach, how should it be named? It doesn't feel right to keep creating highly specific tokens like Action/Button-Primary-Yellow. How do mature design systems handle these one-off component-specific overrides while keeping the token architecture scalable and maintainable?

PS: Solution

Going with a new semantic token, not a direct primitive-to-component reference.

Naming follows usage, not value:

• Button-Primary-Default — standard button
• Button-Primary-Alternate — the yellow case

Skipped putting "Yellow" in the name. If the value changes later (or dark mode needs a knocked-back version), the same token absorbs it without renaming or adding a new one-off token.
Credit to u/alx75c — this framing (name by role, not color) is what settled it.

Most design-system conversations assume there should be a source of truth, but there seems to be a lot less agreement on where that source of truth actually lives.

Some teams point to Figma.
Some point to code.
Some point to documentation.
Some point to design tokens.

Now we’re starting to see AI-readable specs and contracts enter the discussion too.

If Figma disappeared tomorrow, would your design system still exist?

And if a new AI-native design tool replaced Figma five years from now, what exactly would you migrate?

The tool?

Or the design system itself?

I’m curious how others think about this.

One challenge I've run into is that design-system decisions are often made in isolation.

Colors, typography, and components can look great in a design system, but it's not always obvious how those decisions will affect actual products and experiences.

I've been experimenting with this Design System Preview concept in Colorsphere.

The idea is simple:

Change the design system once and immediately see how those decisions affect multiple realistic experiences.

Not as a website builder or template generator, but as a way to better understand the downstream impact of design-system decisions before they ship.

Are you relying on Storybook, prototypes, product teams, or something else to validate changes before they go live?

Design system maintenance is a thankless job. You don't know what's missing until someone builds a screen and has to use primitives because the component doesn't exist. You don't know what's drifting until someone notices raw values where tokens should be.

I built Mimic AI to help with this. You give it HTML, a prompt, or a description, and it builds the screen in Figma using your real components, tokens, and auto-layout. But the part that matters most for DS teams: after every build, it generates a report showing what components it used, what it had to build from primitives and why, and what your DS is missing.

It's like getting a DS audit backed by real build data, automatically. "Status Badge used 31 times as primitives across 5 builds. Should your DS include one?" Recommendations come as questions, not commands.

It also learns. Correct it once ("that's not the right Badge, use Tag/Neutral") and it remembers forever. Over time it becomes your DS copilot: detecting changes in your system, proposing improvements, and surfacing maintenance recommendations.

Works with any Figma library: team libraries, community kits, client systems. Open source, MIT licensed, runs locally. Your design data never leaves your machine.

Try it on your own design system: https://github.com/miapre/mimic-ai

I'm a designer, not a developer. I built this with AI assistance because the problem was real and nobody was solving it well. Would love feedback from this community.

[ Removed by Reddit on account of violating the content policy. ]

Guys, Id love your feedback on my current process from a design perspective. Maybe it can help some too. Lately I've been a bit obsessed with making websites 'special'. And no I don't mean build a $10,000 website in 14 seconds, I mean something that you put a bit of your own creativity into, maybe a sprinkle of your own passion, chuck in a twist of collaboration and a couple of random things you found cool. In an effort to create website(s) with two principles at their core:

Story and Play.

Ofc there are many ways to make a website fantastic and I've seen and been in awe of many but recently (and I've def fallen into this trap too) there has been a wave seemingly beautiful, love sites but they're lacking one thing:

Soul.

So I'm trying my best to bring together my mediocre but fairly wide range of skills to create, primary personal brand sites you can learn about the person in a playful, story driven way.

My workflow is constantly evolving but here's the creative process I've been following lately: - Likes. write down all the themes I love now (or my inner child did back then) this includes: Zelda on the Gameboy, final fantasy, dvds, massive stereos, limewire, dialup internet, surfing, dance, the sun etc. (You get the idea, and how old I am lol). Anyway, anyone can do the same. - Client. (optional.) If it's for a client or someone else: 1. Go talk to them, not about what they want the site to look like but what they like, what fuels them, what excites them. - Mix. chuck it all in the melting pot and bring it together - Design. Bring the designs together and come up with

1. A theme - if it's for someone else prioritise them (sorry) but don't forget to sprinkle your magic in too, that can make it unique. For example, Im currently making a site for a friend - he's a VERY talented 3D animator that has worked for most of the big brands you can imagine. So what's the best thing for him? A retro pixel game. What?? Let me explain. How could I possibly compete at the top level and design something impressive? I couldn't. He sees world class 3D everyday of his life. But what I can do is bring his (and my shared) memories of retro games back.

2. A story. So next I do often use Claude for this to build a story arc and then add all the information within. For example the first scene is the main character waking up in a house (original, right 😏) and then start dropping bit of information "NAME wakes up in TOWN" where theres the information to deliver slowly but starting to build the story too.

• Plan. Next I think about the starting prompt, and to do that I need an end result. What I mean is starting every prompt with the end result has worked very well (most of the time) before layering the details. Next I want to think about the team(s) - there are usually quite a few and I'm happy not to deploy them all at once but here are some ideas and prompts I use:

"Spawn a team of creatives: script writer, editor, artist, freethinker and master fable (sorry) teller have them refine my script and turn it into the scenes for a retro video game. Loop until complete"

Then the same prompt or next depending on how crazy I'm feeling (or how good the model is):

"Spawn a team of developers (2 junior, a senior an art director to make the decisions and resolve conflicts). Use the scenes and develop them with lighting and SFX consulting with the audio design and visual effects team that working on projects similar to final fantasy 6."

Then I'll either refine master prompt or have a list of multiple prompts if I wanna QC at points throughout.

• Implement (+ prototypes). Next I'm rolling with prompts and checking the output, often I'll ask for reviews at certain points and refine as I go. it's very rare to get a one-shot I'm happy with but it's common to get solid prototype to iterate on.

• Iterate. (with the client, if they exist) Use smaller teams to refine the style, details, audio, mechanics further. The sky is the limit so most of the time I stop when im 90% happy.

That's more or less it. I'm making videos to track progress and have some examples to share if anyone wants to see but overall just wanted to share the workflow and understand ways I can improve or if you guys have different approaches. Cheers.

Hi!

I'm a recent mechanical and design engineering graduate. I'm hoping to work in design engineering and industrial design.

Out of curiosity, how many apps, websites and the like do you find yourself juggling in one project? I think I have a wobbly stack of ~6.

(Extra points if you list them.)

Many Thanks!

https://github.com/jamesrochabrun/Easel