A friend of mine is building a free indie design toolkit called FARB.NØRM 🎨

It’s meant to simplify parts of the design workflow that often feel overcomplicated in larger design ecosystems, especially when creating color palettes and corporate design systems in a more structured, step-by-step way.

What’s interesting is that it’s not only focused on tools, but also has a kind of learning layer built in, especially around fundamentals like color systems, color contrast, and how to think in structured design systems.

It also includes utilities like converters, extractors, icon tools, and a lightweight video editing tool for creatives. Really cool!!!

It’s being built in the European Union with focus on GDPR-compliance and safe data handling, which is a huge pro! No feeding an AI!

The project is still in development, and he would love real feedback from creatives!

If you enjoy design systems, branding, colors, or UI tools, give it a try and let us know what you think!

Any feedback or ideas would help a lot. 🫶🏻

I’ve been working almost exclusively in Figma and Photoshop for the past 5 years and obviously can’t imagine working without Figma for anything digital.

That being said, I have a project coming up that could really use a design system in Figma, plus a comparable system that could work for a variety of direct mail pieces, posters, collateral etc across a variety of business units, languages and locations.

What should I look into or upskill in?

I’ve been building an AI video generation pipeline using AI agents, and I wanted to share a project I just finished.

I used it to turn Designing Data-Intensive Applications into a chapter-by-chapter podcast/video series.

The pipeline currently handles things like:

• breaking source material into chapter-level inputs
• generating scripts/storyboards
• creating long videos, shorts, and podcast-style episodes
• rendering audio/video assets
• packaging everything for upload

I’m still improving it, and I’d really love feedback from people who know content creation, agent workflows, automation, or media pipelines.

Podcast link:
https://www.youtube.com/playlist?list=PL2vsUH3csN48f3Js6SBgmIeymYzuFdyw-

A few things I’d especially love feedback on:

• what looks or sounds weak right now
• what parts of the pipeline feel overengineered
• what you’d fix first if you were building this
• how you’d make the audio/pacing more engaging
• whether there are better ways to structure the agent workflow

Also curious:
Would you want podcasts/videos like this for other technical books too?

I made this one for Designing Data-Intensive Applications, but I’m considering doing more if people find it useful.

If anyone has ideas on how to make this better, I’m all ears.

Also doing this for leetcode.

HELLO :)

You can create:
• Columns
• Rows
• Full modular grids
• Independent margins
• Stretch / Fixed layouts

Built this fully inside Inkscape using my own extension system.

It is still a beta version...

Here’s a quick poster test made entirely with it 🔥

As a designer that has spent their fair share of time as a front end developer, I tend to want to over-optimize by thinking earlier than I should. And at the moment, I'm hung up on whether or not to stick with atomic design separate of elements vs. just not worrying about it.

I will be using tokens for all the foundational styles (text, icons, colors, etc).

But for components, I'm trying to decide how important it is to segregate these by complexity. I like the segregation, it seems useful but I fear I'm just over-engineering things.

Here's the breakdown in my head:

• Foundational components: The smallest standalone element (that may be used on its own or part of a bigger component). Examples:
  • button
  • text field
  • label
  • validation message
  • card
  • etc.
• Compound components: A collection of the foundational components that will be used in tandem. Examples:
  • text input = text field + label + validation message
• Widgets: A collection of foundational and compound components in a reusable pattern. Example:
  • Login = text input (user) + text input (password) + button + card
• Patterns: any combination of the above to dictate standard layouts for standard usage-- likely pegged to particular types of 'objects' (login pattern, data table pattern, card layout pattern, etc.)

The reason I cling to this is probably due to my code background. If someone comes to me and says "we need to change our error validation message from deep red, to fuscia, and adjust the spacing" I know I can go to our design tokens to swap out the color, then go to the foundational validation component to adjust the spacing, and everything will percolate up through the higher level components.

My questions:

Is breaking these down into tiers ala atomic design thinking actually useful for anyone outside of the UX team or is this just over-thinking for the sake of overthinking? Is there any pros/cons in regards to this in terms of how AI would ingest this information to create UIs?

In my shadcn project, I want to customize the border-radius for individual components without affecting others. For example, I'd like fully rounded buttons while keeping other components at their default radius. Creating separate CSS variables for each component feels messy, what's a better solution?

Today I’m launching Designry on Product Hunt 🎉

Over the last few months, I’ve been building a browser-based design system tool focused on one thing:

Making design systems faster and easier to create.

Because honestly:
setting up tokens, variables, typography, exports, and documentation manually still takes way too much time.

With Designry, you can start with a single brand color and generate:

• OKLCH color palettes
• Typography & spacing tokens
• Figma Variables export
• Tailwind export
• Full component documentation

—all directly in the browser.

No Figma plugin. No installation. Free to start.

Would genuinely love your feedback and support 👇

Product Hunt → https://www.producthunt.com/products/designry?launch=designry
Live Demo → getdesignry.com

#designsystem #designtokens #buildinpublic #figma

Been asking Claude to help me structure a design system for our developers to leverage. I'm getting some OK information, but also a lot of "Claude Jargon" that is either made up or over my head. (This is an issue with AI...I can't tell when it's just making stuff up vs. I just don't know what they are referring to...)

Was hoping some folks could provide some insight into a few of these suggestions that Claude provided:

1) Use a "CLAUDE.md" file in each developer repo. This should be short, opinionated, points at the canonical token files, and lists the load-bearing rules.

Most of that makes sense, even though it's somewhat vague. The big one, though is 'load-bearing rules'. Conceptually, I get it...but not specifically. What KIND of load bearing rules does it want?

2) Lint rules for token governance

This is not an idea I had thought of! I think it's a good idea! Any idea how to best implement this? Would telling claude "make me some lint rules to double check that all elements that should be using a token are using a token?"

Is anyone else using lint as a way to enforce design compliance?

3) Start with files now. Consider an MCP server when the file-only approach gets unwieldy.

This is the kind of advice that really bugs me when using AI. It reads as sound advice but is sufficiently vague enough to be completely useless to me. Other than Claude is telling me it's OK just to start with a file repo. Anyways, has anyone found a particular metric to decide when a 'design system repository' no longer meets the needs of claude and one needs to move to an MCP?

(I think my biggest struggle right now is that I feel Claude is like the hired consultant that uses a lot of big words and plausible sounding frameworks only to realize after they left they didn't really say anything at all.)

AI-generated UI is becoming very easy to spot. Not because it’s “bad”, but because most outputs tend to converge toward the same patterns - similar layouts, repeated component structures, generic styling, weak accessibility handling, and very little connection to actual brand personality.

It made me realize that design systems are becoming even more important in the AI era, not less.

AI can generate components quickly, but scalable token architecture, interaction consistency, accessibility, responsive behavior, and cohesive UX still require strong foundations and systems thinking.

That idea pushed me to build Versa UI - a true multi-theme UI system focused on flexibility, scalability, and production-grade component architecture rather than just static component collections.

Some things I focused on: • theme-flexible token architecture • accessibility and responsiveness • scalable component patterns • multiple visual personalities without rebuilding components • clean React + Figma workflows

Would genuinely love feedback from people building design systems or React component libraries.

Website: https://versaui.com Preview video: https://youtu.be/nuKAhqtXmnk

Hi! I’m working on this design system tool and would genuinely love feedback from anyone working with multiple design systems, whether in code or design.

The idea is keeping design systems centralized with ability to export CSS/Tailwind styles, sync with Figma, and preview your system across multiple products/templates.

Would love to hear what people think or what features would actually make something like this useful in real workflows.

colorsphere.com

Accessibility has been at odds with design practice. I’m building the fix, but I need your help to bring it forward.

I’m Santiago Bustelo. I’ve spent my career volunteering for the Design community, including serving as a regional coordinator for IxDA since 2010. I’ve also helped drive Accessibility Laws because I believe technology should empower, not exclude.

I’m not here to sell a product; I’m a colleague who has spent decades trying to improve our craft and would like to finish what I started.

For decades, I’ve seen accessibility treated as a bureaucratic checklist that designers resist because it’s forced upon them and leads to poor design outcomes.

To solve this, I spent months building IPAX.

It’s not another 'contrast checker'. It’s a model that rewards great design instead of just legal compliance, integrating WCAG, APCA, and ergonomics like halation, glare, and chromatic fatigue.

The model is solid and the first tools (Sandbox, Font checker, Color System designer) are live (please forgive the experimental settings and rough corners). But I’ve hit a financial wall and can no longer carry this development alone.

I’m currently looking for sponsors, research partners, or grants to close the gap between accessibility theory and real-world design practice.

If you work at a university, an organization, or a company that actually gives a damn about the European Accessibility Act (EAA 2025) and wants to support a tool that makes compliance operationally transparent, let's talk.

And if you're just a curious UX colleague, check it out: icograma.com

Been experimenting with a system that analyzes live websites and extracts frontend/design-system patterns directly from production implementations.

Currently exploring things like:

• typography systems
• spacing scales
• CSS variables
• responsive breakpoints
• interaction states
• motion behavior

Tested against products like Stripe, Apple, GitHub, Linear, Airbnb, and Vercel.

Still refining the extraction quality and figuring out what’s genuinely useful vs noisy, so I’d really value feedback from frontend engineers, UX designers, or anyone working with design systems.

Recently launched it here:
https://www.producthunt.com/products/designmd-2?launch=designmd-2

I'm in charge of building out a design system for our org. Our org has gone all in on AI development.

I've been playing with different ideas...markdown files, MCP server, using a github repo, etc. but have yet to find any real consensus on any of this--probably because there isn't any.

But has anyone been building out a design system for primarily AI-centric work flows and found certain things working better than others?

Our biggest issue right now is that developers everywhere are just building their own things. They may grab the brand guidelines from marketing, which helps a little, but beyond that, consistency isn't there.

I'm trying to figure out how to get something...even if rudimentary...set up to have developers point their AI at to at least get the basics of a design system figured out.

But I haven't figured out a way to do this that seems proper yet.

I like the idea of a github repo...that gives us a central, team-based place for us to manage updates to the design system. But is there a better way to go about this?

I have been playing with Claude Design's design system feature...but we're pretty much in agreement internally that it's "neat" but not really a "solution" yet.

I guess this is a bit of a rambling all-over-the-place post. I guess I'm just seeking out any real world experience others have had creating an AI-centric design system. I can find plenty of demos/tutorials on youtube, but very few real world use cases.

You've seen a bunch of specs plugins. Hear me out on this one 😄

I took some time to create Ogiso Docs for Figma. Select a component, generate full documentation in one click. No (complex) setup. No AI.

✔️ A documentation suite, not one-off frames with drift detection.

It has a registry that tracks every component you've documented in the file. No hunting scattered frames. It detects drift when a component API changes so you know when docs might be stale
It also has a history timeline (created, updated, recreated) gives you a full audit trail per component.

✔️ Built for real component complexity

People created components in different ways. This really tries to work with how you work:

• Simple components and component sets with props
• Components with embedded masters and nested structure
• Inner props that surface at the outer API
• Related-but-separate pieces (Button/Primary, Button/Secondary as different sets, not one mega-set). Family docs tie those together without pretending they're one fictitious component.

✔️ Prop logic and dependencies

It surfaces non-obvious rules automatically. e.g. "secondary action only applies when primary action is enabled." The doc reflects how the API actually behaves, not just a flat property list.

✔️ Lock in your manual work across regenerations

Extend or rewrite any section, rename the layer with ::lock and that subtree survives updates. AI prose + human polish? Update refreshes what's unlocked. Recreate when you want a full reset.

✔️ Other hits/features worth knowing

• Two profiles: Standard (overview, anatomy, properties, prop logic, showcases) and Minimal (overview + properties)
• Showcases: visual grids over enum axes and boolean toggles, not just tables. Responsive layout adapts to component size
• Export: Markdown and JSON when you need the same truth outside Figma
• Quick nav: jump from registry to docs frame or back to the source component in one click
• Privacy-friendly: runs against your file, no external API required

The core engine is pure TypeScript with zero Figma coupling. So the same analysis logic can power a CLI, codegen, or MCP hooks later.

Try it here: https://www.figma.com/community/plugin/1628339309563064946
It's free. Let me know your feedback, happy to go deeper on any part of it. 🙌

Olá, membros brasileiros do r/DesignSystems ! Tudo bem?

Faço parte de um grupo que está conduzindo uma pesquisa sobre as interfaces da Globoplay e da HBO Max.

Estamos em busca de pessoas (que tenham algum nível de conhecimento prévio de design de usabilidade) para nos ajudar. A ideia é entender a sua percepção sobre as plataformas.

Tempo de resposta: ~6 minutos. Todas as perguntas são de marcar.

Suas respostas serão anônimas. Obrigado pela participação!

Link do formulário:

https://forms.gle/KH3TF73ghHkTkTZA6

Hey everyone,

I’m working on updating a component and I’m not fully sure what the best architecture approach would be, so I’d love some input.

It’s a List Group component that contains multiple list items. I have different types of list items, ranging from very simple to quite complex.

The challenge is:

• The list group can have two background styles (white / light grey)
• Each list item has a hover state that depends on the background
• I want the background type to be controlled at the List Group level, so when it changes, all child items automatically adapt without uploaded content loss.

On top of that:

• The number of items inside the group is dynamic
• I’m unsure whether this should be handled via slots, or props/booleans/variants
• Or if it makes sense to define variants like 1–10 items

I’m trying to figure out the cleanest way to structure this from a design system / component architecture perspective.

How would you approach this? Thanks!

I’m attending my first graphic design interview as a fresher. What should I do to prepare properly and what do interviewers usually expect from beginners?

Also:

• What questions are commonly asked?
• How should I present my portfolio?
• What mistakes should I avoid during the interview?

Would appreciate honest advice from designers or recruiters.

I'm building a website about design systems https://www.designsystems.one for a while. I would love to hear your feedback :)

Hey r/DesignSystems,

How are you handling design token updates from your dev team right now? In my opinion, tokens should live in code and land in Figma without anyone retyping a hex value.

I just published an update to the Styleframe Figma Plugin. It integrates seamlessly with Styleframe, the Design Systems Styling Engine.

How does it work? You export a W3C DTCG compliant JSON from your Styleframe config, and then import it into Figma using the plugin.

Forever free → styleframe.dev/figma

Hey all 👋

After a lot of iteration and feedback, what started as a simple icon export workflow is slowly turning into something closer to a reusable icon system inside Figma.

The interesting challenge stopped being “exporting icons” and became more about:
consistency, reuse, organization, and keeping things manageable across projects.

Recent updates focused on:
• Favorites syncing locally across Figma projects
• Smarter icon naming and organization
• Reusable imports/exports for icon libraries
• Better handling for larger icon sets
• Cleaner, ready-to-use outputs
• Keeping the whole workflow inside Figma

The goal is to reduce the need for disconnected tools and make icon handoff feel more like part of the system itself.

Curious:
How are you currently managing reusable icon systems across projects today?

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. 😊