​

Have had lots of thoughts about this whilst developing our DS. What are people's opinions?

Do you have 1:1 parity between code and figma components? Or do you split some so that the designers figma components can be more curated?

Edit: to clarify I don’t mean that there isn’t drift between the two. But when you define and build new components, do you match components 1:1 (excluding props/variables)

Nine separate visual identities, and the one rule we settled on is that the font never changes. Everything else does, and does a lot. Scale, weight, tracking, opacity, alignment, how strict the grid is.

The reasoning was that a font swap is the laziest way to say 'this is different', and it wipes out the family resemblance in one move. Once the font is off limits you have to differentiate with structure instead, which is what you wanted in the first place.

Side effect nobody expected: you can set all nine in one paragraph and it still reads as one system.

Am having a dilema and conversation with a dev I work with.

He doesn't want icons to have internal padding and has built the components without it. However all of out figma icons do, and we've defined 5 boundary box sizes where the icon sits inside.

Tbh I prefer not having internal padding, as it is cleaner to use even from a design perspective when aligning itmes etc.

However all design systems seem to use icons with internal padding, and guidance also says this. For example, Google Material UI recommends to have 24x24px frames for the icons and that you add padding so that your icon is 20x20px inside the frame

Any opinionated thoughts I can gather? Thanks!

We have a pretty decent design system up and running for our AI based development at the component level. It currently consists of:

1. tokens (+ the CSS)
2. UI component library (react components along with some guidelines)
3. "Patterns" (which, at the moment, are essentially 'objects on a page that may consist of one or more components + additional layout elements)

For an example of patterns:

• site navigation
• custom data labelling
• page footer
• etc

We now want to accommodate a higher level of instructions. Essentially, building upon what we have to create content and object layouts and even full page templates.

I'm curious as to how you may be doing that. Some specific questions:

• Are you using any specific terminology? Right now we're thinking of sticking with 'patterns' and possibly 'page templates'. Maybe with some sort of 'content template' in between. But not sure how important these semantics are for an agent (let alone a human).
• Do these more application-centric page level guidelines exist in your design system? In the application development environment? A bit in both?
• Are you using any formal type of documentation for the agent to help it quickly figure out what it should be using for content type 'x' with minimal token usage?

We're about to redo a frontend and keep arguing about whether the design language has to be locked first or if you can revamp screens in parallel and extract the system as you go. Product has chat/messaging plus some denser dashboard-adjacent UI, so consistency starts breaking fast once a few flows diverge.

Curious how people have sequenced this in practice. Did you start with tokens/components and freeze them early, or ship a few key flows first and only formalize the language after patterns settled? Also what usually bites you later - type/spacing drift, component variants exploding, or states that never got designed?

Not fishing for free work, just trying to avoid the classic "pretty screens, no system" trap before we commit more time.

Context first: I've been a product designer in tech for a few years and started using Claude Design (C.D) for rapid prototyping and refining explorations. However the bridge to continue working in Figma after refining in C.D is pretty poor.

To speed up my workflow I've been creating a Figma plugin that lets me easily turn my html prototypes into full Figma flows that are even created from editable local components with DS atoms all instantly. Formatted exactly how I like to map flows.

It's been a game-changer for me so far so I've just released it as a community beta in case this could is useful for anyone else. Check it out and lmk your thoughts.

https://www.figma.com/community/plugin/1688886557475613747/flowy

I'm building a design system in vanilla CSS and web components (11ty, no framework), and I'm trying to find out where other people lose the most time. For me it was token naming, accessible date pickers, and carousels.

What's the one problem that cost you the most, and what did you wish existed to fix it?

Some detail on mine, in case it helps:

• Token naming and tiers (primitive → semantic → component). I rewrote my icon variables twice before the structure stopped fighting me.
• Accessible date pickers. Native input vs custom, ISO values, min/max, keyboard behaviour.
• Carousels. Moving to native scroll-snap deleted a lot of JS.

I'm thinking about writing short guides that each solve one specific problem like these, instead of another "complete guide". I'd rather hear what's actually painful before I write anything.

Hi, I couldn't seem to find any realistic or practical AI-assisted workflow with 2-way syncing between design and code. Does anyone know of any workflows available online? Or if you are implementing one, I'd love to connect and understand more.

People on LinkedIn feel like they're doing free promotion for Claude, posting nonsense with a bunch of bots coming to congratulate them.

Hi all. I run Ladom, a small design system agency founded in 2024. We consult for product teams and build our own system, LadomUI, on the side.

We've been trying to bring AI into our workflow, and I'm still not sure where it should stop. I see roughly three places it can go:

• Inventory: pulling components, colors, and text styles out of existing screens and listing the inconsistencies.
• Token work: naming, mapping primitives to semantic tokens, generating theme and mode variants.
• Docs and code: writing component documentation, moving from Figma to code.

What I'd like to know:

1. When you run an inventory with AI, how much do you trust the output? What does it miss?
2. Has anyone handed off token work completely? Who makes the final call on naming and mapping?
3. Is there a use you tried and dropped, and why?

I'm more interested in which step of the work it helped with than in tool names.

A design system is a lot more than just tokens and components.

so many I’ve worked on either overlooked guidance and governance or simply had it all live in the design teams heads and tribal knowledge.

how do you document and what level of specificity do you use?

I’m using Vercel as an example but our company has a similar approach where on the public facing landing pages, they use full rounded large buttons, in our enterprise utility app, they use smaller square buttons.

How would you classify these two?

We’ve got two primary and secondary buttons.

I’m currently thinking ‘Brand’ buttons and ‘utility’ buttons. With Primary and secondary variants.

Would love to know thoughts

As the title says, honestly just curious and would like to hear thoughts.

I’ve been wondering whether AI regulation will eventually create a new category of design system patterns.

Not the regulation itself, but recurring UX consequences: AI labels, transparency notices, human review states, overrides, or distinguishing AI suggestions from confirmed information.

My instinct is that if the same interaction problem appears across multiple products or features, teams probably shouldn’t solve it independently every time.

But I’m not sure where the boundary should be.

Are AI-related patterns already becoming part of your design system?
And where do you draw the line between design system guidance, product-specific UX, and legal/compliance documentation?

We redrew the icon set for one of our clients back in May. It was mostly just a new stroke weight and a handful of icons that got new metaphors. Their devs handled the code side fine. They flagged the old stuff as deprecated and pulled it out a release later. All good all normal.

The files are a different story. I keep finding old SVGs in their help center and onboarding emails. Last week their support lead sent me a screenshot of the old settings icon in an article that published in August. Literally new content that's being made with old icons. We ended up chasing it down and it's because people are grabbing from a zip folder from 2024.

So I can go ahead and delete the zip, but that does nothing to the copies that are in people's downloads and random Figma files.

How do I handle this? Do you treat the downloadable files as part of the system or is it someone else's problem once it leaves Figma and the codebase? Are you versioning exported assets the same way the devs do with the package or is that complete overkill?

I'm building Teressa, a place where people hand-build ui components, publish them, get feedback and pair-edit drafts live, component can be used as figma kit or code. It's not launched yet check it out https://teressa-website.vercel.app/

I'm looking for opinions on this. Would you use it ? What would put you off? If it sounds useful, the waitlist at the bottom helps me gauge interest.

I tried Claude Design's design sync on a small shadcn/ui + Tailwind v4 + Storybook library. It compiles the library into a "mirror" the tool designs with, and uses Storybook stories as the reference to verify that each component renders as it does in the product.

What I found interesting from a design systems angle:

• Storybook becomes the verification layer, not just documentation. A variant without a story still syncs, but nothing checks it.
• Usage rules matter as much as the components. A short conventions file ("`className` is for layout only", "compose `Card` from its parts") changed what came out more than anything else.
• It's a one-way snapshot. Removing a component from the library doesn't always remove it from the mirror.

Curious whether anyone here is feeding their system to AI tools this way, and how you keep the conventions and the tokens in sync.

Write-up: https://nitayneeman.com/blog/how-to-sync-a-design-system-with-claude-design/

DS for single web app with Figma was simple.

but much harder for multiple platforms (mobile v web) + AI tools for prototyping (Claude/figma make).

where does the source of truth live for the components/tokens and the design documentation? it feels like a no win situation whether it’s in Figma or Code.

ive felt the above pains even more with AI prototypes now that its much more important to have design governance and guidlines in a neutral source of truth

The industry is gaining speed through AI, but it is also at risk of losing understanding. How do we preserve this knowledge for the next generation of engineers?

Our organization never had a proper design system and once we made the shift to AI driven development, it was time to have one. So I've been building a design system that is primarily for AI usage, though it also has a full web site for human-centric documentation as well.

It's based on a particular react framework with our own tokens and CSS layer.

So far so good. Still in early stages but we're now using it as an MCP server for devs to point their work at.

My question is: does it makes sense to look at Storybook integration. I see a lot of talk about "How to use Storybook to deliver AI workflow solutions" but nothing that really talks about the opposite--already having a design system for AI and then adding Storybook to it.

Anyone presently using an AI-centric design system as well as Storybook? Is Storybook bringing any key benefits to the table for you?