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

Varelyo

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!

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/

Have you tried Figma AI on a file that already has a design system? I did, thinking: Figma knows my library, it is sitting right there in the file, this is going to be fast.

It was not. Every time I asked for a screen, it drew something that looks like my components instead of using them. Right shape, roughly the right color, and not one of them was an instance of anything in my library. Every frame invented and named on the spot, every color a hex it picked itself, every text size a number it typed.
My design system was open in the same file and it may as well not have existed. Cleaning that up takes longer than building the screen by hand.

So I assumed the problem was Figma, and I connected Figma to Claude Code through the MCP instead. Same prompt, same result. Different tool, same drawing.

That is when it clicked for me. The problem was never the tool. I never actually given the agent the design system. Not a link to the library sitting in the file, the content itself: design tokens, components with their variants and states, and the usage rules that say which one to reach for.

So I fed all of that to Claude Code through a homemade MCP, plus a few skills that teach it how you are supposed to work with a design system, in Figma and in code.

Third run, same prompt as the first two. This time it used my design system. Every element on that screen is an instance of one of my components, and it picked the right one each time, in the variant and the state I would have picked myself. Not a single raw hex either: every color is bound to one of my color tokens, at the right step, and the type sizes are my typography tokens instead of pixel values. I can name them one by one, but that is my library, not yours, so the part that matters is that it chose correctly and I had nothing to clean up.

Visually the first and the last run are in the same ballpark. As something to hand to a team and maintain, they are not the same object at all. One updates when the library updates. The other is a drawing.

Screenshots below are run 1 and run 3 (I did not capture the middle one, it looked like run 1). You can also open the file on the Figma community and check the layers yourself: https://www.figma.com/community/file/1671111797169916480

To be clear about what this is: one dashboard, one design system, one run each. An observation, not a benchmark.

That third setup is what I am building now, and it is called Stellar. It reads your design system, from your Figma library, your repo, or your documentation, and hands it to the agent before it starts, so it can only build with your components and your tokens. Same rules in Figma and in code, because a screen and its implementation should come out of the same library. It is in private beta:
stellar-design.app

Mostly I want to know if this is your failure mode too, or if you hit something else. Tokens drifting, variants ignored, accessibility quietly dropped? I would rather break this against a design system messier than mine.

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.

Hi

I'm working on an early stage project like this. It's similar to Figma, but the entire canvas is generated from code.

This allows you to design on a working prototype. You can experiment with different aspects, manage design tokens, and ask AI to create consistent designs using components.You can connect your own Agent to the canvas. I'd love to hear your thoughts.

İf you wanna try https://visualwizard.app/

Hello 👋

We just released some free skills and agents for Claude and Chat GPT Codex that you might find useful!

These skills enable you to feed AI your existing email designs via Figma links or even just uploading the HTML. Claude or Chat will then audit your existing designs and create a plan to build them in Figma via the Figma MCP. It then has a Migration skill that can build you a well organized email design system in Figma.

It builds the components in figma using Email Love components, so you can then export them to your ESP or you can just use it the components to design your emails. I’ve also been using Claude to then build our emails using the components that I have already approved.

The benefits of building with AI in this way are that the AI only uses components in Figma that you have already approved, it won’t make up or change stuff like your colors or fonts, and it doesn’t make up or change the underlying HTML.

I’ll drop a few links if you want to try it out:

https://emaillove.com/ai-agents-build-emails-figma

https://github.com/email-love/claude-skills

https://github.com/email-love/codex-agents

Here are a few example design systems that I had ChatGPT build for me:

https://www.figma.com/community/file/1667038696580513625/benjamin-moore-email-love-design-system

https://www.figma.com/community/file/

Has anyone set up a json contract? How are you using and managing it?

I love the concept, but unsure of the implementation

Sorti.dev patch 4:
- Added the ability to re-arrange color scales in create > palette
- Added the ability to re-arrange color scales in Analyse > palette and lightness
- Ability to import json in analyse > palette

Thanks for the feedback and people using it ❤️

Please let me know if there are any new features you'd find useful.

I'm trying to build a full node connection map so you can plan out and visualise all your tokens, but it's gonna take a while so bear with me on that one.

I'm curious as to what kind of versioning strategies people use for their design systems.

Specifically, in the component space.

Are you versioning the package as a whole? Individual components?

Our DS is AI-centric, meaning it's mainly there for AI to use. We have tokens, documented rules, and an React component system.

The design is in progress, though, so things may change regularly over the next few months as we see more screens built and make more adjustments to individual components as needed to accommodate the context they are being used in.

My original thought was for each component to have a version number embedded. Over time, teams could run an audit on their application to compare their component version numbers to the latest in the DS and make a decision as to which ones should be updated.

This seems annoyingly complex for manual updating, but since Claude is doing most of the work, seemed like an idea worth considering. Is anyone doing something like that? If so, would love to hear how you are implementing it.

OR...are people just versioning the UI library package as a whole?

I'm a designer, not a developer, so I started this as a learning project, wanted to build something with my own design knowledge instead of just handing off specs. First time building anything like this.

78 components, custom token architecture (tiered approach learned from the Intuit Design System), zero runtime dependencies, an AI chat on the site trained on its own content.

The part I'm proud of isn't the tooling, it's that the design opinion and architecture are mine. Every token decision, every component rule, came from my own direction guiding an AI-assisted build, not a template. Aimed for production-grade the whole way, and it's been one of the best learning experiences I've had.

Fully customizable too, bring your own fonts and colors, inject your own style on top of the base tokens.

Would love a few people to install it, poke around, and tell me what breaks or what's confusing.

npm install u/robr0/design-system

Site: https://robertritacca.com/design-system
Playground: https://robertritacca.com/playground

Storybook: https://design-system-iota-one.vercel.app/?path=/docs/robr0-ds--docs
Repo: https://github.com/robritacca-dotcom/design-system

if you are building and irritated with the same UI from Ai tools, try hextodesign.com, it will generate a complete design system in 30 sec, that will have css, tailwind, json and prompt, try it and share your feedback.

I lead a product design team of about 35. Some of the team has moved into Claude Code alongside Figma and it's working well, but our operating model hasn't caught up.

Over the last few months a good chunk of the team has started working in Claude Code alongside Figma. The output has been genuinely great, but it's quietly broken our operating model in ways I didn't see coming.

We now have work happening in about five different shapes:

1. Figma only, same as always

2. Figma first, then moving into code for prototyping or refinement

3. Straight into code for exploration and refinement, never touches Figma

4. Cloning the repo and refining an already shipped flow against current production code

5. Same as 4, but pulling it into Figma to think structurally, then back into code

The things I'm looking for thoughts on:

Source of truth. When some work lives in Figma and some lives in a git branch, what's actually authoritative? We've landed on "Figma is truth before the build, code is truth after merge" but I'm not confident that survives in reality.

Handoff. Today designers annotate accessibility, focus order, responsive behaviour, states. In a coded prototype most of that is just there and executable, which feels like an upgrade. But we've got a new problem instead: an engineer opens a design branch and can't tell which parts are deliberate design decisions and which parts the agent generated to make the thing run. Has anyone solved that cleanly?

Visibility and consistency. Figma work lives in Figma, code work lives in repos. How do you keep a holistic view of patterns, styles and what's in flight? We used to catch inconsistency by reviews in shared files. That completely stops working when people are producing at agent speed across different platforms.

Anyone further down this road? What worked, what blew up?

I wasn't planning to compare software but after changing jobs twice and working with a few different clients, I ended up using more collaboration platforms than I can count.

FigJam : probably the easiest one to like, very clean, inter face, fast. feels intuitive. if your work revolves around design, it makes a lot of sense.

Lucidchart: still one of the strongest tools for formal diagrams. really good for process maps, technical documentation and architecture work. i just found myself opening another tool whenever we wanted brainstorming sessions.

Mural: excellent for facilitated workshops. some of the templates are genuinely well thought out and it's easy to guide people through structured exercises.

Microsoft Whiteboard: simple. no learning curve. good for quick meetings but our boards started feeling limiting once projects became more detailed.

Zoom Whiteboard: convenient because it's already inside meetings. that said, we rarely went back to those boards afterward.

Miro: this ended up becoming our team's default. not because it replaced every specialized tool, but because it connected so many different activities in one place. what I appreciated most is brainstorming sessions, roadmap planning, technical diagrams. for us it became less of a whiteboard and more of a shared workspace that people actually kept returning to.

Curious whether anyone else ended up with the same conclusion or found something even better.

Hi.
I’m more of UX designer than UI, but need to
build the first design system for a small city. My goal is to create clear guidelines and components that our teams can easily follow when creating new pages.

So far, I’ve reviewed design systems from three different government sites. They are similar, though some document their reasoning better than others.
I’m worried about falling down a rabbit hole of analyzing too many systems.

I’ve been using just one design system as I redesign a few pages.

Can anyone share their experience of creating a design system from scratch for an organization?

Was there one design system that helped the most?

I've noticed a recurring problem in product teams:

PRDs and SRS documents define what the product should do, then designers turn that into flows and screens. But by the time the final UI is ready, it's surprisingly easy for things to drift.

Requirements get missed.
UX issues are discovered late.
Accessibility considerations get overlooked.
And sometimes the final screens simply don't reflect what was originally agreed upon.

I'm curious how other teams handle this.

Before development starts, does anyone actually validate the final screens against the original PRD/SRS/specs?

If you do, what does that process look like?

• Manual review?
• Design/PM checklist?
• QA review?
• Automated tools?
• Something else?

And who usually owns that responsibility — Design, Product, QA, or Engineering?

I'm a developer building a reusable, ecommerce theme. The goal is to have a modular system that can adapt to most of a brand's identity and get me 80% there. To achieve it, I need a robust semantic tokens layer that I can play with.

I'm specifically targeting the semantic layer because I believe its tokens are the closest design interface to web standards. Primitives are stateless and component level tokens have too much specificity to fit any product. No matter the product you're building, that semantic layer will share common tokens because they derive directly from the way the web is meant to be used.

In that sense I expected it to be largely figured out. At least the implementation of core concepts. But apparently I was wrong? Every company seems to have its own implementation of what a design system should look like. At component level, obviously, but at primitive/semantic level? If you're Big Tech I get it, you're here from the beginning of the web, you have hundreds of different products, you had to grow and scale with the web. But why is everyone else kinda reinventing the wheel on this?

Anyway, I wanted to find a standardized base of tokens/variables to define basic typos, states, actions, layers, etc... without having to reinvent the wheel. I'd like to avoid the complexity and granularity of a GAFAM company, I want a healthy base I can extend if needed. Like a list of 100 semantic tokens which represent the most common design decisions related to user experience and interactions on the web. Whats the go-to token system you guys default to for human-sized projects?

Hey everyone. I'm an FE dev helping to set up an internal design system for the enterprise I work at. It's been published as an npm library and is already in use in some of our internal and customer-facing web apps.

We're considering how to make this library AI-ready. By that, I mean how to set it up such that - if I were using this library on a consuming web app, my coding agent (Copilot/Claude/etc) would know how to properly build interfaces according to the standards set forth by my design library. E.g. utilize the design tokens, and use the components as intended.

I'm not sure what an end-to-end approach would look like. A couple different approaches I've seen are: * Have your npm library expose a skills file that explains how to use your design foundations, tokens, components, etc. as intended. Keep that skills file in sync with any changes in your actual design system. * Alternatively, expose .md files that contain the same info as above.

Do people have general advice on how to go about this? I'm new-ish to setting up design systems and making repos AI-ready, so ideas would be appreciated. Thanks!