Figma Variables आर्किटेक्चर: ऐसा टोकन सिस्टम कैसे बनाएं जो प्रोडक्शन में टिके

Figma variables इस्तेमाल करने वाली ज़्यादातर टीमें styles वाले मेंटल मॉडल पर ही निर्माण कर रही हैं, और यही असली समस्या है। आर्किटेक्चर के बिना variables बस अतिरिक्त क्लिक वाले styles हैं।

जो टीमें इसे सही कर रही हैं, वे Figma variables को एक असली डिज़ाइन टोकन लेयर मानती हैं: संरचित, aliased, scoped और exportable। जो टीमें गलत कर रही हैं, वे डार्क मोड की एक रिक्वेस्ट दूर हैं पूरे रीबिल्ड से। यही वह आर्किटेक्चर है जो प्रोडक्शन में टिकता है।

Variables styles नहीं हैं, वे टोकन लेयर हैं

Figma styles प्रीसेट हैं। आप एक रंग, एक टेक्स्ट स्टाइल, एक इफ़ेक्ट तय करते हैं और उसे सीधे लेयर पर लगा देते हैं। यह एक ब्रांड, एक मोड वाली और बिना dev हैंडऑफ़ ज़रूरतों वाली फ़ाइल के लिए चलता है। जैसे ही कुछ बदलता है, यह चलना बंद कर देता है।

Figma variables टोकन हैं। एक variable में वैल्यू हो सकती है, पर वह किसी दूसरे variable का रेफ़रेंस भी रख सकता है। यही रेफ़रेंस चेन, और modes के ज़रिए resolved वैल्यूज़ के पूरे सेट बदल देने की क्षमता, variables को styles से आर्किटेक्चरल रूप से अलग बनाती है। यह फ़र्क दिखावटी नहीं है। यह प्रीसेट सिस्टम और टोकन सिस्टम के बीच का फ़र्क है।

तीन-लेयर टोकन आर्किटेक्चर

Primitives, semantic, component। हर काम करने वाले variable सिस्टम में ये तीन लेयर होती हैं। semantic लेयर को छोड़ देना आज Figma फ़ाइलों में सबसे आम आर्किटेक्चरल गलती है।

ये तीन लेयर तीन काम बांटती हैं: primitives कच्ची वैल्यूज़ रखते हैं, semantic टोकन अर्थ लेकर चलते हैं, और कॉम्पोनेंट टोकन किसी एक कॉम्पोनेंट फ़ैमिली तक सीमित रहते हैं। हर लेयर सिर्फ़ अपने नीचे वाली लेयर से बात करती है। कोई स्किप नहीं, कोई शॉर्टकट नहीं।

ये तीनों लेयर प्रोजेक्ट के आकार पर निर्भर वैकल्पिक चीज़ नहीं हैं। पांच कॉम्पोनेंट वाले छोटे सिस्टम को भी तीनों लेयर चाहिए, वरना पहली थीम रिक्वेस्ट उसे उड़ा देगी।

लेयर एक: primitives

Primitives कच्ची वैल्यूज़ हैं। blue-500, gray-900, space-4, radius-md। ये पैलेट हैं, स्केल हैं, नींव हैं। इन्हें कभी सीधे कॉम्पोनेंट लेयर से नहीं जोड़ा जाता।

Primitive का काम है मौजूद रहना, ऊपर से alias होना, और रास्ते से हटे रहना। अगर कोई डिज़ाइनर बटन पर लगाने के लिए blue-500 उठा रहा है, तो आर्किटेक्चर पहले ही टूट चुका है। Primitives अपनी primitives collection में रहते हैं, और कहीं नहीं।

यहां नामकरण मायने रखता है। Primitives स्केल-आधारित या पैलेट-आधारित होने चाहिए, कभी semantic नहीं। blue-500 सही है। button-blue को primitive बनाना श्रेणी की गलती है जो बड़े स्तर पर दर्द देती है।

लेयर दो: semantic

Semantic टोकन अर्थ रखते हैं। surface, surface-elevated, text-primary, text-muted, border-default, border-focus। वे "यह रंग किसलिए है?" का जवाब देते हैं, "यह कौन सा रंग है?" का नहीं।

Semantic टोकन primitives को alias करते हैं। बस यही उनका एकमात्र रिश्ता है। Semantic-से-semantic aliasing यह उलझन पैदा करती है कि वैल्यू असल में कहां रहती है और mode overrides को अविश्वसनीय बना देती है।

आपके light, dark और brand modes इसी लेयर में रहते हैं। Semantic टोकन एक्टिव mode के हिसाब से अलग primitive पर resolve होता है, और थीमिंग असल में ऐसे ही काम करती है। Primitive blue-500 नहीं बदलता। Semantic टोकन text-link mode के आधार पर बदलता है कि वह किस पर resolve हो।

लेयर तीन: component

कॉम्पोनेंट टोकन किसी एक कॉम्पोनेंट फ़ैमिली तक सीमित होते हैं। button-bg, button-text, button-border, card-surface, card-border, input-bg। ये semantic टोकन को alias करते हैं, कभी primitives को नहीं।

कॉम्पोनेंट टोकन का काम है बिना कपलिंग के विशिष्टता। button-bg resolve होता है surface-action पर, जो resolve होता है blue-500 पर। जब ब्रांड बदलता है, आप semantic लेयर अपडेट करते हैं और बटन अपने आप अपडेट हो जाता है। कॉम्पोनेंट टोकन को छुआ भी नहीं जाता।

आम आपत्ति यह है कि यह बिना वजह के एक्स्ट्रा टोकन जैसा लगता है। वजह यह है कि button-bg और surface-action अलग-अलग दिशा में जा सकते हैं। कभी न कभी कोई प्रोडक्ट फ़ैसला चाहेगा कि बटन थोड़ी अलग surface इस्तेमाल करे। कॉम्पोनेंट टोकन आपको semantic सिस्टम छुए बिना override का बिंदु देते हैं।

Modes बनाम collections: फ़ैसले का पेड़

Modes एक collection के भीतर वैल्यूज़ बदलते हैं। Collections चिंताओं को अलग करते हैं। ये दोनों एक चीज़ नहीं हैं, और इन्हें मिला देना Figma variable सेटअप की ज़्यादातर आर्किटेक्चरल उलझन की जड़ है।

नियम यह है: हर चिंता के लिए एक collection, एक ही चिंता के रूपों के लिए modes। रंग एक चिंता है। स्पेसिंग एक चिंता है। Light और dark अलग चिंताएं नहीं हैं। वे एक ही रंग-चिंता के modes हैं।

कब mode इस्तेमाल करें और कब नई collection:

• एक ही चीज़ की अलग वैल्यू? Mode।
• बिल्कुल अलग चीज़? Collection।
• light और dark के बीच स्विच? रंग collection के अंदर mode।
• compact और comfortable स्पेसिंग के बीच स्विच? स्पेसिंग collection के अंदर mode।
• ब्रांड जोड़ना? Semantic लेयर के अंदर mode, नई collection नहीं।

चार scoping नियम

Variable scoping तय करती है कि Figma में variable कहां लगाया जा सकता है। इसे गलत करने का मतलब है कि डिज़ाइनर गलती से semantic टोकन की जगह primitives उठा सकते हैं, और आर्किटेक्चरल अनुशासन इस्तेमाल के बिंदु पर ढह जाता है।

ये चार नियम अटल हैं:

1. Primitives को none पर scope करें। Primitives कहीं भी लगने योग्य नहीं होने चाहिए। ये आंतरिक वैल्यूज़ हैं, उपभोक्ता-सामने वाले टोकन नहीं। उन्हें apply dropdown से पूरी तरह छिपा दें।
2. Semantic टोकन को उनके type पर scope करें। रंग का semantic टोकन fills और strokes तक scoped हो। स्पेसिंग टोकन gap, padding और size फ़ील्ड तक। scope को कसकर रखें।
3. कॉम्पोनेंट टोकन को उनकी फ़ैमिली पर scope करें। बटन का टोकन कार्ड पर लगने योग्य नहीं होना चाहिए। अगर scope बहुत चौड़ा है, तो कॉम्पोनेंट की सीमा का कोई मतलब नहीं रहता।
4. Primitives को कभी उपभोक्ताओं के सामने न रखें। अगर कोई डिज़ाइनर या डेवलपर लेयर पर primitive लगा रहा है, तो सिस्टम scoping लेयर पर फ़ेल हो चुका है। यह प्रक्रिया की विफलता है, यूज़र की नहीं।

वह alias चेन जो थीम को संभव बनाती है

काम करने वाली थीम aliases की एक चेन है: component, semantic को alias करता है, semantic, primitive को alias करता है, primitive वैल्यू रखता है। चेन की लंबाई तीन है, हमेशा तीन।

दो की चेन (component से primitive) अनुवाद लेयर को छोड़ देती है और हर कॉम्पोनेंट टोकन पर मैनुअल overrides के बिना modes को असंभव बना देती है। चार की चेन यह उलझन पैदा करती है कि कौन सी semantic लेयर mode ले जा रही है, और उसका ऑडिट लुकअप की जगह डिबगिंग की कसरत बन जाता है।

button-bg → surface-action → blue-500 → #0066FF

Copy

यह चेन डार्क मोड में इसलिए बची रहती है कि semantic collection के dark mode में surface-action को blue-300 की ओर पॉइंट कर दिया जाता है। button-bg टोकन अपने आप अपडेट हो जाता है। Primitive blue-500 अब भी #0066FF पर resolve होता है। और कुछ बदलने की ज़रूरत नहीं।

Light, dark और brand modes

ज़्यादातर variable सिस्टम को तीन modes चाहिए: light, dark और brand। इन्हें सिर्फ़ semantic लेयर ले जाती है। primitive लेयर कभी नहीं।

Primitives पर modes लगाना श्रेणी की गलती है। blue-500 हमेशा #0066FF है। वह primitive है। उसका कोई light या dark रूप नहीं होता क्योंकि उसमें कोई अर्थ नहीं है। Semantic टोकन text-link के light और dark रूप होते हैं क्योंकि उसका अर्थ अलग संदर्भों में अलग तरह resolve होता है।

Brand modes भी इसी तरह काम करते हैं। दूसरे ब्रांड को दूसरा primitive पैलेट तभी चाहिए जब ब्रांड सचमुच अलग कच्ची वैल्यूज़ इस्तेमाल करता हो। ज़्यादातर समय, semantic लेयर में ऐसा brand mode जो मौजूदा primitives के अलग सबसेट की ओर पॉइंट करे, सही फ़ैसला होता है। दो ब्रांड के लिए दो पूरी primitive collections आमतौर पर ज़रूरत से ज़्यादा है। ऊपरी स्तर के रंग फ़ैसले इसे कैसे आकार देते हैं, इसके लिए semantic लेयर की संरचना पक्की करने से पहले डार्क मोड कलर सिस्टम वाला लेख पढ़ने लायक है।

Number, string और boolean variables

Figma variables सिर्फ़ रंग नहीं हैं। Number variables स्पेसिंग, साइज़ और radius संभालते हैं। String variables डिज़ाइन फ़ाइलों के अंदर कॉपी संभालते हैं। Boolean variables लेयर की visibility संभालते हैं, जो सीधे कॉम्पोनेंट props से मेल खाती है।

variables सिस्टम का यह वह हिस्सा है जिसे ज़्यादातर टीमें इस्तेमाल नहीं कर रहीं, और यही हिस्सा डिज़ाइन और कोड के बीच की खाई को सबसे नाटकीय ढंग से पाटता है। number variables के रूप में तय की गई स्पेसिंग स्केल, जब auto-layout gaps पर लगाई जाती है, तो variable में एक बदलाव उस टोकन का इस्तेमाल करने वाले हर कॉम्पोनेंट को अपडेट कर देता है। असली टोकन सिस्टम यही करता है।

लोकेल modes वाले string variables से डिज़ाइनर फ़ाइल को अंग्रेज़ी और अरबी के बीच पलट सकते हैं और लेआउट को रीयल टाइम में टूटते देख सकते हैं। कॉम्पोनेंट props से जुड़े Boolean variables का मतलब है कि Figma कॉम्पोनेंट और कोड कॉम्पोनेंट के बीच एक-से-एक prop रिश्ता है, जिससे dev हैंडऑफ़ व्याख्या की जगह समीक्षा योग्य बन जाता है।

कोड तक हैंडऑफ़: वह पैटर्न जो काम करता है

Variable सिस्टम उतना ही अच्छा है जितना उसका export। काम करने वाला हैंडऑफ़ पैटर्न है Tokens Studio या Figma Variables REST API, साथ में एक ट्रांसफ़ॉर्म पाइपलाइन, साथ में कोड-साइड इम्पोर्ट स्क्रिप्ट।

Tokens Studio variable collections को Style Dictionary के साथ संगत संरचित JSON फ़ॉर्मेट में export करता है। Style Dictionary उस JSON को वह हर आउटपुट बना देता है जो कोडबेस को चाहिए: CSS custom properties, Swift color sets, Kotlin resource फ़ाइलें, Tailwind config। ट्रांसफ़ॉर्म स्टेप वह जगह है जहां नामकरण परंपराएं सामान्य की जाती हैं और Figma-विशिष्ट वह नामकरण साफ़ होता है जो कोड परंपराओं से मेल नहीं खाता।

पाइपलाइन हर variable अपडेट पर चलनी चाहिए, मैनुअली नहीं। Tokens Studio push पर ट्रिगर होने वाला GitHub Action या variable बदलावों पर चलने वाला Figma webhook कोड-साइड टोकन को सिंक में रखता है, बिना किसी के export याद रखे। यह वही पैटर्न है जो Stripe और Atlassian बड़े स्तर पर चलाते हैं, और यह हर उस कोडबेस में संभव है जिसमें build स्टेप है। उस आउटपुट में रंग टोकन के फ़ॉर्मेट फ़ैसलों के लिए, CSS custom property वैल्यूज़ पक्की करने से पहले OKLCH color पढ़ने लायक है।

---

ऐसा Figma variable सिस्टम चाहिए जो modes, brands और dev हैंडऑफ़ को बिना रीराइट के झेल ले? Brainy तीन-लेयर मॉडल, alias चेन और ऐसी export पाइपलाइन के साथ Figma में प्रोडक्शन टोकन आर्किटेक्चर डिज़ाइन करता है जो आपके कोडबेस में साफ़ तरीके से बैठ जाती है। Brainy को हायर करें

---

सात आम गलतियां जो variable सिस्टम तोड़ देती हैं

इनमें से ज़्यादातर गलतियों की जड़ एक है: variables पैनल को बेहतर styles पैनल समझना, न कि आर्किटेक्चरल लेयर। मेंटल मॉडल का बदलाव ही इलाज है। बाकी सब उसी से निकलता है।

Variable सिस्टम ऑडिट

किसी भी Figma variable सिस्टम पर यह ऑडिट चलाइए और आप आर्किटेक्चरल कर्ज़ को शिप होने से पहले पकड़ लेंगे।

संरचना

• कम से कम तीन collections: primitives, semantic, component (या समकक्ष नाम)
• हर collection की एक स्पष्ट चिंता हो
• कोई collection types न मिलाए (रंग और स्पेसिंग एक ही collection में होना विफलता है)

Alias चेन

• हर कॉम्पोनेंट टोकन semantic टोकन को alias करे, primitive को नहीं
• हर semantic टोकन primitive को alias करे, किसी दूसरे semantic टोकन को नहीं
• primitives के अलावा कोई टोकन कच्ची वैल्यू न रखे
• सभी रंग टोकन के लिए alias चेन की लंबाई ठीक तीन हो

Modes

• Light और dark semantic collection के modes हों, अलग collections नहीं
• Brand रूप semantic collection के modes हों, अलग फ़ाइलें नहीं
• Primitive collection में कोई modes न हों

Scoping

• Primitive variables none पर scoped हों (कहीं लगने योग्य नहीं)
• Semantic variables अपने type पर scoped हों (रंग fills/strokes पर, स्पेसिंग layout फ़ील्ड पर)
• कॉम्पोनेंट variables अपनी कॉम्पोनेंट फ़ैमिली पर scoped हों

हैंडऑफ़

• Variables Tokens Studio या REST API से exportable हों
• ट्रांसफ़ॉर्म पाइपलाइन मौजूद हो और ऑटोमेटेड हो
• कोड-साइड टोकन Figma variable नामकरण परंपरा से मेल खाएं, दस्तावेज़ी अपवादों के साथ

अगर इनमें से तीन से ज़्यादा फ़ेल हों, तो सिस्टम को पैच नहीं, रीबिल्ड चाहिए। अगर ऑडिट में सबसे ज़्यादा कर्ज़ वहीं निकलता है, तो ब्रांड कलर पैलेट उन ऊपरी रंग फ़ैसलों को कवर करता है जो primitive लेयर में जाते हैं।

FAQ

Figma variables और Figma styles में क्या फ़र्क है?

Styles वे प्रीसेट हैं जो सीधे लेयर पर लगते हैं। Variables वे टोकन हैं जो एक-दूसरे को रेफ़र कर सकते हैं और modes से वैल्यूज़ बदल सकते हैं। Variables वह सब कर सकते हैं जो styles करते हैं, साथ में थीमिंग, साथ में export के ज़रिए dev हैंडऑफ़। नए डिज़ाइन सिस्टम के लिए variables सही चुनाव हैं। परिपक्व style सिस्टम वाली मौजूदा फ़ाइल के लिए, बदलने से पहले माइग्रेशन प्लान लिखना सार्थक है।

एक Figma variable सिस्टम में कितनी collections होनी चाहिए?

ज़्यादातर सिस्टम के लिए तीन से पांच: primitives, semantic, component, और वैकल्पिक रूप से अलग स्पेसिंग और टाइपोग्राफ़ी collections अगर वे स्केल इतनी जटिल हैं कि उन्हें अपने scoping नियम चाहिए। पांच से ज़्यादा collections आमतौर पर इस बात का संकेत है कि चिंताएं सही तरह से समूहबद्ध नहीं हो रहीं।

क्या Figma variables Tokens Studio की जगह ले सकते हैं?

Figma के अंदर बनाने और एडिट करने के लिए, हां। Variables API आने से पहले Tokens Studio जो ज़्यादातर काम करता था, नेटिव variables पैनल वही संभालता है। Export और ट्रांसफ़ॉर्म के लिए Tokens Studio अब भी मूल्य जोड़ता है क्योंकि उसके पास Style Dictionary तक परिपक्व पाइपलाइन है और वह उन किनारे के मामलों को संभालता है जिन्हें नेटिव export नहीं संभालता। फ़िलहाल दोनों टूल पूरक हैं, प्रतिस्पर्धी नहीं।

अगर मैं एक semantic टोकन को दूसरे semantic टोकन से alias कर दूं तो क्या होगा?

Mode resolution अस्पष्ट हो जाता है। अगर text-secondary, text-primary को alias करता है और आप डार्क मोड में स्विच करते हैं, तो Figma चेन resolve करता है और हो सकता है dark mode override वहां लागू न करे जहां आप उम्मीद करते हैं। Semantic-से-semantic aliasing बड़े स्तर पर सिस्टम का ऑडिट लगभग असंभव भी बना देती है। नियम सख़्त है: semantic टोकन सिर्फ़ primitives को alias करते हैं।

सिस्टम दोबारा बनाए बिना तीसरा ब्रांड कैसे संभालूं?

semantic collection में तीसरा mode जोड़ें। Primitive collection ब्रांड्स के बीच साझा रहती है, जब तक ब्रांड सचमुच अलग कच्ची वैल्यूज़ इस्तेमाल न करें। Semantic लेयर में ऐसा brand mode जो primitives के अलग सबसेट की ओर पॉइंट करे, सही आर्किटेक्चर है। अगर ब्रांड इतने अलग हैं कि उनके primitive पैलेट आपस में मिलते ही नहीं, तो साझा semantic संरचना के साथ दो primitive collections आख़िरी विकल्प है।

क्या छोटे प्रोजेक्ट के लिए तीन-लेयर मॉडल ज़रूरी है?

हां, पर हर लेयर का आकार सिकुड़ जाता है। छोटे प्रोजेक्ट में पंद्रह primitives, आठ semantic टोकन और हर कॉम्पोनेंट के दो कॉम्पोनेंट टोकन हो सकते हैं। आर्किटेक्चर फिर भी तीन लेयर का ही है। छोटे प्रोजेक्ट में semantic छोड़ने का लालच ही वजह है कि इतने सारे छोटे प्रोजेक्ट दूसरे डिज़ाइनर या डार्क मोड रिक्वेस्ट आते ही आर्किटेक्चरल कर्ज़ बन जाते हैं। टोकन आर्किटेक्चर व्यापक स्टैक फ़ैसले में कहां बैठता है, इसके लिए Framer vs Webflow vs Next.js वाले लेख में संदर्भ है।

वह बदलाव जो Figma variables असल में खोलते हैं

Figma में असली variable सिस्टम वह चीज़ है जो डिज़ाइन और dev पक्षों को सच के एक ही स्रोत के सबसे करीब लाई है। हैंडऑफ़ दस्तावेज़ नहीं। Zeplin लिंक नहीं। एक जीवंत, exportable, संरचित टोकन लेयर जिसे दोनों पक्ष एक ही परिभाषाओं से पढ़ते हैं।

जो टीमें variables को आर्किटेक्चर मानती हैं, वे डिज़ाइन सिस्टम का कर्ज़ आधा कर रही हैं, इसलिए नहीं कि variables जादू हैं, बल्कि इसलिए कि अच्छे variable सिस्टम के लिए ज़रूरी आर्किटेक्चरल अनुशासन उन फ़ैसलों को भी मजबूर करता है जिन्हें डिज़ाइन सिस्टम टालते आए थे। इस टोकन का मतलब क्या है? यह किसे alias कर सकता है? Primitive का मालिक कौन है? इन सवालों के अब जवाब हैं, और जवाब फ़ाइल में रहते हैं।

आर्किटेक्चर के बिना variables बस अतिरिक्त क्लिक वाले styles हैं। तीन-लेयर मॉडल, alias चेन, scoping नियमों और export पाइपलाइन वाले variables ऐसा डिज़ाइन सिस्टम हैं जो दूसरे ब्रांड, डार्क मोड और ऐसे डेवलपर को झेल सकता है जिसने कभी Figma खोला ही नहीं।

आर्किटेक्चर बनाइए, सिर्फ़ टोकन नहीं।