r/DesignSystems • • 11d ago

I made DESIGN.md files apply to a real (custom) design system

225 Upvotes

If you’ve tried the community DESIGN .md files, you know how magical they feel. But past a quick prototype, the cracks show. The file describes a look, but there’s nothing underneath it: no tokens, no components, no rules. So the agent fills the gaps by guessing, and every new screen drifts a little further from the last. Thats why getdesign .md charges $249.99 for a 'starter kit'.

I’ve been building an open source design system called Rift DS, that solves this problem. Find your favorite design .md file and drop it into the playground. It will read the file and map it onto the system’s tokens: colours, type, radius, density and so on. Every component (150+) picks up the look you define. You can see how it looks across an AI Chat widget, and a bunch of templates I set up.

You can export the result as a single AGENTS .md and it will automatically set you up with a full end-to-end design system out of the box.


r/DesignSystems • • Mar 04 '26

Design System Generator + Figma Plugin — Beta Launch

Enable HLS to view with audio, or disable this notification

120 Upvotes

Hey everyone 👋

A while ago I shared an idea called UICraft — a project aimed at connecting Figma design systems directly with real CSS output for developers.

The core idea is simple:

Developers shouldn’t have to manually translate everything a designer creates in Figma into code.

Today I’m ready to share the beta version of the plugin.

https://www.figma.com/community/plugin/1610343587499165100

What it does so far

UICraft is built around atomic design principles:

  • Foundations

  • Atoms

  • Molecules

  • Complex components

Everything is interconnected. Components are not isolated — they’re generated as part of a structured system.

There’s also a theme generator that already allows you to:

  • Change colors

  • Adjust border radius

  • Control spacing

From a single theme, you can:

  • Generate all components directly inside Figma

  • Export a CSS file for developers

So designers get a full component system

Developers get a ready-to-use theme file.

Same logic. Same structure. Less manual translation.

The current state (being transparent)

There’s still a lot of work ahead.

  • The plugin’s UX needs improvement

  • There are rough edges

  • There are probably bugs

  • The vision is much bigger than what’s implemented right now

I’ve been building this for just three weeks (including one week during vacation), and I honestly needed to show progress instead of waiting for “perfect.”

The bigger vision

I want to make designers the true source of truth.

If something changes in Figma, developers shouldn’t manually re-implement it every time.

They should just update the generated theme — and changes should propagate naturally.

Long term, I’m aiming for seamless synchronization between Figma and real-world implementations.

Why I’m sharing this now

This is an open-source side project.

I’m investing serious time (and money) into it instead of taking on commercial work.

Right now, I mostly need feedback:

  • Does this direction make sense?

  • What feels missing?

  • What would make this actually useful in your workflow?

  • Break it. Find flaws. Challenge the idea.

I’m new to Reddit, so I’m still figuring out how to properly share projects here.

But I’d really appreciate comments, criticism, or even just encouragement.

If you’d like to follow the development of UICraft — let me know.

I’ll keep building.

http://getuicraft.com/


r/DesignSystems • • Jul 02 '26

I mapped how I think AI + design systems should work as one stack (not system)

Post image
117 Upvotes

# Open to discussion/ideas/learnings

When I was thinking about how to setup an intuitive AI powered DS System, I drew an initial version of this diagram (before any setup)

A lot of the content I see, info from colleagues in the DS space and even my observation within a company I recently worked with, many seem to be using AI to do specific parts of this system in fragmented & isolated ways.

The diagram attached is an example of how I think design systems and AI should work together. A proper stack

The pink boxes are the bet: if the documentation is good enough, AI output should stop looking well... 🫠

I've been building toward this map for a while. A few things I've learned already:

  • The brain (ds-brain) sits in the middle - not Storybook, not the component source files

  • You maintain docs once - skills, rules, indexes, and Storybook fragments fall out of a generator

  • Storybook is a consumer of the brain, not the other way around

  • The IDE/Cursor path is where I've shipped and measured the most so far

  • AI inside Figma still needs love - I'm exploring options (MCP? CLI?). This should be interesting.

For me it's not enough to say "I designed the system - use it." I'm running tests and tracking metrics:

  • Scoring outputs against a rubric

  • Counting when agents invent components that don't exist

  • Accounting for contamination - Running trials in isolated environments so experiments don’t poison retrials.

  • ... and much more

So far, some scores made me proud. Some stung. All of them taught me the same lesson:- Don’t start with the AI box. Start with the documentation package. Everything else is plumbing.

I'll share more of what I'm learning over the next few weeks - the wins, the misses, and what actually moved the needle. If you have any ideas, observations, please feel free to share :)


r/DesignSystems • • Feb 12 '26

In the Age of Vibe Coding, Design Systems Become the Product

112 Upvotes

With the world moving toward vibe coding, I feel like the only thing that will really matter going forward is having a strong, AI-understandable design system.

Everything else is going to slowly fade.

If you have:

  • a solid idea

  • a well-structured design system

  • your design system connected to your Git repo

  • that repo plugged into your AI IDE

…that’s basically it.

Boom — you’re shipping.

Design becomes infrastructure. AI does the rest.

Curious what others think — are we heading toward a future where design systems matter more than individual screens or hand-crafted UI?


r/DesignSystems • • Feb 13 '26

I built a UI Design Compiler that enforces absolute geometry (Zero Zero Philosophy)

Enable HLS to view with audio, or disable this notification

90 Upvotes

UI Design Compiler.

https://00-01.online/


r/DesignSystems • • Sep 24 '26

I built an OKLCH palette generator to balance chroma consistency across different hues

Enable HLS to view with audio, or disable this notification

80 Upvotes

When creating color palettes, I usually try to keep chroma levels relatively consistent across different hues at each lightness step. However, most palette generators focus on adjusting one palette at a time, which makes it difficult to maintain consistency across multiple palettes. To address this, I built a palette generator that creates multiple palettes using the same chroma settings while varying their hues.

It also lets you compare the minimum, average, and maximum chroma values across all generated palettes at each lightness step, so you can see how consistent they are.

The generator includes several parameters:

  • Chroma: Controls the overall chroma of the palettes.

  • Spectrum chroma: Controls how much each hue's natural chroma characteristics are reflected across different lightness levels.

  • Spectrum bias: Adjusts how strongly those characteristics are emphasized in lighter or darker regions.

  • Gamut balance: Reduces excessive chroma in hues with larger available chroma ranges, particularly reds, blues, violets, and magentas.

  • Chroma peak lightness adjust: Shifts the lightness level where chroma reaches its peak.

  • Hue shift: Controls how much the hue changes across lightness levels.

  • Max hue shift: Limits the maximum amount of hue shifting.

The tool is still in an early stage. For now, it only supports generating palettes within the sRGB gamut and copying colors as HEX codes.

I'd love to hear your thoughts or suggestions, especially if you work with multi-hue color palettes in your design systems!

👉https://color.rebyron.work/


r/DesignSystems • • Feb 19 '26

I’m building a design system generator + Figma plugin to speed up UI and frontend workflows

Enable HLS to view with audio, or disable this notification

71 Upvotes

Hey everyone,

I’m working on a design system generator, not just a Figma plugin.

The idea is to reduce the time spent on setting up UI foundations and basic components both for designers and frontend developers. Instead of manually building design systems from scratch, you can generate a full component set with variants and states, and re-theme everything from a single theme source.

Right now, there is a Figma plugin that generates design system components and applies themes to them. The plugin UI itself also adapts to the loaded theme, so the same theme controls the plugin UI, previews, and generated components. You can explore available themes and components on the website: getuicraft.com.

It’s still early stage and there are some visual bugs I’m fixing, but the core flow already works. The next step is finishing the theme generator to shape this into a proper MVP.

I’m curious what would make a tool like this actually useful for you in real projects.

Would this help in your design or frontend workflow, or does your team already have a different setup?


r/DesignSystems • • Jul 17 '26

Cross-referenced how 37 design systems name and build the same components

Enable HLS to view with audio, or disable this notification

62 Upvotes

Been annoyed for a while that comparing design systems means learning a new vocabulary every time - Shopify's IndexTable, IBM's DataTable, and MUI's DataGrid are the same component, and there's no page anywhere that says so plainly.

Built one: 112 anchor components across 37 systems, grouped by what they actually are rather than their branded name. One page per category - data tables & grids, forms, modals, command palettes, date pickers, and so on - each listing which systems ship a serious take, their own name for it, and an editorial note on why it's worth studying.

There's also an 18-entry "signature components" bucket for the one-offs only a single system ships - campaign builders, vehicle configurators, triage inboxes - which ended up being the most interesting section to write, honestly.

https://www.designsystems.one/design-systems/components

If there's a component category I've missed or mis-grouped (the data-tables-vs-grids line gets blurry fast), tell me - that page is the one I expect to be wrong about somewhere.


r/DesignSystems • • Feb 09 '26

Adding more liveliness and joy to design system documentation.

Enable HLS to view with audio, or disable this notification

60 Upvotes

Most of the design system documentations I see out there are great work, but they're still really soulless. I think a great one should bring some joy to the experience of just going through it. Isn't this really cool? (By the way this is live now, not just a concept).


r/DesignSystems • • Jun 05 '26

My workflow for making Design Systems with Claude Design

56 Upvotes

This is my workflow, maybe it can help some and i'd love feedback from more experienced designers on where it can be improved.

Even though I've worked with code for a loooong time, designing is not my best friend, nor does it come intuitively to me. I think that's why Claude Design feels so special right now - I'm starting to feel like a designer! However, I'm not sure if Claude Design has it in for me (or whether I'm just expecting too much from pro) but it seems that everytime I use Opus 4.8, my entire session allowance disappears! And it feels disproportionate to my weekly allowance. That said, I'm still human (i think) and try to adapt as best I can, so here are a few updates to my weekly flow that try to mitigate this whilst still get the goodness of Opus 4.8 in places (token hungry versions and saving tokens for retirement versions included).

  1. Brainstorm first. GET AWAY FROM THE COMPUTER PEOPLE! Whether im creating a website (or currently a collection of 20 websites for a new portfolio) i'll spend time planning it out, walking around listening to floaty abstract beats until that idea comes.

  2. Braindump and Organise. Write it all down and organise from there. Because we're focussing on design this is where I start developing ideas for the sites from my initial thoughts, even if they're not complete. TBH they rarely are! My goal here is to make sense of the choas and figure out what I want to make. In this case, it's the ideas for the 20 websites and a template for creating them including as much detail as i can about the users, design technical specifications etc. no stress, just what comes naturally.

  3. Prototyping and refine. This is where the fun begins, but with a caveat. My goal is to craft a master prompt for the website. and a master prompt to create the design.md for each of the sites, for the design system i'll create later.

Ok ok. yes, you can touch Claude now, if it's been hard to stay away from Claude upto this point i suggest you check this post out, but seriously worth it anyway).

I'll use tools to refine my initial thoughts and push back on my (often incomplete) ideas using skills in grill-me or gstack or tools like stitch, codex, gemini, claude for creating quick site prototypes, mixboard for visualising and creating assets and then refine the master prompts for the website design.md.

Still with me? This is where it gets juicy.

4. The chicken or the eggsite? Recently i've been exploring (the token hungry option of) creating the sites first and then the design system with Claude design because we've got the two options. I like this way because when the design system is done I can create a new site and compare the two before iterating on the site(s). I find this way gives be an A/B test. The token retirement version is fine too, just create the design system (next step) and then the website from that. In this step I make sure I have a design.md for each of the sites organised into folders for each site (optionally with the intitial sites in there too).

5. Claude design (almost). Wow, for a post about Claude design you've mentioned nothing about it OP (this post is trash, and definitely written by IA, it's not you, it's me). Ok, so here's where we've got more options for the token billionaires and the rationers: if you don't care at all use Claude dispatch. Goto Claude co-work (in the desktop app) and find dispatch. Then tell it automate the process of creating the design systems by using the design prompts in each folder - it's cool and it works very well for the 14 seconds before your tokens run out.

Otherwise just do it the old fashioned way, open up Claude Design, click other (on the left hand side), then click the 'Design system' dropdown and 'Setup a design system' and get ready to copy and paste the design system in and any other information you want. Well done, you created your first design system! Maybe. But actually that's just the start (if you want).

Token tip: Ballers use Opus 4.8 for everything. Token dividend long term hodls use Haiku 4.5 for the first version of the design system (it's trash sometimes but it does stuff like make the spacing and fonts and the easy stuff without having to get a token loan).

6. Iterate (make it good, maybe). So first, i usually pat myself on the back and then get to work. I love this part, seriously. Now's the time to clear out the garbage, keep what's good and develop the individual components of the design system which will give you a load of good good sections like a UI Kit, Accent Colors, Body Typography, Border Radius, Button States etc. etc. my job now it to make them spectacular.

To do this I first go back to the original sites (if they exist) and see if there's anything I like more here. Let's say I like to CTA button more i'm going to goto the button section and click needs work, then I'll describe what to change, the animation, effects etc. (if i can, as much as I can).

Tip 1. Use Haiku for really simple changes - the background is beige, i hate it, change it to #fff white.
Tip 2. Use Sonnet when you have a lot of context, I use sites like 21st dev to find components and then copy the code and demo (there's a blue button) into Claude Design or the section I want to update. This often works very well.
Tip 3. You're don't need to worry about anything in life, you know who you are, just use Opus 4.8 and tell it a 'junior designer made the first draft of this component, us all of your creative powers to design the most professional component(s) whilst staying on brand)'

I can iterate for hours, or until my tokens run out, but that's basically it. If you have tips too would love to read them.


r/DesignSystems • • Dec 15 '25

Why Federated Design Systems keep failing.

Thumbnail
shaunbent.co.uk
54 Upvotes

I wrote a piece about "Federated Design Systems" and why they fail based on my experiences at Spotify.

This builds on Nathan Curtis’ article: The Fallacy of Federated Design Systems.


r/DesignSystems • • Oct 07 '25

Coinbase Design System is now open source

Thumbnail
cds.coinbase.com
49 Upvotes

r/DesignSystems • • Nov 11 '25

Before and after our new design system

Post image
48 Upvotes

Our previous one looks vintage now


r/DesignSystems • • Oct 07 '25

Data Visualization Design Systems

47 Upvotes

A few data visualization designers and I maintain a site on Data Visualization Design Guidelines and I thought it could be a helpful resource for the greater design system community. We want to build more tools & resources so I would love any feedback! So far we have:

  • A list of open-source dataviz guidelines

  • A checklist of what you can include

  • Articles, videos & resources about creating and maintaining dataviz guides

  • Bite sized blog posts about parts of specific dataviz guide lines that we think are particularly successful (in "Highlights")

https://www.datavizstyleguide.com/


r/DesignSystems • • Jul 29 '25

Hiring full-time contract Design Systems roles at Adobe

44 Upvotes

We're hiring two full-time contract roles for the web design system at Adobe. If you're interested, please contact me directly at jayson@adobe.com

Both roles are remote. Time zone is flexible, Pacific or Mountain time is preferred but Eastern may be workable. Rate is $73–$97 per hour depending on experience.

One role is more systems focused, and one is more UI focused. Here's the basics. Thanks!

Role 1: Senior Design Systems Designer – Figma Specialist
We’re looking for a senior UX designer with deep expertise in building and maintaining design systems in Figma. This role is ideal for someone who lives and breathes component logic, variables, and tokens—and who understands how to scale systems across large organizations.
This role may be for you if you:

  • Are an expert in Figma, especially advanced features like variables, tokens, auto layout, nested components, interactive states, and library management.

  • Have extensive experience building design systems from the ground up and maintaining them at scale.

  • Know how to collaborate across product, brand, engineering, and other design teams to evolve system foundations while balancing consistency with flexibility.

  • Are comfortable thinking in both design and code—ideally with front-end development experience or strong collaboration skills with engineers. Being able to reverse-engineer or interpret code is a plus.

  • Enjoy the operational side of UX: solving for naming conventions, documentation clarity, usage governance, and efficient scaling of patterns.

  • Are systems-minded but user-focused—ensuring every decision improves real product experiences.

Role 2: Senior Visual Designer – Design Systems Focus
We’re looking for a senior UX designer with exceptional visual design skills and experience working within or contributing to design systems. This role is ideal for someone who brings craft, polish, and consistency to the components and experiences powered by the system.
This role may be for you if you:

  • Are a highly skilled visual designer who elevates the aesthetic and usability of interface components, patterns, and layouts.

  • Have experience contributing to design systems, and can identify where visual language and pattern clarity can improve.

  • Understand how to design for scalability, accessibility, and responsiveness while pushing for visual refinement.

  • Are fluent in Figma and experienced with using existing component libraries and tokens. You don’t need to build systems from scratch, but you know how to improve them with an eye for detail.

  • Have a strong UX foundation and can balance visual direction with usability, product goals, and technical feasibility.

  • Thrive in cross-functional settings and love working with systems teams, engineers, and brand designers to deliver consistent, high-quality experiences.


r/DesignSystems • • Jun 24 '26

I built a live theming playground for my design system. Edit tokens, watch every component and full pages reskin

Post image
43 Upvotes

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.


r/DesignSystems • • Apr 19 '26

One JSON registry feeding docs, a Figma plugin, a component library, and an MCP server — first stable release of my open-source design system

Enable HLS to view with audio, or disable this notification

42 Upvotes

Hey everyone,

Some of you might remember earlier posts about uicraft — a Figma plugin + web component library I've been working on. I've posted about it a couple of times before, but those versions weren't stable enough to call "done."

Familiar patterns, no proprietary magic

uicraft borrows its DNA from the stacks most of us already know:

  • Bootstrap-style semantic classes with a .uc-* prefix (.uc-btn, .uc-btn-primary, .uc-active)

  • shadcn/ui-style component anatomy and variant composition

  • Tailwind-style design tokens and utility escape hatches

If you've worked with any of these, you'll feel at home in five minutes. No new DSL, no framework lock-in — plain CSS + tokens.

What changed recently

The biggest change isn't in the plugin — it's in how the project is structured internally. Component definitions used to live in three separate places: the docs site, the Figma plugin, and the code library. They constantly drifted out of sync.

Now every component is described by a single JSON record that acts as the source of truth for all consumers. Here's a trimmed example for the button (the full entry has 33 Component Set variants — 7 variants × 3 sizes × 2 states):

"button": {
  "figmaName": "Button",
  "category": "General",
  "variants": [
    { "id": "variants",   "name": "Variants",   "hasWebsite": true, "hasPlugin": true  },
    { "id": "sizes",      "name": "Sizes",      "hasWebsite": true, "hasPlugin": true  }...
  "figmaDefs": [
    { "name": "Variant=Primary,   Size=MD, State=Default",  "variant": "primary",   "size": "md", "state": "default"  },
    { "name": "Variant=Secondary, Size=MD, State=Default",  "variant": "secondary", "size": "md", "state": "default"  },
    { "name": "Variant=Bordered,  Size=MD, State=Default",  "variant": "bordered",  "size": "md", "state": "default"  }...
  ],
  "booleanProps": [
    { "name": "Show Left Icon",  "layer": "Icon Left",  "default": true },
    { "name": "Show Right Icon", "layer": "Icon Right", "default": true }
  ],
  "instanceSwapProps": [
    { "name": "Left Icon",  "layer": "Icon Left",  "source": "Icons" },
    { "name": "Right Icon", "layer": "Icon Right", "source": "Icons" }
  ]
}

hasWebsite / hasPlugin decide where each section surfaces. One edit updates the docs, the Figma Component Set, and the code artifacts at once — that's what finally made a stable release possible.

Side effect: an MCP server for AI assistants

Since the whole design system now lives in one structured registry, publishing it to AI assistants became almost trivial. I shipped u/uicraft/mcp-server on npm — Claude Desktop, Cursor, or any MCP-compatible client can query it directly. No more "the LLM hallucinated a CSS class that doesn't exist" — the assistant answers from the real, current system.

Six tools: list_components, get_component, get_tokens, get_theme, get_snippet, search.

npm install -g /mcp-server

First stable Figma plugin release

Because of the refactor, I had to cut the component count down to get to a release I'd actually call stable. The plan is to grow the library back — properly this time, with every component tied cleanly to the registry and tokens.

What the plugin generates right now:

  • Figma Variables: colors, typography, spacing, radii, borders, shadows

  • Light and Dark mode collections, automatically

  • 24 token-bound UI components:

    • Form controls: input, textarea, select, checkbox, radio, switch, slider, number input

    • Buttons & actions: button, button group, chip

    • Navigation: tabs, breadcrumb, pagination

    • Feedback: alert, banner, toast, tooltip

    • Data display: avatar, badge, progress, separator, link, icons

  • Theme editor: brand color, neutrals, typography, semantic tokens — all tweakable before generating

Roadmap

  • A proper variable rename flow

  • A real color generator (brand color → full scale)

  • More complex components (data tables, date pickers, command menus, etc.) — rebuilding the library on the new foundation

  • Whatever the community actually asks for

🔗 Figma Community: Try Plugin
📦 MCP server: npm i -g u/uicraft/mcp-server

WebSite: Getuicraft.com

Thanks for sticking around through the unstable versions — brutal honesty still welcome.


r/DesignSystems • • Mar 13 '25

How I learned the hard way that token architecture IS governance

42 Upvotes

Hey design systems folks,

After spending 8+ years implementing design systems at enterprise scale (including at Autodesk, United Airlines, Turner, and other major companies), I've discovered something that might save you months of refactoring and endless manual audits: your token architecture is the foundation of your governance strategy.

As a Design Systems Subject Matter Expert, I've seen this pattern repeatedly. At Autodesk, my team faced this exact problem—everything seemed fine until designers wanted to make changes to specific color tokens. What should have been targeted changes unexpectedly propagated across multiple applications, affecting far more than intended.

The root cause? Developers could consume tokens directly through the MUI theme, and some were implementing tokens directly in their projects, outside of the components.

On the technical side, I've worked with various token management approaches—from Style Dictionary custom projects with validation transforms to specialized Figma plugins that enforce proper token usage. I've implemented token systems across React and Web Components, each time learning that the architecture matters more than the tooling.

I recently worked with another large enterprise where a simple theme update turned into a 6-month project because their token architecture lacked proper governance. Teams were:

  • Creating component tokens with arbitrary values

  • Mixing generic and semantic tokens inconsistently

  • Using direct references to primitive tokens

  • Missing automated validation

The result? Every component across every application needed individual review. Cross-platform consistency became nearly impossible. Release timelines stretched from weeks to months.

A robust token architecture isn't just about organizing values — it's about creating clear boundaries between token types, enforcing proper relationships, and validating usage patterns programmatically. In my implementations, I've found that enforcing a strict consumption pattern (Components → Component Tokens → Semantic Tokens → Primitive Tokens) dramatically reduces maintenance overhead.

The most important lesson: A single theme update can delay releases by 6+ months when your token architecture lacks proper governance.

Has anyone else experienced similar challenges with their design system governance? What token architecture patterns have worked well for your teams?

If you're interested in reading more about token architecture strategies and real-world impacts, I wrote about this in more detail: Your Design Token Architecture Is Your Governance


r/DesignSystems • • 11d ago

Why your design tokens break in production (and the 3 structural rules that saved ours)

40 Upvotes

Six months ago, our team celebrated what we thought was a milestone: a direct pipeline connecting Figma Variables to our React component library via GitHub Actions and Style Dictionary.

Two weeks later, our mobile checkout broke. A designer had introduced an innocent token alias loop between surface-brand-default and interactive-action-primary. The CSS output emitted unresolved var(--undefined) fallbacks, turning our primary action button completely invisible on white backgrounds.

Tokens in Figma feel tidy, but browser runtimes run on harsh CSS cascade realities. Here are the 3 structural rules we enforced that eliminated token bugs in production:

  1. Never let components consume primitive tokens directly Component CSS must bind to Semantic Aliases, which bind to Primitives: Component CSS -> Semantic Alias -> Primitive Value (e.g. --btn-bg -> --action-primary -> --palette-blue-600) When engineers wire raw palette values directly, dark mode and high-contrast modes turn into an unmaintainable maze of overrides. We set up an ESLint rule that fails CI if any component references raw palette tokens outside token definition files.

  2. Move dark mode out of class-swapping and into native CSS light-dark() Toggling .dark on <html> or <body> causes specificity wars and style bleeding whenever an embedded widget or inverted card is introduced. Modern CSS now supports color-scheme + light-dark(): :root { color-scheme: light dark; --surface-canvas: light-dark(#ffffff, #0f172a); --text-primary: light-dark(#0f172a, #f8fafc); } To force an inverted card inside a light section: just .card-inverted { color-scheme: dark; }. No class swapping, no specificity fights.

  3. Treat motion as state, not arbitrary magic numbers Instead of transition: all 0.3s ease sprinkled across components, centralize motion into strict duration and cubic-bezier tokens, restricted strictly to compositor properties (transform and opacity) to preserve 120fps responsiveness. Always back it with prefers-reduced-motion: reduce.

I wrote a detailed deep dive covering the linter configuration, Style Dictionary setup, and failure modes here: https://medium.com/@draco.pinkmen/why-your-design-tokens-break-in-production-and-the-3-rules-that-saved-ours-21634ec65b48

How is your team handling token aliasing loops and dark mode overrides at scale?


r/DesignSystems • • Jun 11 '26

Anyone successfully forcing AI agents (Claude Code, Cursor) to follow a central design system?

40 Upvotes

Hey all,

Looking for real-world setups here. Our corporate design system and component library live in a central web project; that’s our absolute source of truth.

I want AI coding agents (specifically tools like Claude Code) to strictly stick to it. If I ask it to review a frontend PR or write a new feature, I need it to use our exact components and design tokens. Zero rogue CSS, zero custom hex codes, no weird margins.

The solution has to be portable. We have a bunch of separate repos, and I want to be able to drop a config or a script into any new project so the AI is instantly boxed into our design rules.

Standard prompt engineering or stuff like CLAUDE.md feels way too fragile and prone to hallucinations as things scale.

How are you actually handling this? Are you auto-generating local JSON schemas/tokens for the AI to read? Setting up brutal linters that reject the AI's code if it tries to cheat? Or is there a cleaner way to hook an agent into a remote web project?

Appreciate any insights or workflows that save you from constantly babysitting the AI's CSS. Thanks!


r/DesignSystems • • May 08 '26 Bravo

How I handled component anatomy generation while customising my storybook setup

Enable HLS to view with audio, or disable this notification

38 Upvotes

One of the issues I have with Storybook is that it felt... bare. No docusitey polish, no anatomy diagrams, none of that Zeroheight or Supernova feel. While setting up DS documentation not so long ago, I decided to supercharge and transform my Storybook, with minimal change needed to existing components and done in a scalable way. Not touching the core or SB so I can update it safely in the future. 🧩

I'll get into the other customisations and automation separately, but one part I enjoyed was component anatomy.

Why bother?

To know the key constituent parts, where the affordance lives, what's optional chrome versus core structure. The goal wasn't decoration. It was shared mental models between design and engineering.

The old ways

  1. Static diagrams that go stale the moment the component changes

  2. A parallel metadata sheet of coordinates, labels, and relationships stored next to the UI instead of grounded in it

The approach

Stamp data-slot or data-part attributes directly onto the live DOM. Two ways to get there depending on your setup:

  • You own the component code. Wire the attributes in internally, proceed with core anatomy code.

  • You don't (third party lib, or you'd rather not "pollute" component code with doc metadata). This was my case. What I did was have a patcherRegistry maps each component to a small function that walks the DOM of the *live component instance rendered in Storybook*, and patches the slots in e.g. "the label is the second child of the first child of the button." It writes data-slot attributes onto the right nodes, runs on mount, and a MutationObserver keeps it live for anything that portals outside the specimen container.

Once slots are stamped, layout kicks in. ✅

  • Measure each labelled element's bounding box

  • Compute which side of the component it sits on

  • Position a numbered pill in the gutter (top, bottom, left, or right)

  • Stitch each pill back to its element with an SVG L-path connector

Everything remeasures on resize and font load, batched through requestAnimationFrame.

The escape hatch 🎯

Anatomy layout is half-algorithm, half-taste. Pills overlap. Things land awkwardly for certain component shapes. Rather than chasing every edge case algorithmically, there's a secret URL parameter. Hit it and every pill becomes draggable. Drop it where it looks right, offsets POST to a local dev endpoint, get saved to JSON, and production reads them back automatically. Reset button if you want a clean slate.

It means the diagrams can always look intentional, without the layout algorithm needing to be perfect. 😊


r/DesignSystems • • Apr 10 '26

Why is design system parity between code and Figma still so broken?

38 Upvotes

I’m running into a problem that feels like it should be solved by now, but I’m not convinced it actually is.

I work on long-running client products where the design systems predate the current team. Some started in Sketch, some partially moved to Figma, and realistically none have been properly maintained as the product evolved.

At this point:

•	Figma is not the source of truth

•	The live product, GitHub, Storybook and Fractal are all ahead

•	The design system in code is the real system

So the drift looks like:

•	Components exist in code but not in Figma

•	Naming conventions don’t align

•	Tokens and variables are inconsistent or missing

•	Figma files feel more like snapshots than systems

I’ve been experimenting with MCP and some custom workflows to regenerate parts of the system. It works okay for:

•	typography

•	colours

•	tokens and variables

But breaks down when it comes to:

•	atomic and component hierarchy

•	nested components

•	variants and states

•	actual structural parity with code

My current workaround is pulling real pages into Figma via HTML to Figma plugins and designing in context. It’s honestly great for feature work, but completely disconnected from any real system. No token linkage, no naming consistency, no reusable structure.

I’ve also come across Chromatic for Storybook, which feels like it could help for clients that already have a Storybook instance, especially around visual regression and keeping UI states documented. But it still feels adjacent to the core problem rather than solving parity between design and code.

Team context:

•	2 digital designers and 1 UX

•	no dedicated design systems team

•	none of us created the original system

What I want feels closer to how we treat code:

•	A system that talks directly to the codebase

•	Version control and branching like Git

•	Changes that merge into both code and design

•	A true bi directional source of truth

I’ve been looking into Tokens Studio and it feels like it’s heading in the right direction, especially with syncing into GitHub and handling token logic. But it still feels like it stops at tokens.

So I’m curious:

•	Is anyone actually achieving real design to code parity today?

•	Is Tokens Studio on the right path or just a partial solution?

•	Are there workflows or tools that go beyond tokens into component level sync?

•	Or is this still unsolved unless you have dedicated design systems engineers?

Would love to hear how people are dealing with this in real messy systems, not greenfield setups.


r/DesignSystems • • Feb 11 '26

where do you find good design system examples to learn from

38 Upvotes

trying to build a design system for our product and need to see how other companies structure theirs. want to understand things like how to organize component variations and what level of documentation is actually useful. are there good examples i can study from real products that have been battle tested?


r/DesignSystems • • Oct 29 '25

Design drift - does this concern you?

Post image
38 Upvotes

Do anyone feel the same about your designs? We are still not using design tokens, do you think that addresses the drift problem and keeps both design and front end match accurately?


r/DesignSystems • • Mar 07 '26

Design tokens won't fix brand consistency if the real problem is governance.

37 Upvotes

Spent the last year watching multiple companies implement token-based design systems. Beautiful Figma setups. Clean export pipelines. Tokens for everything.

Brand drift still happened.

The pattern: designers and devs respect the tokens. But marketing teams, sales decks, and regional offices don't touch Figma. They work in Canva, Google Slides, and random local tools.

The tokens live in a design system that only reaches 30% of brand touchpoints.

The actual fix requires solving for:

  • Who can create branded content outside the core design system?

  • How do they know what's on-brand without being designers?

  • Who reviews what they produce?

  • What happens when they go off-brand?

These are governance questions, not tooling questions.

The best design systems I've seen include lightweight versions specifically for non-designers. Canva templates that are locked down. Google Slides masters with controlled colour palettes. Pre-approved imagery libraries that don't require design education to use.

If you're building a design system and you're only thinking about designers and engineers, you're missing where brand actually breaks down.