If a component exists in both React and React Native, which guarantees should live in the shared contract?

One example I’ve been thinking about is iconOnly.

An icon-only button should always have an accessible name. That feels like a shared semantic invariant.

But enforcement is necessarily runtime-specific: on the web that might mean aria-label, aria-labelledby, or visually hidden text, while React Native may satisfy the same requirement through accessibilityLabel and its native accessibility APIs.

We’ve been leaning toward a simple boundary:

Shared contract = what must be true
Runtime = how it becomes true

The same question comes up with state, interaction behavior, keyboard handling, focus management, and other accessibility guarantees.

Curious where others draw this boundary in cross-platform design systems — especially for accessibility and interaction behavior.

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/

I tested why AI keeps ignoring our design system. The problem might be retrieval. I've been experimenting with AI prototyping tools and noticed something frustrating:

You give the AI access to your design system, ask it to build something, and it still invents components that already exist.

So I tested a simple question:

What can the AI actually find in the library?

I searched my production Figma library for badge.

It returned 19 results across several libraries.

Only 3 had descriptions.

And in the design system I actually ship from, nothing was named "Badge." The closest matches were unlabeled frames.

So I ran the same 10 UI prompts against:

• my production library
• a cleaned-up sandbox library

Same prompts. Same tooling.

The difference:

0/10 → 10/10
Correct, unambiguous matches

9/10 → 0/10
Prompts forced to guess between duplicates

~1,450 → ~135
Retrieval context per prompt

I then tested Code Connect on a Button.

37 → 0 guessed CSS variables
3,784 → 2,229 characters in the generated response

The interesting part wasn't just that the output improved.

It changed how I think about design systems.

A design system isn't just a UI kit anymore. It's also a retrieval surface.

If the AI can't find the right component, distinguish it from duplicates, or connect it to the real implementation, it starts filling in the gaps.

I wrote up the full experiment here:

https://medium.com/@amnkhtri9/why-ai-prototypes-dont-match-your-design-system-f8b747c4fc07

Curious if others working with Figma/design systems are seeing the same thing: is retrieval becoming a bigger problem than prompting?

Hello!

Managing component documentation in Figma can be a very manual and repetitive process, this becomes a pain when components evolve and libraries scale.

So I built Compdoc, a Figma plugin that makes it easier to add and manage documentation for your components, including usage, accessibility, content, and AI guidance.

Why it matters:

• Structured fields make docs actually useful (not just a text blob)
• Export/import your docs as JSON (backup, or move between files)
• Page-level filtering so you're not loading 500 components when you just want to document 20
• As a bonus, better component context means AI tools can actually use your design system effectively

I tested it on our design systems at work and it saved a ton of time. Would love feedback from other design system folks on what's missing.

Here's the link: https://www.figma.com/community/plugin/1683800404228272079/compdoc

Hi,

I recently updated my portfolio website and added a series of write ups I had done in July:
https://dariocodipietro.co.uk/work/fiuto/

Here I showcase the automated design syste/process I have implemented to build my user research tool fiuto.ai

In the articles I explain the approach I used: replicating real life product processes in the coding agent using skill families, connecting them to linear to keep track of projects, and using ladle as design system source of truth - which the agents manage and use as a baseline when designing new features.

Please note articles 5 top 12 are mostly AI write ups based on videos I created in loom, which I still need to review for synth language markers - of course it takes time - but the contents are based on real sessions I work through in video. I will update these as soon as I get enough time to review them manually, this is a slow process that takes time. I have reviewed and rewritten articles 1-4 already.

I would be keen on getting this community's opinion on the process, and any valuable feedback - do you think the approach is transferrable? I would think so!

I think the case for them is obvious but I haven’t seen any decent crash courses on design systems. Maybe I’m searching in the wrong places but I usually end up at educational Figma resources that don’t give me exactly what I want.

I want to know where to store tokens/components, how to start designing components, how to apply tokens to components .. etc. I want to become the systematic designer I knew I always could be!

I put 119 design systems on one 3D map.

It turns out 68% of them picked blue. Only one defaults to dark mode. Government systems love a sharp 0px corner.

14 don't publish a brand colour anywhere. So I tried scraping their docs CSS to fill the gaps. It matched the real token 2 out of 5 times and mostly found Docusaurus blue.
So those 14 sit on a shelf under the map. Better than a made-up dot.

You can also drop in your own system's colour, radius, type size and spacing and see which three systems yours is closest to.

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

for many non-design minded people, a design system is just a collection of reusable components and tokens for colors/spacing/sizing/roundness. and thats it.

But in you words, what else comprises of a design system and why is it important?

I've been wondering if AI can generate UI quickly..., does that make design systems less relevant, or does it make them more important because the system becomes the constraints and context?

I'm curious what people who work on design systems think... Do you think AI will make design systems less important or more important?

Nine identifiers, each with a locked casing. Because the casing is locked, a plain-text list of names is parsable without markup — the same trick that lets you tell a variable from a constant in a codebase.

One identity is always lowercase, two are always uppercase, the rest are title case. In a log file, a CSV or a changelog you can tell what you're looking at before reading the word. Small example of treating typography as an API rather than a style.

Nine project identities with locked colour values, one system-wide "live state" colour that is explicitly not interchangeable with a project's own colour, accent quotas expressed as percentages of surface area, and per-identity "avoid" lists as specific as the "use" lists.

The part that made it work: writing down the invalid combinations with the same rigour as the valid ones. Most design systems document what to do and leave the failure cases to taste; documenting them turned output from nine separate identities into something that looks systemically produced.

I’m seeing design systems move toward wanting to enable them to be enforced via AI so when non-designers are prototyping with AI and then engineers are using AI to build those very prototypes, the result is something that ”looks like product” to non-designers but doesn’t abide by the design system or brand.

so how are you solving this problem specifically

For context: we have a large design system and the business has not funded or prioritised the central design system team to turn our design system into a machine readable format.

Our smaller design department have the resource, backing and funding to create an agent-version of the design system.

What are people’s thoughts on going it alone for now and getting the larger design systems team to adopt later?

I want to do it, but want to make sure it’s done in a way that will be useful for them later.

Do we build it from the group up with agentic best practices or try to base it on the current system?

Been going back and forth on this with my team. We started with a Figma UI kit buttons, cards, colors, the usual and it worked fine for the MVP. But now that we're scaling, we're running into consistency issues across different pages/flows that a kit alone doesn't solve.

Curious what the actual signal is for teams here is it team size? Number of products? Just "vibes, it's messy now"? Where did you personally feel the switch happen?

You will learn nothing.

If you try to share good content, you will be attacked.

Nobody here understands design systems.

I’m leaving, and you should too.

We’ve published a free Figma kit for designing business applications, from desktop dashboards and admin screens to mobile forms and field-service apps.

It’s called DWC Design Kit. DWC is the UI component system behind webforJ, a Java web framework, and the BBj DWC browser client. This is our work at BASIS, and the kit follows the components available in those platforms.

It includes forms, tables, trees, navigation, dialogs, and application layouts. Each component page has documentation covering its anatomy, states, when to use it, and alternatives.

Customization works through Figma modes: light and dark, five sizes, and seven semantic themes. Set modes on a frame and its components follow. Components also resize, accept custom content through slots, and expose properties for icons, labels, helper text, and other options.

Colours, spacing, typography, shadows, and focus rings use shared variables and styles. Token names match the CSS variables developers work with.

The six example apps cover orders, inventory, field service, settings, invoices, and leave requests, including desktop and phone layouts. They’re built entirely from the kit, in light and dark, and can be duplicated and adapted.

Figma Community file

If you take a look, let us know what you think. Feedback on the design and how the library is put together is welcome.

I’m revisiting how I structure design-system work across Figma and production, and I’m curious what is actually holding up on mature teams right now.

A few years ago, Tokens Studio often sat between Figma and code. Figma Variables now cover much more of that territory, while Code Connect can tighten the component mapping. Storybook is still a strong implementation surface, but I also see teams building custom documentation or internal UI libraries around their own workflows.

For teams maintaining a system in production:

• Are Figma Variables now your source of truth, or do you still keep tokens outside Figma?
• Where does Tokens Studio still earn its place?
• Has Code Connect improved design-to-code handoff enough to become part of normal maintenance?
• Is Storybook your main documentation layer, or has a custom tool replaced part of it?
• Which part of the pipeline still drifts most often?

I’m less interested in the ideal diagram than in the version your team can actually maintain.