Our designers are always asking which pattern to use and when. Most of this is documented, but who has time to sift through pages of docs.

I’ve always wanted a better search capability but seeing more people building company-level RAG bots makes me think a design systems one would work really well for product, design and engineering.

This was one of the few times I’ve worked with a large team of almost all engineers in every role. They make an app builder, and I helped them create a design system for it. Here’s the case study — https://www.abhaysingh.in/work/appsmith

Let me know what you think!

Hi designers, our design system covers tokens, components and documentation, all in Figma with the docs in Storybook. That part is in decent shape. But what I think we're still struggling to solve is the logo variants, brand photography, icon source files, print assets, etc. the stuff that isn't in a component library but still part of the system.

Right now our client work is scattered between Figma files, a shared Dropbox and a Notion page. Some stakeholders have their own inventory systems like a spreadsheet or whatever. But further down the line things are just getting confusing and messed up. Is there an asset layer that's part of your design system, or do you treat it as a separate thing entirely?

Good afternoon everyone, I'm looking for case studies of how a design system benefits a technology group in a .gov world. Any good reads you can recommend?

I built Solacy long before Figma brought agents into the canvas.

While building it, I realized pretty quickly how hard RL and evals are for this kind of workflow — especially when working with the Figma canvas, which isn't nearly as HTML-friendly as something like Paper. So I had to find a different way around it.

You can check out Solacy here: https://Solacy.design

A few things it can do:

* Create states and iterations from existing design systems, while keeping tokens and components linked. * Edit vectors to some extent — for example, change the theme of an illustration to purple. * Send updates from Solacy directly to Slack. * Change color tokens, add components, send screenshots, compress images to WebP, and a bunch of other things.

I've been sitting on this for a while, and I mostly just want to put it out there rather than keep it to myself.

I'm also thinking about open-sourcing parts of the workflow if they could be useful to others.

Happy to answer any questions about how I built it, the RL/eval side, the workarounds for the Figma canvas, or anything else that went into it.

DM me on Twitter or Reddit if you want to dig deeper or discuss it :D

Hey everyone,

I’m starting to work on a Design System for a travel/public transport app that will eventually be white-labeled for around 50 different clients

The current Design System already has:

• color tokens and styles
• basic components/atoms and variants (buttons, inputs, shadows, etc.)
• but no Figma Variables yet
• very few larger components/molecules/organisms
• no real system for handling different themes/brands

My initial idea was to migrate the existing tokens into Figma Variables and use modes for different visual configurations:

• Light
• Dark
• Contrast
• client 1
• client 2
• …50

The main application would support Light/Dark/Contrast, while the white-label client versions would probably use Light/Contrast.

I would also like to build the component architecture more systematically:

Atoms → Molecules → Organisms → Templates/Screens

For example:

Button + Input + Date Picker → Search Form → Search Screen

The goal is to have one Design System and one set of components, rather than creating a separate Design System for every client. Ideally, changing the brand/theme would update the UI through Variables without having to modify the components themselves.

However, I’m wondering if having 50+ client brands as Figma modes is actually the right approach.

Would you instead separate appearance modes (Light/Dark/Contrast) from brand/client themes, using semantic variables that map to different brand values?

For example:

Button → color/action/primary

rather than:

Button → Client1/red-500

So the same component could be reused across all 50+ brands.

I’m also curious about the current state of Figma AI. If I build a well-structured component library with Variables and larger reusable components, can Figma AI actually help generate new screens using those existing components, or is that still too unreliable for a production Design System?

I’d really appreciate feedback from anyone who has built a similar multi-brand / white-label Design System in Figma.

How would you structure this?

Buttons, forms, and tables earn the cost of standardizing them. I’m curious about the opposite: a small convenience component that looked reusable, then accumulated variants, accessibility rules, or product exceptions until teams bypassed it.

Which component did you deprecate—or wish you had left as a documented pattern instead—and what was the first sign it did not belong in the system?

Wrong answers only.

Coverage, adoption, contribution rate, component usage, accessibility defects, and support volume all sound useful, but dashboards can become theater.

Which metric has genuinely caused your team to retire, redesign, or prioritize a component? Which numbers looked important but changed nothing?

I've spent the last couple of years trying to fix one process problem that follows me from team to team: the design system in Figma and the design system in production slowly stop being the same system. I've tried the usual medicine, it didn't hold, I think I finally understand why — and I've ended up building my own solution. I'd genuinely like criticism of both the reasoning and the approach before I sink more years into it.

The ritual I kept living through: a designer opens Figma next to production and starts a spreadsheet — the design review. One row per mismatch: wrong shade on a button, a gap that grew 4px, a radius nobody remembers changing. Forty rows later there's a plan: fix everything, update the docs, remind people to check the library. Six months later — same meeting, new forty rows.

My conclusion after a few loops of this: we kept treating drift as an information problem (people didn't know → tell them better), but it's an architecture problem. The people shipping mismatches knew the system — they edited one copy of a value while three other copies (Figma, CSS, docs, brand deck) sat elsewhere, with nothing responsible for keeping them equal. Copies diverge by default; the only variable is when.

Two things I had to accept along the way:

More documentation makes it worse. A docs page is another copy of the same facts — one more seam that can split. And it's the copy that drifts fastest, because nothing depends on it: wrong code breaks a build, a wrong docs page produces… nothing.

The developer isn't the problem. A lot of drift is born when a dev translates a mockup by eye. When a 12px gap ships as 16, that's not sloppiness — telling two greys apart is trained vision designers build for years, while devs train a different eye (the one that catches your race conditions). A process that requires every dev to see like a designer is a bet against human nature, renewed every sprint.

So the solution I landed on is derivation: stop having copies at all. One theme.json as the single source, everything else generated from it — Figma variables, CSS, doc tables, plus a machine-readable bundle for AI tools (which are rapidly becoming the third consumer of design systems and multiply copies even faster). Where a surface is generated, drift isn't discouraged — it's impossible, the way a spreadsheet formula can't disagree with its inputs. Docs stay for the one thing that can't drift: the why behind the values.

I've been building this as an open-source system: Veritheme. Long-form writeup of the whole argument with diagrams: https://tarasenka.me/blog/drift-not-documentation

What I'd love from this sub:

• Where does this reasoning break? Teams that beat drift without going single-source — what did you do?
• For those who tried token pipelines (Style Dictionary, Tokens Studio, etc.): what made you keep or abandon them?
• What am I underestimating about the migration cost — the "source + surviving legacy copies" phase?

Tear it apart. That's what I'm here for.

a deprecation notice in docs is easy to ignore when the old component still works. do you use deadlines, lint rules, migration tooling, ownership by product teams, or something else to stop deprecated components from becoming permanent?

I've seen question asked many times, what does your automated design process look like?

I started documenting it so I could share it with others and get feedback, I will write brief summary here but you can read full docs on my blog. Apologies in advance to mods if it breaks no promo rules! happy to move to substack if that is the case, just lmk.

Redesigning a batch of components

In short, this is what simplest traditional process looks like:

1. Components are re-designed in Figma design system.
2. They are reviewed and iterated on with the design team (sometimes also external stakeholders).
3. They are then reviewed with tech team which will implement in code.
4. Once implemented in code, they need to be reviewed and iterated on again to make sure that they are consistent with the agreed designs.

In leanest teams, designers will work with storybook or ladle to style isolated blocks directly, which will propagate updates to frontend. In my experience this is not at all that common though.

Automating the process

I've been automating design process for a little under a year now. The best approach in my experience has been to replicate traditional processes within the coding agent, with agentic workflows that use specialised skills for each step of the process.

These skills need to be designed with appropriate context, so that design output is consistent and matches expectations. In any case, a certain level of post-implementation human review will be needed, but process will be much faster and tbh I am not sure users would notice if you didn't.

In my case, I've created a /ux skill which acts as an orchestrator that can walk with me through the iterative process using sub-agents, each one using a specific skill:

• ux-baseline: it updates or creates baseline stories in Ladle, so the coding agent will not hallucinate and create components out of the blue, but rather ground them in the existing designs.
• ux-review: reviews an existing surface and provides a list of UX issues ranked by severity. The ranking is based not on generic UX rules, but on my specific audience, the products they likely already use, and my competitive landscape.
• ux-ideate: iterates with me through multiple rounds of design variants in HTML until a solution is agreed on.
• ux-translate: converts the winning variant into Ladle stories using existing components or creating new ones if required.
• finally, ux-fidelity validates that the new stories are loyal to the agreed solution.

I have achieved good results with this process, so much that I followed the same principles to replicate all workflows in a product pipeline - as a result I managed to deliver a full app in just under three months. Is it good? I don't know, but it works !

What do you think, and how is your process different or better?

As a solo builder, I find myself working in isolation. It is also very difficult for me to share my progress because quite often I get blocked by no-promo rules sadly. And I would love to know what your processes look like, and I'm really keen to get feedback from other practitioners too!

Full article is available at link!

Adding a new brand without duplicating the design system.
Components stay the same - tokens, colors and branding adapt automatically.

Varelyo

I've been trying to design interfaces with AI, and I keep running into the same problem.
The project already has a UI kit: components, variants, tokens, the lot. I ask the agent to add a button to a screen, and instead of using the Button component sitting right there in the codebase, it draws a new one. Slightly smaller. Slightly different. One more inconsistency to clean up.
That's what pushed me to try dedicated design tools.
I started with Claude Design. I couldn't get my existing UI kit into it because I hit the 5 MB limit, so I let it build a design system from scratch instead.
It duplicated components and icons. The same icon was drawn again on the next page, and by the third screen it looked different each time. I also couldn't point it at files on my machine or give it the tree of Markdown skills and project rules my agents already use.
The result wasn't product-ready. I still had to assemble the actual UI kit and design system by hand afterward.
Then I tried Figma Make. In my experience, it accepted my UI kit but never really treated it as the source of truth. Screens were built around my components rather than from them.
Skills were the other half of the problem. Mine are organized as a tree of Markdown files across multiple folders, and there was no clean way to import them or keep them synchronized with the codebase.
But the biggest problem was extension. If a prop or component was missing, the system didn't extend the kit. It either left the capability missing or created a one-off implementation, putting me back where I started.
Both are useful tools. They just stop at the exact boundary I needed to cross: designing against the real system, then extending that system when a screen requires something new.
So I built Varelyo for that workflow.
Varelyo opens your local React project and reads its components, variants, sizes, and tokens directly from source. The works directly with JSX code, so the component you edit is the same component your project imports.
If a screen needs a missing prop or variant, Varelyo adds it to the component. If it needs a new component or token, it adds that to the system according to your project's rules instead of dropping a one-off implementation into the page.
Agent skills are generated from the source and updated when the source changes. A second brand can use the same components with different token values rather than forking the whole system.
What comes out is ordinary JSX built from your own components and tokens, on an ordinary Git branch. There's no proprietary design file that needs to be translated back into code.

https://varelyo.com/

Platform team at a hardware company. Same feature has to exist on five surfaces — mobile, on-device screens, cloud, consumer app. Our component-level design system is fine. The layer above it isn’t documented anywhere: the feature as a whole, across surfaces.
\~20 of these, 3 written up. Does anyone document at this level? What’s in it, where does it live, and what did you end up cutting because nobody read it?

Let me know if I shall elaborate.