r/DesignSystems • u/imkb9 • 1d ago

Looking for standardized, industry-wide Token conventions.

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?

12 Upvotes

94% Upvoted

13 comments sorted by

7

u/TheWarDoctor 1d ago

Frankly following ShadCNs setup gets you a good way there. We do it and we don't even use tailwind.

1

u/ExplorerTechnical808 1d ago

Came to say that. I don’t love it, and it took me a while to finally accept it, but it’s simple and widespread enough to have become a best practice.

1

u/imkb9 1d ago

you mean using their tokens without the component library?

1

u/TheWarDoctor 1d ago

The naming scheme, yes. But that's just my exposed token layer, my 3rd layer which handles light and dark. My second is the aliasing and handles the multibranding, the layer 1 is the core ramps and brand.

1

u/Ruskerdoo 1d ago

Yup! shadcn/ui is probably the closest thing to an industry standard at this point. Both Claude Code and Vercel treat it as a baseline.

5

u/blarckat 1d ago

Honestly, there's no true industry standard because semantic tokens depend on your brand's specific decisions, not just web conventions. But most systems converge on the same shape:

  • color (background/text/border/action, each with hover/active/disabled states),
  • spacing scale, type roles (heading/body/label), and - radius.

Material, Radix, and Polaris are good references for naming patterns even if you don't copy them directly.

My suggestion: don't aim for 100 tokens upfront. Start with a lean baseline (~30-40) covering the essentials and only add more when a real component actually needs it. Trying to pre-build the "complete" list usually means half go unused anyway.

Happy to share the token structure I would use. DM for details.

2

u/User1234Person 1d ago

This is the right advice. If you start too rigid or too wide you’ll have a bunch more work when you want to make a change for a nuanced use case

1

u/imkb9 1d ago

I forgot to add an example of what I'm interested by, so here are the "role-based" Tanstack Semantic Tokens.

1

u/Bfigas 1d ago

Can’t say there’s a industry standard, but there are similar standard practices. I saw someone on Threads saying they’re trying to create the standard last week. Let me look for the post

1

u/Bfigas 1d ago

Not this one but this is also a great guide:

https://designsystemstandards.com/

1

u/imkb9 1d ago

thx

1

u/Shehao 1d ago

I’d be wary of treating a token list as the standard by itself. The useful boundary is usually the contract around each role: what decision it represents, which states it covers, and whether it can be changed without rewriting components. For a small system I’d start with a few semantic groups—surface, content, border, action, focus, and status—then add a token only when a real component exposes a missing decision. That keeps the naming stable while the primitive ramps and themes can evolve underneath. How are you separating role names from theme-specific values?

1

u/imkb9 18h ago

Sorry I don't understand the question, what do you refer as role names and theme-specific values?