React ऐप्स में डिजाइन टोकन्स और नियमों से सुसंगत UI

Q: What are design tokens in plain English, and why do they help?

Design tokens are named, reusable values for things like spacing, type sizes, colors, and radius. Instead of “comfortable padding,” you use something like . The name stays stable, and every screen reuses the same decisions so the UI stops drifting.

Q: What’s a good “small but complete” token set to start with?

Start small and cover only what causes visible drift: - Spacing: 4, 8, 12, 16, 24, 32 - Type: 1 body size + 2 heading sizes + fixed line heights - Colors: text, muted, bg, surface, border, primary, danger - Radius: 2 values (for example 8 and 12) - Elevation: none, small, medium If you need a “new” value, round to the nearest token instead of inventing 10px or 18px.

Q: How do I write a prompt that keeps every generated screen consistent?

Put a compact UI spec block at the top of every request and treat it like a contract: - List tokens (spacing/type/colors/radius) - List allowed components (Button, Input, Card, etc.) - Add hard rules (no new spacing values, no one-off CSS) Then describe the screen below it. The key is to keep the spec unchanged across screens.

Q: What’s the best default for form validation timing and error placement?

Pick one pattern and never break it: - Label always above the field (don’t use placeholders as labels) - Helper text below the field (not used for errors) - One error line directly under the field - Show errors after blur or submit , and clear/update on change This avoids the common “one screen validates on blur, another only on submit” inconsistency users notice.

Q: Which UI states should I standardize so screens don’t feel random?

Define a few non-negotiable state rules: - Loading: disable the control, show a spinner, keep width stable - Disabled: lower contrast, but keep focus behavior consistent - Empty state: short message + one clear action - Errors: inline under the field; avoid big layout shifts If you don’t specify states, each screen tends to invent its own patterns.

Q: What should I do when a screen needs a new component that isn’t in my list?

Don’t let it improvise styling. Add it as a documented extension of an existing pattern: - Base the new component on current tokens and a familiar container (often Card) - Define its sizing, spacing, and states using existing tokens - Add it to your approved component list for future screens If you can’t describe it with tokens, it’s usually too custom and will cause drift.

Q: What’s a fast checklist to catch inconsistency before I merge a generated screen?

Use a quick scan before you accept the screen: - Spacing uses only token values (no random numbers) - Typography matches the type scale (including line height) - Buttons follow the same variants and sizes - Forms follow one label/helper/error structure - States exist: hover, focus, disabled, loading, empty If something is off, update the spec/tokens and regenerate—don’t patch one-off margins.

लॉग इन शुरू करें

क्यों जनरेट की गई React स्क्रीन अक्सर असंगत लगती हैं

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

अक्खर यह विचलन कुछ बुनियादी चीजों से आता है:

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

यह तब सामान्य है जब स्क्रीन अलग-अलग प्रॉम्प्ट्स से बनाई जाती हैं। हर प्रॉम्प्ट असल में एक नया शुरुआत होता है, इसलिए मॉडल अनुमान से बची हुई कई छोटी-छोटी फैसले भर देता है। यहां तक कि “मॉडर्न स्टाइल” बोलने से भी सैकड़ों छोटे विकल्प खुले रह जाते हैं: 8px बनाम 12px गैप, 14px बनाम 16px बॉडी टेक्स्ट, कब एरर दिखाना है, प्राथमिक बटन कैसा दिखेगा।

आप दो-तीन पेज्स मैन्युअली ठीक कर सकते हैं, लेकिन यह स्केल नहीं होता। आप वन-ऑफ CSS फिक्स के पीछे भागते रहेंगे, फाइलों में स्टाइल कॉपी करेंगे, और फॉर्म्स फिर से ठीक करेंगे। नियम आपके दिमाग में हैं, प्रोजेक्ट में नहीं।

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

जब हर स्क्रीन एक ही साझा सिस्टम का पालन करती है — डिजाइन टोकन्स (spacing, type, color) और कुछ कंपोनेंट व फॉर्म नियम — तो सुसंगति डिफ़ॉल्ट बन जाती है।

सरल भाषा में डिजाइन टोकन्स

डिजाइन टोकन्स सरल नाम वाले मान हैं जिन्हें आप UI में बार-बार उपयोग करते हैं। हर स्क्रीन पर “आरामदायक पैडिंग” मांगने के बजाय आप space-4 जैसे टोकन का उपयोग करते हैं। “थोड़ी गोलाई” के बजाय radius-md इस्तेमाल करते हैं। नाम स्थिर रहता है, भले ही बाद में आप उसके मान बदल दें।

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

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

क्या टोकनाइज़ करें और क्या लचीला रखें?

उसे टोकनाइज़ करें जो पूरे प्रोडक्ट के फील को प्रभावित करता है: स्पेसिंग स्केल, फ़ॉन्ट साइज और लाइन-हाइट, मुख्य रंग (text, background, primary, danger, border), और कुछ बॉर्डर रेडियस।

कंटेंट-ड्रिवन चॉइस लचीले रखें, जैसे कॉपी की लंबाई, कौन सा आइकन उपयोग करना है, या किसी सेक्शन को दो या तीन कार्ड चाहिए या नहीं।

जब आप स्क्रीन जनरेट करते हैं (किसी टूल जैसे Koder.ai के साथ भी), तो पहले एक छोटा टोकन सेट देने से अनुमान कम होता है और आउटपुट काफी अधिक सुसंगत दिखता है।

एक छोटा पर पूर्ण टोकन सेट चुनें

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

स्पेसिंग से शुरू करें। एक स्केल चुनें और उसे पैडिंग, गैप्स और लेआउट के लिए हर जगह उपयोग करें। 4, 8, 12, 16, 24, 32 जैसा सेट अधिकांश UI को कवर कर देता है। अगर डिज़ाइन 10px या 18px का मांग करता है, तो नया नंबर जोड़ने के बजाय निकटतम टोकन पर गोल कर दें।

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

एक कॉम्पैक्ट सेट जो उपयोगी रहे बिना बढ़ता जाए:

Spacing: 4, 8, 12, 16, 24, 32
Type: एक बॉडी साइज, दो हेडिंग साइज, बॉडी के लिए एक लाइन हाइट, हेडिंग्स के लिए एक लाइन हाइट
Colors: text-primary, text-muted, bg, surface, border, accent
Radius: दो मान (उदा. 4 और 12)
Elevation: none, small, medium (तीन स्तर अधिकतम)

Accessibility भी सिस्टम में होनी चाहिए। एक फोकस आउटलाइन स्टाइल (रंग, मोटाई, ऑफ़सेट) रखें ताकि कीबोर्ड उपयोगकर्ताओं को समान फोकस स्टेट्स मिलें। मोबाइल के लिए न्यूनतम टैप टारगेट (जैसे 44x44) सेट करें। कंट्रास्ट को पूर्वानुमानित रखने के लिए टेक्स्ट रंगों को एक छोटी, विश्वसनीय सूची तक सीमित रखें।

यदि बटन कभी-कभी तंग लगते हैं, तो अक्सर कारण यह होता है कि एक स्क्रीन ने padding 10 उपयोग किया और दूसरी ने 12। टोकन्स के साथ आप कह सकते हैं: “Buttons use paddingY=8, paddingX=16, radius=12, focus outline token, min height 44.” जब ये नंबर फ़िक्स हो जाते हैं, जनरेटर अनुमान करना बंद कर देता है।

वे कंपोनेंट नियम जो हर स्क्रीन को संरेखित रखते हैं

टोकन्स संख्याएँ तय करते हैं। कंपोनेंट नियम आदतें तय करते हैं।

कुछ कोर कंपोनेंट्स चुनें और उन्हें ही स्क्रीन बनाते समय प्राथमिक बिल्डिंग ब्लॉक्स मानें। उन्हें सरल और पुन:प्रयोगी रखें: Button, Input, Select, Checkbox, Card। आप TextArea और Modal जोड़ सकते हैं, पर वे उसी सिस्टम (लेबल, स्पेसिंग, स्टेट्स) का पालन करें।

फिर, वेरिएंट्स को सीमित करें और परिभाषित करें कि वे कब इस्तेमाल होंगे। उदाहरण:

Button के पास primary, secondary, और danger हैं। Primary स्क्रीन की मुख्य क्रिया के लिए है (आम तौर पर एक)। Secondary कैंसल या कम-प्राथमिकता क्रियाओं के लिए है। Danger सिर्फ विनाशकारी क्रियाओं जैसे delete के लिए है। अगर वेरिएंट सही तरह से जायज़ नहीं ठहरता, तो डिफॉल्ट के रूप में secondary का उपयोग करें।

स्पेसिंग नियम सूक्ष्म ड्रिफ्ट को रोकते हैं। कंपोनेंट्स के अंदर डिफॉल्ट्स परिभाषित करें: Button padding, Input height, लेबल-से-फ़ील्ड गैप, stacked फील्ड्स के बीच सामान्य गैप। कुछ लेआउट नियम भी जोड़ें: Cards की फिक्स्ड इंटरनल पैडिंग और हेडर/बॉडी स्पेसिंग; Modals एक ही चौड़ाई स्टेप्स और फ़ूटर अलाइनमेंट का उपयोग करें।

अंत में, स्टेट्स को गैर-वार्तालापीय बनाएं क्योंकि यहीं UIs अक्सर यादृच्छिक दिखना शुरू करते हैं:

Loading: कंट्रोल डिसेबल करें, स्पिनर दिखाएँ, चौड़ाई स्थिर रखें
Disabled: कंट्रास्ट कम करें, पर hover/focus स्टाइल पूरी तरह हटाएँ नहीं
Empty states: एक छोटा संदेश और एक स्पष्ट क्रिया
Validation: एरर फील्ड के नीचे दिखें और बड़े लेआउट शिफ्ट न करें

जब आप “Create project” जैसा फॉर्म-भारी स्क्रीन जनरेट करते हैं, ये नियम मिक्स बटन साइज, लेबल पोजिशन में शिफ्ट, या किसी एक पेज पर दिखने वाला एक-ऑफ “स्पेशल” कार्ड जैसी समस्याओं को रोकते हैं।

फॉर्म व्यवहार नियम: वे विवरण जो आमतौर पर ड्रिफ्ट करते हैं

Own the React codebase

Ship what you generated by exporting source code and keeping your token system in the repo.

Export Code

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

एक फॉर्म पैटर्न चुनें और हर जगह उसी का उपयोग करें: लेबल, optional/required मार्कर, helper टेक्स्ट, फिर एरर टेक्स्ट। शब्दावली भी लगातार रखें (उदा. सेंटेंस केस लेबल, छोटा helper टेक्स्ट, और एरर संदेश क्रिया से शुरू हों)।

वे नियम जो अधिकांश ड्रिफ्ट रोकते हैं:

लेबल हमेशा फ़ील्ड के ऊपर (placeholder को लेबल के रूप में न उपयोग करें)
Helper text हमेशा फ़ील्ड के नीचे, एक ही साइज और रंग में, कभी एरर के लिए उपयोग न करें
Validation टाइमिंग: एरर ब्लर या सबमिट के बाद दिखें, चेंज पर साफ़/अपडेट हों
Error placement: एक एरर लाइन सीधे फ़ील्ड के नीचे, helper टेक्स्ट के साथ आलाइन
Focus व्यवहार: Tab ऑर्डर विज़ुअल लेआउट का पालन करे; Enter तभी सबमिट करे जब अंतिम फ़ील्ड हो या प्राथमिक बटन फोकस में हो

साइज़िंग और लेआउट को लॉक कर दें ताकि स्क्रीन अलग-अलग “साँस” न लें। एक इनपुट की एक ही ऊँचाई, एक बटन ऊँचाई, और एक डिफ़ॉल्ट फ़ील्ड चौड़ाई परिभाषित करें। डेस्कटॉप पर फ़ील्ड्स को एक समान ग्रिड पर अलाइन करें और लेबल्स को ऊपर स्टैक करें। मोबाइल पर फ़ील्ड्स फुल-विथ करें और दो-कालम फॉर्म तभी उपयोग करें जब वास्तव में आवश्यक हो।

एक साधारण उदाहरण: “Create project” स्क्रीन में Name, Region, और Description हो सकते हैं। भले ही Region एक select हो, उसे किसी अन्य फ़ील्ड की तरह ट्रीट करें: वही ऊँचाई, वही लेबल पोजिशन, वही एरर लाइन। अगर यूजर Name खाली छोड़कर सबमिट करता है, फोकस Name पर जाता है, एरर उसके नीचे दिखता है, और लेआउट स्थिर रहता है।

अगर आप Koder.ai में स्क्रीन जनरेट करते हैं, इन फॉर्म नियमों को अपने प्रॉम्प्ट में एक बार डालें और फीचर भर में फिर से उपयोग करें ताकि हर नया फॉर्म बिना बार-बार सफाई के समान व्यवहार करे।

अपने प्रॉम्प्ट में टोकन्स और नियम कैसे व्यक्त करें

अपने प्रॉम्प्ट को एक छोटे UI कॉन्ट्रैक्ट की तरह ट्रीट करें। इसे छोटा, सटीक और पुन:प्रयोगी रखें ताकि हर नई स्क्रीन वही स्पेसिंग, टाइपोग्राफी, कंपोनेंट और व्यवहार अपनाए।

एक व्यावहारिक पैटर्न है कि आप अपनी रिक्वेस्ट के ऊपर एक कॉम्पैक्ट UI स्पेस चिपकाएँ, फिर स्क्रीन को सामान्य भाषा में वर्णित करें।

एक कॉम्पैक्ट प्रॉम्प्ट टेम्पलेट

UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)

Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast

Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16

Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below

Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles

If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens

स्पेक के बाद कुछ ऐक्सेप्टेंस चेक्स जोड़ें जो ड्रिफ्ट जल्दी पकड़ लें:

“Use only the tokens above; no inline styles.”
“All forms must use FormRow and show errors the same way.”
“If you must add a component, base it on Card plus existing typography.”

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

ऐसी वर्कफ़्लो जो स्क्रीन को सुसंगत रखे

कुछ भी जनरेट करने से पहले UI कॉन्ट्रैक्ट लिखें: एक छोटा टोकन सेट (spacing, type, colors, radius, shadows) और एक छोटी कंपोनेंट सूची (Button, Input, Select, Card, Modal, Table, Toast)। अगर कोई टोकन या कंपोनेंट गायब है, तो मॉडल नया बना देगा और आपकी UI ड्रिफ्ट करेगी।

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

वहां से, नए स्क्रीन बनाते समय पहले से परिभाषित चीज़ों को कंपोज़ करें। “Fresh styling” न माँगे। वही Card, वही spacing scale, वही टाइपोग्राफी स्टेप्स, और वही फ़ील्ड पैटर्न माँगें।

एक सरल वर्कफ़्लो:

टोकन्स और कंपोनेंट नियम कन्फरम करें, फिर फीचर के लिए उन्हें फ्रीज़ करें
एक रेफ़रेंस स्क्रीन जनरेट करें और स्पेक तब तक एडजस्ट करें जब तक यह सही न लगे
नए स्क्रीन कंपोनेंट्स को पुन:प्रयोग करके बनाएं, रिस्टाइल करके नहीं
सुसंगति की समीक्षा करें, फिर नियम (टोकन्स/कंपोनेंट) बदलें—न कि व्यक्तिगत पिक्सलों को
स्पेक को अगले फीचर के लिए एक पुन:प्रयोगी स्निपेट के रूप में सेव करें

अगर “Search users” स्क्रीन रेफ़रेंस से सख्त स्पेसिंग के साथ आती है, तो मैन्युअली मार्जिन बदलने की बजाय स्पेसिंग टोकन या Card पैडिंग नियम एक बार अपडेट करें और फिर पुनःजनरेट करें।

यदि आप Koder.ai में काम कर रहे हैं, तो स्नैपशॉट्स और रोलबैक मददगार हो सकते हैं: एक बेसलाइन लॉक करें, सुरक्षित रूप से प्रयोग करें, और अगर कोई बदलाव ड्रिफ्ट लाना शुरू करे तो जल्दी रिवर्ट करें।

बचने योग्य सामान्य गलतियाँ

Go from UI to live app

Deploy and host your app after you confirm spacing, type scale, and component rules.

Deploy App

सुसंगति खोने का सबसे तेज़ तरीका यह है कि टोकन्स और नियमों को सुझाव माना जाए। छोटे अपवाद नए स्क्रीन के साथ गुणा हो जाते हैं।

एक आम जाल स्पेसिंग स्केल को प्रोजेक्ट के बीच बदलना है। शुरुआती स्क्रीन 8,16,24 का उपयोग करती हैं। एक नई स्क्रीन 10 और 18 जोड़ देती है “क्योंकि वह सही लगता है।” अब ड्रिफ्ट वैध हो गया है, और पुराने स्क्रीन अपडेट नहीं होते।

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

स्टेट्स भी अक्सर मिस होते हैं। Loading, empty, और error स्टेट्स अक्सर स्पेसिंग और व्यवहार बदलते हैं। अगर आप इन्हें बाद में जोड़ते हैं, तो आम तौर पर आप परदर्शी पैटर्न पाएँगे जो बाकी से मेल नहीं खाते।

उस गलत प्रकार की विशेषता से भी सावधान रहें: “इसे मॉडर्न बनाओ नरम शैडो के साथ” अस्पष्ट है, जबकि व्यवहार नियम जैसे “errors show under the field,” “disabled buttons keep focus styles,” और “Enter submits only on the last field” ठोस और दोहराने योग्य हैं।

यदि आप प्रॉम्प्ट में एक हल्का गार्डरेल ब्लॉक रखना चाहते हैं, तो इसे छोटा रखें:

Use the same spacing scale and typography tokens as existing screens; don’t invent new values
Use only approved components and variants
Include loading, empty, and error states using the same tokens
Specify behaviors (validation, focus order, submit, disabled) as clearly as visuals

स्क्रीन को स्वीकार करने से पहले तेज़ कंसिस्टेंसी चेकलिस्ट

जनरेट की गई स्क्रीन को मर्ज करने से पहले दो मिनट का स्कैन करें।

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

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

बटन स्कैन करें। वेरिएंट और साइज आपके नियमों के अनुसार होने चाहिए: मुख्य क्रिया के लिए primary, कम महत्वपूर्ण क्रियाओं के लिए secondary, delete जैसे मामलों के लिए danger। बटन की ऊँचाई, आइकन प्लेसमेंट, और लेबल स्टाइल मेल खाना चाहिए।

फॉर्म्स के लिए, सुसंगति ज्यादातर स्ट्रक्चर के बारे में है। लेबल एक ही जगह रहें, required संकेत एक नियम का पालन करें, helper टेक्स्ट और एरर्स परस्पर प्रतिस्पर्धा न करें, और एरर्स एक सुसंगत जगह पर दिखें।

एक छोटा चेकलिस्ट:

Spacing uses only token values (no random numbers)
Typography matches the type scale (including line height)
Buttons follow the same variants and sizes
Forms use one pattern for labels, helper text, and errors
States exist: hover, focus, disabled, loading, empty

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

उदाहरण: स्टाइल ड्रिफ्ट के बिना एक छोटा React फीचर जनरेट करना

Reuse a small component set

Generate Button, Input, Card, and layout patterns once, then compose every screen from them.

Start Building

कल्पना कीजिए एक सरल ऑनबोर्डिंग फ्लो: तीन स्क्रीन (Profile, Preferences, Confirm), और बाद में एक Settings पेज। आप चाहते हैं कि हर स्क्रीन ऐसा लगे जैसे वही डिज़ाइनर ने बनायी हों, भले ही वे अलग रन में जनरेट हुई हों।

कुछ भी जनरेट करने से पहले एक छोटा टोकन सेट और कुछ कंपोनेंट नियम दें:

TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12

COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts

अब अलग-अलग “Profile” और “Preferences” जनरेट करें। क्योंकि दोनों स्क्रीन Page, Card, Field, और Button row के रूप में परिभाषित किए गए हैं, वे समान मार्जिन, लेबल स्पेसिंग, और बटन प्लेसमेंट के साथ आएँगे। Confirm स्टेप तब भी फिट हो जाएगा, भले ही उसमें अधिक read-only टेक्स्ट हो।

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

जब आपको नया UI पीस चाहिए, मॉडल को इम्प्रोवाइज करने न दें। एक नियम जोड़ें, फिर पुनःजनरेट करें और पुन:प्रयोग का ध्यान रखें:

ProgressStepper: height=32, spacing=md, current step bold, completed steps clickable

अगले कदम: सुसंगति को डिफ़ॉल्ट बनाना

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

एक व्यावहारिक स्पेक आमतौर पर शामिल करता है: आपका टोकन टेबल (spacing, type, radii, colors), एक छोटी कंपोनेंट नियम सूची (buttons, inputs, cards, headings), फॉर्म व्यवहार नियम (validation timing, errors, disabled/loading), लेआउट डिफ़ॉल्ट्स (page padding, max width, section spacing), और एक छोटा “कभी मत करो” सूचि (random margins, ad-hoc font sizes)।

फिर एक आदत बनाइए: स्पेसिफ़िकेशन को पहले बदलें, न कि व्यक्तिगत पिक्सल्स को।

यदि आप Koder.ai (koder.ai) उपयोग कर रहे हैं, तो planning mode स्पेक को जनरेट करने से पहले फिर से स्पष्ट करने के लिए एक अच्छा स्थान है। जब आप विकल्प आज़माना चाहते हैं, तो snapshots और rollback आपको बिना स्थिर बेसलाइन खोए प्रयोग करने में मदद करते हैं।

अक्सर पूछे जाने वाले प्रश्न

Why do generated React screens look inconsistent even when I ask for “modern styling”?

Because each screen request is a fresh start. If you don’t provide a shared system, the generator fills in missing details by guessing—spacing, font sizes, button padding, shadows, and form behavior—so small differences pile up across pages.

What are design tokens in plain English, and why do they help?

Design tokens are named, reusable values for things like spacing, type sizes, colors, and radius.

Instead of “comfortable padding,” you use something like space-md. The name stays stable, and every screen reuses the same decisions so the UI stops drifting.

What’s a good “small but complete” token set to start with?

Start small and cover only what causes visible drift:

Spacing: 4, 8, 12, 16, 24, 32
Type: 1 body size + 2 heading sizes + fixed line heights
Colors: text, muted, bg, surface, border, primary, danger
Radius: 2 values (for example 8 and 12)
Elevation: none, small, medium

If you need a “new” value, round to the nearest token instead of inventing 10px or 18px.

How do I write a prompt that keeps every generated screen consistent?

Put a compact UI spec block at the top of every request and treat it like a contract:

List tokens (spacing/type/colors/radius)
List allowed components (Button, Input, Card, etc.)
Add hard rules (no new spacing values, no one-off CSS)

Then describe the screen below it. The key is to keep the spec unchanged across screens.

What component rules prevent the most UI drift?

Tokens define the numbers; component rules define the habits. Useful rules include:

Button: fixed height, padding, and only a few variants (primary/secondary/danger)
Inputs: one height, consistent label spacing, consistent border/focus style
Cards: fixed padding and predictable header/body spacing
Layout: standard page padding and section spacing

Default rule: if a variant can’t be justified, fall back to the standard one.

What’s the best default for form validation timing and error placement?

Pick one pattern and never break it:

Label always above the field (don’t use placeholders as labels)
Helper text below the field (not used for errors)
One error line directly under the field
Show errors after blur or submit, and clear/update on change

This avoids the common “one screen validates on blur, another only on submit” inconsistency users notice.

Which UI states should I standardize so screens don’t feel random?

Define a few non-negotiable state rules:

Loading: disable the control, show a spinner, keep width stable
Disabled: lower contrast, but keep focus behavior consistent
Empty state: short message + one clear action
Errors: inline under the field; avoid big layout shifts

If you don’t specify states, each screen tends to invent its own patterns.

What should I do when a screen needs a new component that isn’t in my list?

Don’t let it improvise styling. Add it as a documented extension of an existing pattern:

Base the new component on current tokens and a familiar container (often Card)
Define its sizing, spacing, and states using existing tokens
Add it to your approved component list for future screens

If you can’t describe it with tokens, it’s usually too custom and will cause drift.

What workflow keeps consistency when I generate screens over multiple sessions?

Create one “reference” screen that stresses the system (a form-heavy page works well), then reuse the same spec for every new screen.

In Koder.ai, you can use planning mode to restate and confirm the spec before generating, and use snapshots and rollback to keep a stable baseline while you experiment.

What’s a fast checklist to catch inconsistency before I merge a generated screen?

Use a quick scan before you accept the screen:

Spacing uses only token values (no random numbers)
Typography matches the type scale (including line height)
Buttons follow the same variants and sizes
Forms follow one label/helper/error structure
States exist: hover, focus, disabled, loading, empty

If something is off, update the spec/tokens and regenerate—don’t patch one-off margins.

React ऐप्स में डिजाइन टोकन्स और नियमों से सुसंगत UI | Koder.ai