वर्शन-कंट्रोल्ड डिज़ाइन टोकन्स अब स्टैंडर्ड प्रैक्टिस बन गए

एक डिज़ाइन टोकन अब सिर्फ एक ऐसा वैल्यू नहीं रहा जिसे आप एक्सपोर्ट करके भूल जाते हैं। यह एक वर्शन्ड प्रोडक्ट चेंज है जो एक ब्रांच, एक पुल रिक्वेस्ट, एक रिव्यू, और एक चेंजलॉग से होकर गुज़रता है, बिल्कुल वैसे ही जैसे इंजीनियर्स कोड शिप करते हैं। यह खामोश बदलाव तब सबकी नज़र में आया जब डिज़ाइनर्स पैलेट एडिट्स के लिए असली पुल रिक्वेस्ट्स पोस्ट करने लगे: एक कलर टोकन बदला गया, PR में रिव्यू हुआ, अप्रूव हुआ, मर्ज हुआ, और एक चेंजलॉग एंट्री के साथ रिलीज़ हुआ।

इसका महत्व सौंदर्यबोध का नहीं बल्कि मैकेनिकल है। जब एक टोकन बदलता है, तो यह उस हर प्लेटफॉर्म और प्रोडक्ट तक पहुंच सकता है जो उसे पढ़ता है, इसलिए एक बिना रिव्यू किया हुआ स्वैच एडिट अब एक प्रोडक्शन चेंज है। यही पूरी कहानी है, और बाकी सब यह है कि यह कैसे काम करता है और क्या आपको वाकई इसकी ज़रूरत है।

"वर्शन-कंट्रोल्ड टोकन्स" का असल में मतलब क्या है

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

यहां उत्प्रेरक (catalyst) Tokens Studio है। Tokens Studio आपको Figma के अंदर ही टोकन्स एडिट करने देता है, फिर उस टोकन सेट को एक GitHub रिपॉज़िटरी के साथ सिंक करता है। जिस पल आपके टोकन्स एक रिपो में आ जाते हैं, हर बदलाव एक कमिट बन जाता है, हर प्रस्तावित बदलाव एक पुल रिक्वेस्ट बन जाता है, और हर रिलीज़ एक टैग की गई वर्शन बन जाती है जिसका इतिहास आप पढ़ सकते हैं।

इसलिए "वर्शन-कंट्रोल्ड टोकन्स" कोई रूपक नहीं है। यह डिज़ाइन निर्णयों को उसी git वर्कफ़्लो के तहत रखने की वास्तविक प्रैक्टिस है जो GitHub इंजीनियर्स को देता है, फिर इसके साथ आने वाली सेफ्टी रेल्स को उधार लेने की: काम को अलग रखने के लिए ब्रांचेज़, गलतियां पकड़ने के लिए रिव्यूज़, और एक चेंजलॉग ताकि किसी को यह अंदाज़ा न लगाना पड़े कि क्या बदला।

यह बदलाव: एक टोकन एडिट अब एक प्रोडक्शन चेंज है

यहां वह हिस्सा है जो सब कुछ नए सिरे से परिभाषित करता है। एक टोकन परिभाषा से ही साझा होता है। आपने color.brand.primary को स्क्रीन्स में बिखरे हुए एक हेक्स वैल्यू के बजाय एक टोकन बनाने की पूरी वजह यही थी कि एक बदलाव हर उस जगह को अपडेट कर दे जो उसका इस्तेमाल करती है।

वही सुपरपावर ही जोखिम भी है। जिस पल आप उस टोकन को एडिट करते हैं, आपने web, iOS, और Android के पार हर बटन, लिंक, बैज, और स्टेट के लिए एक बदलाव प्रस्तावित कर दिया है। यहां "सिर्फ इस एक स्क्रीन" जैसा कुछ नहीं होता। Style Dictionary, वह बिल्ड स्टेप जिसे ज़्यादातर टीमें अपने टोकन्स के साथ इस्तेमाल करती हैं, मर्ज किए गए टोकन सेट को हर प्लेटफॉर्म के लिए कंपाइल करता है, इसलिए एक अकेला एडिट एक मल्टी-प्लेटफॉर्म रिलीज़ बन जाता है।

इसे एक आम सेव की तरह ट्रीट करें और आपने अपने पूरे सरफेस एरिया में एक बिना-टेस्ट किया हुआ प्रोडक्शन चेंज शिप कर दिया है। इसे कोड की तरह ट्रीट करें और इसके कहीं भी जाने से पहले आपको एक रिव्यू मिलता है।

वर्शन-कंट्रोल प्लेबुक, टोकन्स पर लागू

यह वह टेबल है जिसे सेव करना ज़रूरी है। कोड को सुरक्षित रूप से शिप करने के लिए इंजीनियर्स जिस भी प्रैक्टिस का इस्तेमाल करते हैं, अब उसका एक साफ़-सुथरा डिज़ाइन-टोकन समकक्ष मौजूद है।

यह मैपिंग महज़ एक खूबसूरत आइडिया नहीं है। हर रो एक असली फेलियर मोड को सुलझाती है।

Branches अधूरे पैलेट एक्सपेरिमेंट्स को प्रोडक्शन में लीक होने से रोकती हैं। Reviews उस "मैंने ब्रांड कलर को डार्क किया और इसने तीन स्टेट्स पर कॉन्ट्रास्ट तोड़ दिया" वाली समस्या को यूज़र्स तक पहुंचने से पहले पकड़ लेती हैं। Semantic versioning ऐप टीमों को बताती है कि क्या वे शुक्रवार को आपका अपडेट पुल कर सकती हैं या उन्हें इसके लिए प्लान करना होगा।

एक पैलेट की सेमेंटिक डिफिंग कैसी दिखती है

एक सेमेंटिक डिफ़ दिखाता है कि एक टोकन चेंज का असल में क्या मतलब है, सिर्फ यह नहीं कि कौन-से कैरेक्टर बदले। एक रॉ git diff आपको बताता है कि #ff6b3d, #ff6434 बन गया। एक सेमेंटिक डिफ़ आपको बताता है कि ब्रांड प्राइमरी थोड़ा ज़्यादा सैचुरेटेड हो गया, कि यह अब 14 कंपोनेंट्स को प्रभावित करता है, और कि नया वैल्यू डिसेबल्ड स्टेट पर आपके कॉन्ट्रास्ट थ्रेशोल्ड से नीचे चला जाता है।

व्यवहार में, पुल रिक्वेस्ट ही रिव्यू सरफेस बन जाता है। पुराना स्वैच बाईं तरफ बैठता है, नया स्वैच दाईं तरफ, बदली हुई प्रॉपर्टीज़ की लिस्ट होती है, और एक रिव्यूअर अप्रूव करता है या चेंजेज़ रिक्वेस्ट करता है। बस इतनी ही पूरी सेरेमनी है, और यह वही मांसपेशी है जो एक कोड रिव्यूअर के पास पहले से होती है।

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

यह अभी क्यों हो रहा है

तीन चीज़ें एक साथ आईं:

• Tokens Studio ने Figma-से-GitHub राउंड ट्रिप को व्यावहारिक बनाया, इसलिए डिज़ाइनर्स को अब टोकन्स को एक रिपो में डालने के लिए किसी इंजीनियर की ज़रूरत नहीं रही।
• Style Dictionary उस बिल्ड लेयर के रूप में परिपक्व हुआ जो एक टोकन सोर्स को प्लेटफॉर्म-स्पेसिफिक आउटपुट में बदल देता है, और यही चीज़ एक मर्ज को एक असली रिलीज़ बनाती है।
• GitHub हमेशा से एक सब्सट्रेट के रूप में मौजूद था, जिसके branches, pull requests, reviews, releases, और changelogs पहले से ही दुनिया की हर इंजीनियरिंग टीम द्वारा बैटल-टेस्टेड थे।

दूसरा कारक है स्केल। Supernova जैसे प्लेटफॉर्म्स ने कई प्रोडक्ट्स में टोकन्स के मैनेजमेंट और डिस्ट्रिब्यूशन को प्रोडक्टाइज़ किया, और यह वैसा टूल है जिसकी तरफ आप तभी जाते हैं जब आपका पैलेट एक से ज़्यादा ऐप को फीड करता है। एक बार जब एक टोकन सेट web के साथ-साथ दो नेटिव ऐप्स और एक मार्केटिंग साइट को भी सर्व करने लगता है, तो "मैंने Figma फ़ाइल एडिट कर दी" एक सुरक्षित वाक्य नहीं रह जाता।

तो यह बदलाव किसी आविष्कार से कम और एक टकराव से ज़्यादा है। डिज़ाइनर्स को ऐसे टूल्स मिले जो git की भाषा बोलते हैं, डिज़ाइन सिस्टम्स इतने बड़े हो गए कि उन्हें इसकी ज़रूरत पड़ी, और इंजीनियरिंग प्रैक्टिसेज़ पहले से ही सिद्ध थीं। वायरल पुल रिक्वेस्ट्स ने बस इस बदलाव को उन सबके लिए साफ़ कर दिया जिन्होंने अभी तक इसे नोटिस नहीं किया था।

ईमानदार प्रतिवाद (डिज़ाइन-ऑप्स थिएटर असली है)

ज़्यादातर टीमों को अपने पैलेट के लिए पूरी git-flow सेरेमनी की ज़रूरत नहीं होती। अगर आप एक प्रोडक्ट शिप कर रही तीन-लोगों की स्टूडियो हैं, तो हर कलर ट्वीक को एक branch, एक pull request, दो अप्रूवल्स, और एक semantic version बम्प में लपेटना सिर्फ प्रोसेस कॉसप्ले है। आप एक ऐसे ब्लास्ट रेडियस से बचने के लिए इंजीनियरिंग ओवरहेड चुका रहे हैं जो आपके पास है ही नहीं।

डिज़ाइन-ऑप्स थिएटर एक असली फेलियर मोड है। यह तरक्की जैसा दिखता है क्योंकि यह आर्टिफैक्ट्स पैदा करता है: PRs, changelogs, review queues, status labels। लेकिन आर्टिफैक्ट्स नतीजे नहीं होते। अगर आपका टोकन चेंज सिर्फ उस एक प्रोडक्ट को छूता है जिसका मालिक एक ही व्यक्ति है, तो रिव्यू बस आप खुद को रिव्यू कर रहे होते हैं, और चेंजलॉग एक ऐसी डायरी है जो आप एक अकेले पाठक के लिए लिख रहे हैं।

यह ओवरहेड दोनों तरफ से असली है। वर्शन कंट्रोल टोकन्स को असली सेफ्टी देता है, और साथ ही उन टीमों को भी प्रोसेस शिप करने के लिए ललचाता है जो इसकी ज़रूरत के लिए बहुत छोटी हैं, प्रोडक्ट के बजाय। जाल यह है कि आप यह रिचुअल इसलिए अपना लेते हैं क्योंकि यह कठोर दिखता है, और फिर सोचते हैं कि साधारण कलर चेंजेज़ अब दो दिन क्यों लगा रहे हैं।

अपने टोकन्स को वर्शन कंट्रोल के तहत कैसे लाएं

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

अगर आप वह लाइन पार करते हैं, तो सेटअप छोटा है:

1. अपने टोकन सेट को Figma के अंदर Tokens Studio में ले जाएं ताकि वैल्यूज़ स्ट्रक्चर्ड डेटा हों, ढीले-ढाले स्टाइल्स नहीं।
2. उस सेट को एक GitHub रिपॉज़िटरी के साथ सिंक करें। अब हर बदलाव एक कमिट है और हर प्रस्ताव एक पुल रिक्वेस्ट है।
3. Style Dictionary को बिल्ड स्टेप के रूप में जोड़ें ताकि एक मर्ज ऑटोमेटिकली टोकन्स को web, iOS, और Android के लिए कंपाइल कर दे।
4. अपना रिव्यू रूल तय करें। मर्ज होने से पहले किसे एक टोकन चेंज को अप्रूव करना होगा, और क्या चीज़ ब्रेकिंग मानी जाएगी।
5. साथ-साथ चेंजलॉग लिखते जाएं। हर बदलाव के लिए एक लाइन: क्या बदला, क्यों बदला, किन प्लेटफॉर्म्स पर।

अगर आप हाथ से बनाए गए वर्ज़न से आगे निकल जाते हैं, तो Supernova जैसा एक प्लेटफॉर्म प्रोडक्ट्स में टोकन्स को मैनेज और डिस्ट्रिब्यूट करता है ताकि आपको पाइपलाइन की हाथ से देखभाल न करनी पड़े। इसकी तरफ तब जाएं जब डिज़ाइनर्स की संख्या नहीं बल्कि कंज्यूम करने वाले प्रोडक्ट्स की संख्या मैनुअल डिस्ट्रिब्यूशन को दर्दनाक बना दे।

हर टोकन कहां रहना चाहिए, इसके लिए यह नियम इस्तेमाल करें।

अक्सर पूछे जाने वाले सवाल (FAQ)

क्या छोटी टीमों को वर्शन-कंट्रोल्ड टोकन्स की ज़रूरत है?

आमतौर पर नहीं। अगर आपके टोकन्स सिर्फ उस एक प्रोडक्ट को फीड करते हैं जिसका मालिक एक ही व्यक्ति है, तो रिव्यू बस आप खुद अपने बदलाव को अप्रूव करना है और चेंजलॉग एक डायरी है। इसे तब अपनाएं जब एक टोकन एडिट किसी ऐसे व्यक्ति के लिए कुछ तोड़ सकता हो जो कमरे में मौजूद नहीं है।

Tokens Studio और Style Dictionary में क्या अंतर है?

Tokens Studio वह जगह है जहां आप टो��न्स एडिट और सिंक करते हैं, Figma को एक GitHub रिपॉज़िटरी से जोड़ते हुए ताकि बदलाव पुल रिक्वेस्ट्स बन जाएं। Style Dictionary वह बिल्ड स्टेप है जो मर्ज किए गए टोकन्स को हर प्लेटफॉर्म के लिए कंपाइल करता है। एक ऑथरिंग और रिव्यू संभालता है, दूसरा डिस्ट्रिब्यूशन संभालता है।

क्या आप GitHub के बिना टोकन्स को वर्शन कर सकते हैं?

आप कोई भी वर्शन-कंट्रोल होस्ट इस्तेमाल कर सकते हैं, लेकिन GitHub आम सब्सट्रेट है क्योंकि branches, pull requests, reviews, releases, और changelogs पहले से ही परिपक्व हैं। ब्रांड से ज़्यादा प्रैक्टिस मायने रखती है। आपको बस ऐसी जगह चाहिए जहां एक टोकन चेंज एक रिव्यू करने योग्य, रिकॉर्डेड इवेंट बन जाए।

एक डिज़ाइन टोकन के लिए सेमेंटिक डिफ़ क्या है?

यह इस बात का एक नज़ारा है कि एक टोकन चेंज का क्या मतलब है, सिर्फ यह नहीं कि कौन-से कैरेक्टर बदले। एक हेक्स वैल्यू के दूसरे में बदलने को दिखाने के बजाय, यह पुराने स्वैच को नए के बगल में दिखाता है, कौन-से कंपोनेंट्स प्रभावित हुए, और क्या बदलाव कॉन्ट्रास्ट जैसे किसी थ्रेशोल्ड को पार करता है। यह एक कलर डिसीज़न को रिव्यू करने योग्य बनाता है।

क्या यह मेरे डिज़ाइनर के निर्णय की जगह लेता है?

नहीं। यह निर्णय को अदृश्य छोड़ने के बजाय उसे रिकॉर्ड और रिव्यू करता है। यह वर्कफ़्लो यह तय नहीं करता कि नया ब्रांड कलर सही है या नहीं, यह बस यह सुनिश्चित करता है कि हर प्लेटफॉर्म पर शिप होने से पहले किसी इंसान ने इसे अप्रूव किया हो और एक चेंजलॉग वजह बताए।

निष्कर्ष (जो शिप होता है उसे वर्शन करें)

यह बदलाव असली है। Tokens Studio, Style Dictionary, और GitHub ने मिलकर डिज़ाइन टोकन को एक स्टैटिक एक्सपोर्ट से एक ऐसे वर्शन्ड प्रोडक्ट चेंज में बदल दिया जिसमें branches, reviews, semantic diffs, और एक changelog होता है। जब एक एडिट एक साथ हर प्लेटफॉर्म पर रिलीज़ हो सकता है, तो यह वही सेफ्टी रेल्स पाने का हकदार है जो इंजीनियर्स पहले से इस्तेमाल करते हैं।

असली अनुशासन यह जानने में है कि लाइन कहां है। उन टोकन्स को वर्शन करें जो प्लेटफॉर्म्स के पार शिप होते हैं और बदलने पर चीज़ें तोड़ देते हैं। बाकी को Figma में रहने दें और एक-मालिक वाले कलर ट्वीक को दो-अप्रूवल वाले पुल रिक्वेस्ट में लपेटने की इच्छा पर काबू रखें।