u/TrifleOk5042

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?

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

Been tasked with figuring out how to wrangle all the AI dev going on at our company to follow some sort of basic design guidelines. We decided to redesign everything the same time we adopted AI so things are chaotic with no global design system in use.

Been playing with Claude Design this week using the new Design System tool and...it's "neat" and "kinda cool" but...isn't really building out a comprehensive design system.

At best it seems to create some general font and color rules and that's about it.

Has anyone found a good workflow to take this to the next step...where we can start spec'ing out individual components, using claude design to tweak them as needed, organizing our tokens into primitive/semantic/etc? That kind of thing?

There still seems to no consistent road map for any of this. Not sure if I should be building a whole bunch of skills (A skill for each element of the design system) or maybe have claude just build out a design system website for me that we point devs to?

Anyone found a path that is working?

Again, not trying to necessarily build the 'master design system to beat all' but rather 'something good enough to at least stop the hemorrhaging of all the inconsistent stuff currently being built by everyone randomly..."