04 · Design · Components and color
When three reds exist at once, nobody knows which one is void
The design-system designer unifies tokens, components, and names. One meaning may have only one expression. Whether a given screen can be read is still the UI designer's job.
State color: Danger, warning, success, info — one each. Void uses the danger color plus words, not a new red.
Document components: List, detail, to-do, empty state come from one set. A new document must first say why it cannot reuse.
Naming: Design files and code use the same component name. Different names are treated as two sets at walkthrough.
The design-system designer reduces forks. He does not add decoration to pages
When several designers and several frontends build receiving, expense, and shop-floor reporting at once, each easily ships their own table, their own red, their own empty copy. The design-system designer's job includes the right to say no. A new component must prove the current one cannot do the viewing distance, density, or interaction. Taste is not a reason. He maintains tokens and usage: what a color means, which spacing step, which button level is the main action. If the docs only paste mocks and never write bans, the system still forks.
He does not replace the UI designer of a given page. That designer owns whether the screen can be read on the shop floor or in the office. The design-system designer owns that the next document does not invent another way to read. When they conflict, "one meaning, one expression" wins. A page may vary density. The variant must be registered. It cannot be a private copy with the color changed.
How to accept that a system is actually in use
Acceptance does not count how many buttons sit in the library. It watches whether a new requirement still draws a table outside the library. Each iteration the design-system designer samples new pages: does a dangerous action use the danger token, does empty distinguish no data, no privilege, and load failure, do form errors sit beside the field rather than toast once at the top. Fail the sample and it is returned. "Unify it later" after go-live is not allowed.
Naming is the other acceptance line. Design files say "primary button", code says btn-primary, docs say "emphasis button". Three names point at one component, and a newcomer makes a fourth. He requires design files and docs to use the same name, with the code name mapped in the docs, and he corrects it in the review, not as a debt to log.
Where three reds came from, and how they were folded
One project had a back office and stores. Void in the back office was brick red. Promo in the store was pure red. Write-off privately opened a third red. Store staff treated a promo-marked item as void and returned it. The design-system designer locked danger to one token. Promo moved to the brand secondary color and must carry the word "promo". Store-page private reds were deleted. The next write-off document reused the danger token. No new color-value discussion. Whether void on paper needs a word stamp, and which cell it covers, goes to the Visual designer for proofing. This role does not write print operations.
If at the time the three reds had only been put in a brand book with "please prefer the first", a fourth would appear on the next page. The design system's job is to keep a wrong color value out of screen components, not to rely on goodwill.
When a new page is opened, the design-system designer first issues a reuse list: which list, which empty, which primary-button step. If the list cannot be written, the page goal is still unclear, and visual should not be drawn yet. He uses the list to stop "make it special first" before work starts. Special needs may exist. They must sit beside the list naming which old rule they break, and whether old pages change with them. Without that sentence, the system keeps two correct versions for a long time.