This is one of my main topics when integrating design systems for UI concerns, and imho this site does well at demonstrating a central problem and misunderstanding:<p>The author talking about "4 colors", when really he means 4 "color roles" or "theming swatches".<p>First of all, 4 don't cut it.<p>You'll need accents for all of them, to fade sidenotes, visual hierarchy and disabled elements; to differentiate states of interactive; for borders, separators, and other parts of the chrome, and visual distinction of illustrative elements like icons; to give just a few samples ..<p>But the shortcomings of building a design system on 3 swatches for "text, bg, button" will become obvious much sooner, since defining which of the text/bg colors works for the button text depends on the button color itself, etc.<p>What most frameworks, complex and simplistic alike, get wrong imho, is that you need TWO "layers" of color definition, not to cram your palette definition into semantic concerns of the ui to be decorated. Those are separate concerns!<p>Or better said: the purpose of design tokens is not to be an abstraction for css properties of distinctive components.<p>- One Layer is your brand definition, or the color palettes that will serve to define the GUIs design. These are your design tokens<p>- The other layer is a semantic abstraction of the requirements in the design context. These are your "text, bg, button text, button bg, ..."<p>The library of design tokens need to acommodate ANY context the brand design could be applied to, and thus provide a wide range of shades for whatever amount of base colors want to use in the brand design.<p>These will then be mapped to the second layer of "roles", and populate whatever distinct use cases in the design.<p>TLDR: there is no "text, bg, highlight" color. There are "primary, secondary, accent, neutral, ..." color palettes, and "copy text, copy bg, button text, button icon, button bg, hovered button, .." swatches to be populated with them.