टोकन जो बचे रहते हैं
एक डिज़ाइन टोकन सिस्टम बनाएँ जो अगली विज़ुअल रीफ्रेश से भी ज़्यादा टिकता है। थ्री-लेयर स्ट्रक्चर, सिमैंटिक नेमिंग, वास्तविक-दुनिया के पैटर्न।
ज़्यादातर टोकन सिस्टम रीडिज़ाइन से बचते क्यों नहीं हैं
ज़्यादातर डिज़ाइन टोकन सिस्टम दो साल के अंदर रिटायर हो जाते हैं क्योंकि उन्होंने उस दिन की विज़ुअल वैल्यूज़ को एनकोड किया था, न कि उनके पीछे के सिमैंटिक इरादे को। blue-500 नाम का टोकन हमेशा के लिए एक नीली वैल्यू से बँधा रहता है; accent-primary नाम का टोकन किसी भी रंग बदलाव से बचा रहता है क्योंकि अगला डिज़ाइनर इसे नई सिस्टम के किसी भी नीले-समकक्ष में मैप कर सकता है।
वह एक ही नियम जो बचे रहने वाले टोकन सिस्टम को मरने वाले से अलग करता है: टोकन्स को दिखने से नहीं, बल्कि उद्देश्य से नाम दें। accent-primary, surface-base, text-secondary, danger-bg। कभी blue-500, gray-900, red-light नहीं। सिमैंटिक नाम कॉन्ट्रैक्ट है; वैल्यू इमप्लीमेंटेशन डिटेल है।
थ्री-लेयर आर्किटेक्चर
लेयर 1: primitives। कच्चे रंग, स्पेसिंग, टाइपोग्राफ़ी वैल्यूज़। blue-50, blue-100, blue-200..., blue-900। space-1, space-2..., space-12। ये अंतर्निहित स्केल के रूप में मौजूद होते हैं और शायद ही कभी बदलते हैं।
परत 2: सिमेंटिक। उद्देश्य-नाम वाले टोकन जो primitives से मैप करते हैं। accent-primary नीले-500 से मैप करता है, accent-hover नीले-600 से, surface-base gray-50 से, text-primary gray-900 से। कंपोनेंट्स इन्हें संदर्भित करते हैं, कभी primitives को सीधे नहीं।
परत 3: component-scoped। प्रति-कंपोनेंट टोकन जो सिमेंटिक टोकन्स से मैप करते हैं। button-primary-bg accent-primary से मैप करता है, card-border border-subtle से, nav-active-bg accent-emphasis से। कंपोनेंट्स इन्हें consume करते हैं।
जब ब्रैंड रिफ्रेश होता है, तो आप primitive स्केल को बदलते हैं और संभवतः sematic-to-primitive मैपिंग को। Component-scoped टोकन्स अपरिवर्तित प्रवाहित होते हैं। redesign दिनों में नहीं महीनों में शिप होता है।
क्या एनकोड करें और क्या hard-code करें।
एनकोड करें: रंग, spacing, टाइपोग्राफी (फ़ॉन्ट परिवार, साइज़, वजन, line heights), border-radius, shadow, motion duration और easing, breakpoint widths।
एनकोड न करें: layout-specific values (लेख template पर 1280 का max-width), one-off positioning offsets, animation choreography जो एक ही कंपोनेंट के लिए unique है। ये inline होते हैं; इन्हें एनकोड करने से एक ऐसा सिस्टम बनता है जो खुद से लड़ता है।
लिटमस टेस्ट: क्या कोई अन्य कंपोनेंट plausibly इस same value को use कर सकता है? अगर हाँ, तो एनकोड करें। अगर नहीं, तो hard-code करें।
stack भर में implementation।
token boundary पर CSS custom properties। :root में primitives और semantics को define करें, [data-theme="dark"] में override करें। कंपोनेंट्स sematic tokens को संदर्भित करते हैं, कभी primitives को नहीं।
एक generated TypeScript file के माध्यम से JS-accessible tokens उसी स्रोत से। Style Dictionary, Theo, या एक छोटे custom generator जैसे tools एक ही JSON या YAML स्रोत से CSS variables और TS exports दोनों produce करते हैं। single source का अर्थ है कि JS animations और styled components stylesheets के साथ sync में रहते हैं।
सिस्टम को एक single page में document करें (एक Storybook page या site के /design page पर) ताकि future contributors को यह मिल जाए। Token systems जो discoverable नहीं होते, वे महीनों में उन लोगों द्वारा bypass हो जाते हैं जिन्हें पता नहीं होता कि वे exist करते हैं।