06 दिस॰ 2025·8 मिनट पढ़ने में

नो-कोड UI बिल्डरों में डिज़ाइन टोकन: सुसंगत थीम के लिए

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

क्यों टीमों का UI असंगत हो जाता है

UI की असंगतता आम तौर पर “डिज़ाइन की समस्या” नहीं होती — यह समय की समस्या होती है। किसी को तुरंत बटन चाहिए होता है, तो वे किसी दूसरे पन्ने से कॉपी करके थोड़ा एडजस्ट कर लेते हैं।

यही छोटे-छोटे बदलाव धीरे-धीरे अंतर पैदा करते हैं: दो लगभग समान नीले, कोर्नर रेडियस 6 से 8 हो जाना, हेडिंग जो “थोड़ी बोल्ड” लगे, और पैडिंग जो उस स्क्रीन बनाने वाले पर निर्भर करे। नो-कोड बिल्डरों में छोटे एक-ऑफ एडिट करना और भी आसान है क्योंकि कंट्रोल्स उसी जगह होते हैं और बदलाव मामूली लगते हैं।

जैसे-जैसे प्रोडक्ट बड़ा होता है, यह ड्रिफ्ट तेज़ हो जाता है। ज्यादा पेजेस का मतलब ज्यादा पैटर्न्स दोहराना। ज्यादा बिल्डर्स का मतलब अधिक व्यक्तिगत पसंद। ज्यादा टीम मेंबर का मतलब अलग-गर सुझाव। अगर कोई व्यक्ति कस्टमर पोर्टल बनाता है और दूसरा एडमिन पैनल, तो आपको एक ही ब्रांड की दो अलग व्याख्याएँ मिलती हैं।

‘‘आंख से देख कर’’ निर्णय रोज़मर्रा के काम में दिखते हैं: रंग को तब तक चुनना जब तक वह "ठीक लगे", कुछ पिक्सल से स्पेसिंग नudge करना क्योंकि स्क्रीन "थाईट" लग रही है, नया बटन स्टाइल बनाना बजाय मौजूदा का उपयोग करने के, फ़ॉन्ट साइज़ मिक्स करना क्योंकि डिफ़ॉल्ट "थोड़ा छोटा" लगता है, या एक स्क्रीन ठीक कर लेना बिना बाकियों को चेक किए।

लागत बाद में दिखती है। रिव्यू धीमे होते हैं क्योंकि फ़ीडबैक विषयगत बन जाता है ("इसे दूसरे पन्ने जैसा बनाओ"). रीवर्क जमा हो जाता है क्योंकि बदलाव हर जगह लागू करना मुश्किल होता है। वेब और मोबाइल अलग हो जाते हैं क्योंकि अलग लोग समान पर असमान चुनाव करते हैं।

डिज़ाइन टोकन इस समस्या का समाधान हैं: वे “काफी अच्छा” निर्णयों की जगह साझा मान स्थापित कर देते हैं। टीम और ऐप बड़े होने के बावजूद UI सुसंगत रहता है।

डिज़ाइन टोकन, साधारण भाषा में

डिज़ाइन टोकन आपके UI के बारे में नाम दिए गए निर्णय होते हैं। "इस नीले का इस्तेमाल करो" या "बटन roomy बनाओ" कहने के बजाय आप उन विकल्पों को ऐसे नाम देते हैं जिसे कोई भी दोहरा सके।

एक टोकन कच्चा मान नहीं होता। कच्चा मान हो सकता है 16px, #2563EB, या 600 (फॉन्ट वेट)। टोकन वह लेबल है जो उस मान का अर्थ बताता है, जैसे space-4, color-primary, या font-weight-semibold।

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

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

टोकन डिज़ाइन और बिल्ड को भी जोड़ते हैं। डिज़ाइनर स्पेसिफिकेशन्स में टोकन नाम इस्तेमाल करते हैं और बिल्डर नो-कोड UI बिल्डर में उसी नाम का उपयोग करते हैं, जिससे हैंडऑफ के बाद भी डिज़ाइन बचा रहता है।

ज़्यादातर टोकन सेट कुछ श्रेणियों में आते हैं: रंग रोल (primary, background, text, danger), टाइपोग्राफी (फॉन्ट फैमिली, साइज़, वेट, लाइन हाइट), स्पेसिंग स्टेप्स (padding, margins, gaps), शेप और डेप्थ (radius, border widths, shadows), और कभी-कभी मोशन (durations और easing)।

वह टोकन सेट जिसकी ज़रूरत अधिकांश उत्पादों को होती है

ज़्यादातर टीमों को एक बड़ा टोकन लाइब्रेरी नहीं चाहिए। उन्हें एक छोटा, साफ़ सेट चाहिए जो अधिकतर स्क्रीन को कवर करे ताकि लोग मान अनुमान न लगाएं। यह नो-कोड टूल्स में और भी ज़रूरी है, जहाँ "बस इस बार" के ट्वीक तेज़ी से फैलते हैं।

एक व्यावहारिक स्टार्ट-अप सेट पाँच समूह कवर करता है:

Color: कुछ ब्रांड रोल (primary, secondary), एक न्यूट्रल सेट (text, background, border), और स्टेटस रोल (success, warning, error)। यदि आप अक्सर hover और disabled दिखाते हैं तो उन्हें भी जोड़ें।
Typography: एक फॉन्ट फैमिली (ज़्यादातर मामलों में दो से अधिक नहीं), एक छोटा साइज़ स्केल (जैसे 12/14/16/20/24/32), वे वेट्स जो आप वास्तव में उपयोग करते हैं, और मिलते-जुलते लाइन हाइट।
Spacing: एक सरल लैडर (जैसे 4/8/12/16/24/32) padding और gaps के लिए।
Shape and effects: कुछ रेडियस (none/sm/md/lg), बॉर्डर चौड़ाइयाँ, और एक छोटा शैडो सेट (0-3)।
Motion (वैकल्पिक): केवल अगर आपका ऐप एनिमेशन इस्तेमाल करता है, तो 2-3 ड्यूरेशन और 1-2 easing नाम।

एक नियम लाइब्रेरी को समझदारी से बनाए रखता है: अगर कोई मान तीन या उससे अधिक जगहों पर दिखता है, तो उसे टोकन बनाएं। अगर वह एक बार दिखता है, तो पहले उस पर शक करें कि वह स्थायी पैटर्न न बन जाए।

नामकरण नियम जो टोकन गड़बड़ी रोकते हैं

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

पहले सिमेंटिक नाम (रंग नहीं) इस्तेमाल करें

ऐसे नाम पसंद करें जो उस मान का UI में क्या काम है बताएं, न कि कि वह कैसा दिखता है। text-primary सभी को बताता है कि इसका कब उपयोग करें। blue-600 सिर्फ पेंट की बाल्टी है।

एक उपयोगी पैटर्न दो परतों का है:

Base tokens: कच्चे बिल्डिंग ब्लॉक्स जैसे color-blue-600, space-16, font-14
Semantic tokens: UI रोल जैसे text-primary, bg-surface, border-muted

नो-कोड UI बिल्डर में सिमेंटिक टोकन ही गैर‑डिज़ाइनरों को बिना आंख से चुनने के सही विकल्प चुनने में मदद करते हैं।

नए टोकन जोड़ने के नियम

ज़्यादातर टोकन लाइब्रेरी गड़बड़ इसलिए हो जाती है क्योंकि “नया” डिफ़ॉल्ट बन जाता है। “रेयूस” को डिफ़ॉल्ट बनाएं।

नियम सरल रखें:

टोकन तभी जोड़ें जब वह 2+ जगहों पर उपयोग हो या वह किसी वास्तविक स्टेट (hover, disabled, error) को सपोर्ट करे।
यदि यह एक-ऑफ है, तो उसे कंपोनेंट के लोकल रखें।
अगर दो टोकन बहुत छोटे अंतर से अलग हैं, तो एक चुनें और दूसरे को हटाएँ।
यदि आप टोकन का उद्देश्य एक वाक्य में नहीं बता सकते, तो उसे न जोड़ें।

फिर नामकरण मानकीकृत करें। एक केसिंग स्टाइल चुनें (kebab-case अच्छा काम करता है), स्थिर प्रिफ़िक्स इस्तेमाल करें (text-, bg-, border-, icon-, space-), और नंबर्स का स्केल संगत रखें (space-4, space-8, space-12, space-16)।

चरण-दर-चरण: उन मानों से टोकन परिभाषित करें जो आप पहले से उपयोग कर रहे हैं

Unify portal and admin UI

Build a portal and admin panel with shared components, not one-off tweaks.

Start a Project

अपने मौजूदा UI को साक्ष्य की तरह मानें। कुछ नया बनाने से पहले एक त्वरित सूची बनाएं: स्क्रीनशॉट इकट्ठा करें, स्टाइल्स निरीक्षण करें, और हर रंग मान, फ़ॉन्ट साइज़, और स्पेसिंग मान लिख लें जो आप प्रोडक्शन में देखते हैं (एक-ऑफ मानों सहित)।

फिर जानबूझकर डुप्लीकेट्स घटाएँ। आमतौर पर आप पाएँगे कि वही ग्रे पाँच थोड़े अलग hex मानों में उपयोग हो रहा है, या स्पेसिंग 14, 15, और 16 के बीच कूद रही है। एक मान चुनें और पुराने मानों को उस पर मैप करें। यहीं पर टोकन व्यावहारिक बनते हैं: आप स्वाद पर बहस बंद करके एक छोटे सेट पर सहमत हो जाते हैं।

एक ठोस पहली वर्ज़न एक पास में बन सकता है:

पैलेट टोकन: कच्चे रंग (ब्रांड, न्यूट्रल, फीडबैक)
सिमेंटिक टोकन: अर्थ-आधारित रंग (text, background, border, success, warning)
टाइपोग्राफी स्केल: 6-8 साइज़ जिनके स्पष्ट रोल हों (body, label, H1-H3)
स्पेसिंग स्केल: 6-10 स्टेप्स जिन्हें आप हर जगह उपयोग कर सकें
कंपोनेंट बेसिक्स: कुछ स्टैंडर्ड रेडियस और शैडोज

प्रत्येक टोकन के लिए एक वाक्य मार्गदर्शन जोड़ें: कहां उपयोग करें और कहां नहीं। उदाहरण: “text-muted सहायक टेक्स्ट के लिए है, न कि प्राथमिक बटनों के लिए।”。

अंत में, स्वामित्व तय करें। किसी एक व्यक्ति (या छोटी टीम) को बदलाव मंज़ूर करने के लिए नामित करना मददगार होता है, साथ ही एक साधारण नियम: “नया टोकन तब ही जोड़ें जब मौजूदा उससे मेल न खा सके।” यह सिस्टम को स्थिर रखता है जबकि प्रोडक्ट बढ़ता है।

नो-कोड UI बिल्डर के अंदर टोकन कैसे लागू करें

हर स्क्रीन के लिए पहले डिफ़ॉल्ट बनाएं जो विरासत में मिले: एक बेस टेक्स्ट स्टाइल (फॉन्ट, साइज़, लाइन हाइट, रंग), हेडिंग स्टाइल (H1-H3), और एक छोटा सेट लेआउट स्पेसिंग नियम ताकि पेज रैंडम न दिखें।

फिर अपने टूल की जो भी सेटिंग थीम कहे उसे टोकनों से मैप करें: theme variables, global styles, style presets, या design system settings—लक्ष्य यह रहे कि “Primary” या “Space/16” चुनने पर टोकन चुना जाए, न कि एक-ऑफ मान।

रीयूज़ेबल स्टाइल्स को उन पैटर्न पर केंद्रित रखें जो आप रोज़ इस्तेमाल करते हैं। एक शुरुआती सेट में कार्ड स्टाइल (background, border, radius, padding, shadow), फॉर्म फील्ड स्टाइल (label, input, help text), बटन स्टाइल्स, और टेबल रो डेन्सिटी व hover स्टेट शामिल हो सकते हैं।

स्टेट्स वह जगह हैं जहाँ असंगतता आती है, इसलिए उन्हें पहले परिभाषित करें। हर इंटरैक्टिव कंपोनेंट का hover, focus, disabled, और error टोकन-चालित होना चाहिए। focus को हर जगह एक समान ring color और मोटाई उपयोग करनी चाहिए। error के लिए वही border और text color पेयरिंग हर जगह उपयोग करें।

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

ऐसे कंपोनेंट वेरिएंट जो सुसंगत रहें

Keep web and mobile aligned

Align web and mobile screens with shared semantic tokens and platform-specific sizing.

Try It

वेरिएंट्स वही जगह हैं जहाँ UI सिस्टम शांत और प्रत्याश्यशील बनता है या एक-ऑफ ट्वीक का ढेर बन जाता है। वेरिएंट्स तब बेहतर काम करते हैं जब वे टोकन के लिए एक पतली परत हों—रंग, टाइप, और स्पेसिंग के लिए मैप करें।

शुरू करें उन मुख्य घटकों से जिन्हें आप हर जगह उपयोग करते हैं: बटन, इनपुट, बैज, अलर्ट, और कार्ड। हर एक को दो आयाम दें: size और intent। Size यांत्रिक होना चाहिए (टाइपोग्राफी और स्पेसिंग)। Intent मतलब-आधारित होना चाहिए (सिमेंटिक रंग)।

बिना अनुमान के साइज और इंटेंट

साइज वेरिएंट तब सुसंगत रहते हैं जब वे केवल कुछ टोकन-आधारित गुण बदलते हैं: फॉन्ट साइज, पैडिंग, और बॉर्डर रेडियस। इंटेंट वेरिएंट मुख्यतः रंग रोल बदलें (background, text, border) और चुपके से स्पेसिंग न बदलें।

एक सेट जो अधिकांश उत्पाद कवर करता है:

Sizes: sm, md, lg
Intents: primary, secondary, danger
States: default, hover, focus, disabled

टीमों के लिए इंटरैक्शन नियम

ऐसे स्टेट नियम परिभाषित करें जो हर कंपोनेंट पर लागू हों, सिर्फ बटनों पर नहीं। उदाहरण के लिए: focus हमेशा एक दृश्यमान रिंग दिखाए, hover सुसंगत तरीके से कंट्रास्ट बढ़ाए, और disabled वही ओपेसिटी व क्लिक ब्लॉक करे।

नया वेरिएंट तब जोड़ें जब वह किसी बार-बार आने वाले अर्थ का प्रतिनिधित्व करे (जैसे “danger”)। अगर यह एक समय का लेआउट ज़रूरत है तो वह आम तौर पर नया कंपोनेंट या रैपर होना चाहिए, न कि ऐसा वेरिएंट जिसे सब गलत तरीके से उपयोग कर लें।

वेब और मोबाइल थीम को कैसे संरेखित रखें

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

शेयर किए गए टोकन से शुरू करें जो आसानी से यात्रा कर सकें: रंग रोल (background, surface, text, primary, danger), टाइपोग्राफी स्केल (साइज़ और वेट), और स्पेसिंग टोकन (4, 8, 12, 16, 24)। ये अनुमान हटाते हैं और अपडेट को पूर्वानुमान्य बनाते हैं।

फिर वास्तविक अंतर स्वीकार करें। मोबाइल को बड़े टच लक्ष्य चाहिए और अक्सर थोड़ा अधिक स्पेसिंग। वेब को घनी टेबल्स, साइडबार, और मल्टी-कॉलम लेआउट चाहिए। फॉन्ट भी अलग हो सकते हैं: आप ब्रांड फॉन्ट वेब पर उपयोग कर सकते हैं पर iOS/Android पर प्लेटफ़ॉर्म डिफ़ॉल्ट पढ़ने की आसानी और परफ़ॉर्मेंस के लिए बेहतर हो सकता है।

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

Global: color.text, color.primary, space.md, radius.sm, type.body
Web-only: type.family.web, control.height.web, space.tableRow
Mobile-only: type.family.mobile, control.height.mobile, space.touch

कंपोनेंट नाम समान रखें (Button/Primary) भले ही साइज अलग हों। रिलीज़ से पहले दोनों थीम के लिए कंट्रास्ट चेक अनिवार्य रखें।

गवर्नेंस: टोकन समय के साथ स्वस्थ कैसे रहें

Go from tokens to code

Build visually and get production-ready source code you can deploy or self-host.

Generate Code

टोकन तभी काम करते हैं जब वे स्थिर और समझने योग्य बने रहें। हल्की गवर्नेंस के बिना टीमें धीरे-धीरे “एक और नीला” जोड़ देती हैं और आप फिर से eyeballing पर लौट आते हैं।

एक हल्का टोकन चेंज फ्लो

प्रक्रिया छोटी रखें, पर वास्तविक:

Request: कोई भी नया टोकन या बदलाव माँग सकता है, स्क्रीनशॉट और कारण के साथ।
Review: एक डिज़ाइनर और एक बिल्डर प्रमुख स्क्रीन पर प्रभाव जाँचें।
Approve: नामकरण, पहुँचयोग्यता (contrast, tap size), और वास्तविकता की पुष्टि करें।
Release: अपडेट शेड्यूल पर प्रकाशित करें (साप्ताहिक या प्रति स्प्रिंट), न कि असंगठित रूप से।
Communicate: क्या बदला और अब क्या उपयोग करें यह साझा करें।

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

सफ़ाई भी काम का हिस्सा है। महीने में एक बार अनयूज़्ड टोकन और कंपोनेंट वेरिएंट हटाएँ या कम से कम उन्हें फ़्लैग करें।

टोकन सभी के लिए उपयोगी बनाएं

गैर‑डिज़ाइनरों को सिद्धांत नहीं, उदाहरण चाहिए।

Do: गैप्स के लिए स्पेसिंग लैडर का उपयोग करें, और मुख्य क्रिया के लिए Primary Button वेरिएंट का उपयोग करें।

Don’t: padding को “13px क्योंकि ऐसा ठीक लगता है” सेट करें, या किसी स्क्रीन से मैच करने के लिए नया बटन स्टाइल बनाएं।

टोकन कार्य को प्रोडक्ट प्राथमिकताओं से जोड़ें: नए फीचर, रीब्रांड, और पहुँचयोग्यता सुधार टोकन अपडेट चलाएँ, न कि व्यक्तिगत पसंद।

आम गलतियाँ और जाल

Turn tokens into a theme

Set global colors, type, and spacing once, then reuse them across your app.

Build Now

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

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

एक और समस्या कच्चे मानों का कंपोनेंट्स में छिप जाना है। कोई बटन की पैडिंग को 14px सेट कर देता है “बस इस बार”, या कार्ड में सीधे हेक्स रंग लगा देता है। हफ्तों बाद कोई नहीं जानता कि क्यों वो अलग है। नियम बनाएं: अगर यह दिखाई देता है और दोहराया जा सकता है, तो वह टोकन होना चाहिए।

ध्यान रखें टोकन प्रकार न मिलाएँ। बेस टोकन (gray-900 या space-4) कच्चे मान बताते हैं। सिमेंटिक टोकन (text-primary या surface-muted) अर्थ बताते हैं। समस्याएँ तब होती हैं जब एक कंपोनेंट बेस टोकन उपयोग करे और दूसरा उसी रोल के लिए सिमेंटिक टोकन—यह असंगतियों का कारण बनता है।

स्टेट्स भी बाद में दर्द दे सकती हैं। टीम अक्सर सामान्य स्टाइल परिभाषित करती है, फिर focus, hover, disabled, और error रिलीज़ से ठीक पहले पैच करती है। इस तरह आप असंगत फोकस रिंग और तीन अलग "error" रेड्स पाते हैं।

स्केल करने से पहले एक त्वरित जाँच करें:

नए टोकन को साझा ज़रूरतों तक सीमित रखें, एक-ऑफ स्क्रीन तक नहीं
कंपोनेंट्स में कच्चे मानों से बचें
बेस बनाम सिमेंटिक टोकन को अलग रखें और सुसंगत लागू करें
स्टेट्स (focus, error, disabled) को जल्दी परिभाषित करें
डार्क मोड या भविष्य के ब्रांड रीफ्रेश के लिए जगह छोड़ें—सिमेंटिक टोकन बदलकर, न कि कंपोनेंट्स फिर से लिखकर

स्केल करने से पहले त्वरित चेकलिस्ट

किसी भी टीम ने अपने UI को और स्क्रीन, टीम या प्रोडक्ट्स पर रोल आउट करने से पहले देखें कि आपकी नींव इतनी स्पष्ट है कि कॉपी करते समय अनुमान न लगे।

रंग रोल सिमेंटिक हैं। टोकन टेक्स्ट (default, muted, inverse), सतह (page, card), बॉर्डर (default, focus), और स्टेटस (success, warning, danger) कवर करते हैं।
टाइप एक छोटे स्केल से मैप होती है। H1-H3, body, small जैसे टेक्स्ट स्टाइल्स जिनका साइज, वेट, और लाइन हाइट परिभाषित हो।
स्पेसिंग ऐसे स्टेप्स से आती है जिन्हें लोग याद रखें। सामान्य पैडिंग और गैप्स एक तंग लैडर (4, 8, 12, 16, 24) से आएं। अगर “14” बार-बार दिखता है, तो आपका लैडर सुधारने की ज़रूरत है।
शीर्ष घटकों के वेरिएंट मौजूद हैं। आपके सबसे उपयोगी कंपोनेंट्स में size (sm/md/lg) और intent (primary/secondary/danger) हैं जो टोकन रोल से मेल खाते हैं।
स्वामित्व स्पष्ट है। एक व्यक्ति (या छोटी टीम) बदलाव मंज़ूर करे, और एक हल्की प्रक्रिया हो: क्यों, प्रभाव, और कब शिप करना है।

उदाहरण: पोर्टल और एडमिन पैनल में UI ड्रिफ्ट रोकना

Design system plus full app

Pair a clean UI system with real business logic, APIs, and database models in one place.

Build an App

एक छोटी टीम दो ऐप एक साथ बना रही है: एक कस्टमर पोर्टल और एक अंदरूनी एडमिन पैनल। अलग लोग अलग स्क्रीन बनाते हैं और नो-कोड बिल्डर में तेज़ी से काम करते हैं। कुछ हफ्तों बाद UI “ऑफ” लगने लगता है, भले ही कोई एक स्पष्ट समस्या न बता पाए।

टोकन से पहले रिव्यू टिप्पणियाँ बढ़ती हैं: बटन लगभग समान पर एक जैसे नहीं, स्पेसिंग स्क्रीन से स्क्रीन बदलती है, फॉर्म फील्ड मैच नहीं करते, और पोर्टल गलती से "फ्रेंडली" जबकि एडमिन पैनल "सख्त" लगता है।

वे इसे हल्के, व्यावहारिक टोकन सेट लागू करके ठीक करते हैं। उन्होंने सिमेंटिक रंग परिभाषित किए (Primary, Success, Danger, TextMuted), एक स्पेसिंग स्केल (4, 8, 12, 16, 24), और बटन वेरिएंट्स (Primary, Secondary, Ghost) एक सामान्य रेडियस और सुसंगत स्टेट्स के साथ।

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

बिल्ड तेज़ होता है क्योंकि विकल्प पहले से तय हैं। रिव्यू छोटे दृश्य दोषों की बजाय वास्तविक UX मुद्दों पर केंद्रित होते हैं। “यह बटन प्राइमरी वेरिएंट बनाइए” बदल जाता है “इसे थोड़ा और नीला और थोड़ा ऊँचा कर सकते हो?” के।

फिर एक छोटा रीब्रांड आता है: प्राइमरी रंग बदलता है और फ़ॉन्ट स्केल संकुचित होता है। टोकनों के साथ टीम कुछ मान एक बार बदलती है और पोर्टल और एडमिन पैनल दोनों एक साथ अपडेट हो जाते हैं।

अगले कदम: छोटा शुरू करें, फिर मानकीकृत करें

एक ऐसा फ्लो चुनें जिसे लोग अक्सर उपयोग करते हैं और जिसमें स्पष्ट ड्रिफ्ट दिखता है—जैसे ऑनबोर्डिंग, सेटिंग्स पेज, या एक साधारण फॉर्म। एक ही फ्लो को कन्वर्ट करना विचार सिद्ध करने और eyeballing रोकने का सबसे तेज़ तरीका है।

छोटे, सुरक्षित टोकन सेट से शुरू करें: primary/background/text/border/danger, एक छोटा टाइप स्केल, एक स्पेसिंग लैडर, और 2-3 रेडियस व शैडो लेवल। फिर एक छोटा कंपोनेंट सेट बनाएं जो केवल टोकन उपयोग करे: एक बटन, एक इनपुट, एक कार्ड, एक अलर्ट। वेरिएंट तभी जोड़ें जब वे वास्तविक ज़रूरत हल करें।

टीम के साथ एक छोटा रिव्यू रन करें दो स्क्रीनशॉट का उपयोग करके: एक “पहले” स्क्रीन जिसमें असंगत पैडिंग और फ़ॉन्ट हैं, और एक “बाद” स्क्रीन टोकन व वेरिएंट्स से बनाई गई। कुछ नियमों पर सहमति बनाएं (जैसे “हार्ड‑कोडेड रंग नहीं” और “स्पेसिंग टोकन होना चाहिए”) और शीर्ष असंगतियों को पहले ठीक करें।

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

यदि आप AppMaster में पूरा प्रोडक्ट (बैकएंड, वेब, और मोबाइल) बना रहे हैं, तो टोकन और रीयूज़ेबल UI स्टाइल्स जल्दी सेट करना मददगार होता है ताकि नए स्क्रीन एक ही निर्णय विरासत में लें। इस तरह दृश्य सुसंगतता और ऐप लॉजिक साथ-साथ आगे बढ़ते हैं बिना बाद में बार-बार सफ़ाई के।

सामान्य प्रश्न

UI drift आमतौर पर छोटे “बस इस बार” बदलावों से शुरू होता है: किसी घटक की नकल करना, पैडिंग को एडजस्ट करना, या आंख से रंग चुनना। समय के साथ ये छोटे अंतर कई पन्नों और टीम के सदस्यों में जुड़कर बड़े समस्या बन जाते हैं, और रिव्यू एक सामान्य नियम के बजाय व्यक्तिगत राय बन जाते हैं।

डिज़ाइन टोकन ऐसे नाम दिए गए UI निर्णय हैं जिन्हें लोग कच्चे मानों की जगह दोहराते हैं। मान होते हैं जैसे 16px या #2563EB, पर टोकन का नाम उद्देश्य बताता है—जैसे space-16 या color-primary—ताकि हर कोई हर बार वही विकल्प चुने।

पहले रंग रोल, टाइपोग्राफी, स्पेसिंग, और कुछ रैडियस व शैडो मान पर ध्यान दें। ये सबसे ज़्यादा स्क्रीन कवर करते हैं और “आंख से चुनना” रोकते हैं, साथ ही टोकन सेट इतना छोटा रहेगा कि लोग इसका प्रयोग करेंगे।

व्यवहारिक नियम: कोई मान तभी टोकन बनाएं जब वह दो या उससे अधिक जगहों पर दिखे, या वह किसी वास्तविक स्टेट (hover, focus, disabled, error) का समर्थन करे। अगर वह सच में एक-बार उपयोग है तो उसे लोकल रखें ताकि वह गलती से ग्लोबल मानक न बन जाए।

समानार्थक नाम (semantic) बताने चाहिए कि टोकन किस काम के लिए है—जैसे text-primary या bg-surface—ताकि बिना पैलेट याद किए सही विकल्प चुन सकें। कच्चे नाम जैसे blue-600 बेस टोकन के रूप में ठीक हैं, पर उनके इस्तेमाल से रंगों के गलत प्रयोग की संभावना बढ़ती है।

अपने प्रोडक्शन UI का ऑडिट करें: जो रंग, फॉन्ट साइज़ और स्पेसिंग आप वास्तव में इस्तेमाल कर रहे हैं उन्हें इकट्ठा करें, और फिर निकटवर्ती डुप्लीकेट्स को मिलाकर एक छोटा, साफ़ सेट बनाएं। पुराने मानों को नज़दीकी टोकन पर मैप करें ताकि भविष्य में लोग टोकन ही उपयोग करें।

सबसे पहले ग्लोबल डिफ़ॉल्ट सेट करें, फिर अपने बिल्डर में थीम वेरिएबल्स या ग्लोबल स्टाइल्स को टोकनों से मैप करें ताकि घटक नामों को रेफर करें न कि हेक्स/पिक्सल को। इसके बाद रोज़ के उपयोग के लिए छोटे रीयूज़ेबल स्टाइल्स बनाएं और उनके hover, focus, disabled, error स्टेट भी टोकन से चलें।

वेरिएंट्स को सरल रखें: साइज और इंटेंट तक सीमित रखें। साइज केवल कुछ टोकन-आधारित गुण बदले (फॉन्ट साइज़, पैडिंग), इंटेंट मुख्यतः सिमेंटिक रंग रोल बदलें—ताकि “danger” बटन अनजाने में स्पेसिंग या टाइपोग्राफी न बदल दे।

ग्लोबल सिमेंटिक टोकन साझा रखें ताकि अर्थ समान रहे, और प्लेटफ़ॉर्म-विशिष्ट टोकन छोटे अंतर संभालें जैसे टच टार्गेट साइज और घनत्व। लक्ष्य है “एक परिवार जैसा अनुभव, पिक्सल-दर-पिक्सल समान नहीं।”

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