डिज़ाइन सिस्टम की योजना बनाना
अपने डिज़ाइन सिस्टम का दायरा परिभाषित करें, जिसमें टोकन वर्गीकरण, कंपोनेंट सूची और आपके द्वारा उपयोग किए जाने वाले दस्तावेज़ीकरण टूल शामिल हों।
डिज़ाइन सिस्टम की योजना बनाना, CoddyKit पर Tailwind CSS Academy का एक निःशुल्क पाठ है। यह 4 में से 1वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Tailwind CSS Academy सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Tailwind CSS Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
डिज़ाइन प्रणाली क्या है
डिज़ाइन प्रणाली पुनः उपयोग किए जा सकने वाले घटकों, डिज़ाइन टोकन, दिशानिर्देशों और दस्तावेज़ों का संग्रह होती है, जो टीमों को सुसंगत उपयोगकर्ता इंटरफ़ेस कुशलतापूर्वक बनाने में सक्षम बनाती है। Tailwind के संदर्भ में, डिज़ाइन प्रणाली में tailwind.config.js में टोकन कॉन्फ़िगरेशन, स्टाइल किए गए घटकों की लाइब्रेरी, लिखित परंपराएँ और दस्तावेज़ीकरण उपकरण शामिल होते हैं, ताकि पूरी टीम समाधान दोबारा बनाने के बजाय प्रणाली का उपयोग करे।
प्रणाली का दायरा निर्धारित करना
कोड लिखने से पहले अपनी डिज़ाइन प्रणाली का दायरा निर्धारित करें। तीन प्रश्नों के उत्तर दें: यह किन उत्पादों के लिए है? (एक ऐप, कई ऐप या तृतीय-पक्ष उपभोक्ता)। इसमें घटकों की कौन-सी श्रेणियाँ शामिल हैं? (टाइपोग्राफ़ी, फ़ॉर्म, लेआउट के मूल घटक, जटिल पैटर्न)। इसका रखरखाव कौन करता है? (समर्पित टीम या वितरित योगदानकर्ता)। दायरा जटिलता और शासन से जुड़े हर अगले निर्णय को दिशा देता है।
/* Design System Scope Document (example) */
Products:
- Web marketing site
- Admin dashboard
- Mobile web app (responsive)
Component inventory:
- Primitives: Button, Input, Badge, Icon
- Layout: Stack, Grid, Container
- Composite: Card, Modal, Dropdown, Toast
- Complex: DataTable, DatePicker, Combobox
Maintainers:
- Design System team (2 engineers, 1 designer)
- Contributors: any engineer via PRटोकन वर्गीकरण की योजना
डिज़ाइन टोकन वे परमाणु मान हैं जिनसे प्रणाली बनाई जाती है। दो-स्तरीय वर्गीकरण की योजना बनाएँ: मूल टोकन कच्चे मान होते हैं (जैसे blue-500: #3b82f6), जबकि अर्थपूर्ण टोकन उद्देश्य-आधारित संदर्भ होते हैं (जैसे color.primary: blue-500)। घटक अर्थपूर्ण टोकन का उपयोग करते हैं; अर्थपूर्ण टोकन मूल टोकन का संदर्भ देते हैं। यह अप्रत्यक्षता घटकों को बदले बिना थीम बदलने में सक्षम बनाती है।
/* Token taxonomy plan */
/* Tier 1 — Primitives (raw values) */
/* color.blue.500 = #3b82f6 */
/* color.red.500 = #ef4444 */
/* spacing.4 = 1rem */
/* Tier 2 — Semantic tokens (purpose-driven) */
/* color.primary = color.blue.500 */
/* color.danger = color.red.500 */
/* color.surface = color.white */
/* spacing.component = spacing.4 */दस्तावेज़ीकरण उपकरण चुनना
दस्तावेज़ीकरण का तरीका जल्दी चुनें, क्योंकि इससे यह तय होता है कि आप घटक कैसे लिखेंगे। सामान्य विकल्प हैं: इंटरैक्टिव घटक सैंडबॉक्स और दृश्य प्रतिगमन परीक्षण के लिए स्टोरीबुक, कोड नमूनों वाले लिखित दस्तावेज़ों के लिए डॉक्यूसॉरस, या अपने डिज़ाइन सिस्टम का उपयोग करने वाली कस्टम Next.js दस्तावेज़ीकरण साइट (अर्थात अपने ही उत्पाद का व्यवहार में उपयोग करना)। हर विकल्प की स्थापना लागत और रखरखाव के बोझ के बीच अलग-अलग समझौते होते हैं।
/* Documentation tool comparison */
Storybook:
+ Visual sandbox for every component
+ Addon ecosystem (a11y, viewport, interactions)
- Setup and maintenance overhead
- Separate from your app, can drift
Custom docs site:
+ Uses your actual design system live
+ No tooling drift
- More initial build work
Docusaurus:
+ Markdown-driven, easy to write
- No interactive component sandbox by defaultघटक सूची और प्राथमिकता निर्धारण
अपने उत्पादों के लिए आवश्यक हर घटक की सूची बनाएँ और उन्हें उपयोग की आवृत्ति तथा सुसंगतता पर प्रभाव के आधार पर प्राथमिकता दें। बटन हर जगह दिखाई देते हैं—उन्हें पहले बनाएँ। DataTables का उपयोग कम होता है और वे जटिल होते हैं—उन्हें बाद के चरणों तक टाल दें। घटक नाम, प्राथमिकता (उच्च/मध्यम/कम) और स्थिति (नियोजित/प्रगति में/पूर्ण) वाले स्तंभों की एक साधारण स्प्रेडशीट निर्माण की प्रगति पर नज़र रखने के लिए पर्याप्त है।
/* Component inventory (simplified) */
Priority HIGH (build in sprint 1-2):
Button, Input, Label, Badge, Icon, Spinner
Priority MEDIUM (sprint 3-4):
Card, Modal, Dropdown, Toast, Tooltip, Avatar
Priority LOW (sprint 5+):
DatePicker, Combobox, DataTable, RichTextEditorसुलभता मानकों की योजना
कोई भी घटक बनाने से पहले सुलभता का लक्ष्य स्तर तय करें। WCAG 2.1 AA वह मानक है जिसे अधिकांश संगठन लक्ष्य बनाते हैं। दस्तावेज़ित करें कि प्रत्येक घटक प्रकार को कौन-से ARIA पैटर्न लागू करने होंगे: बटनों को type विशेषताएँ चाहिए, मोडल में फ़ोकस को सीमित करना चाहिए, ड्रॉपडाउन में role='listbox' चाहिए आदि। योजना चरण में सुलभता शामिल करने की लागत बाद में उसे जोड़ने की तुलना में बहुत कम होती है।
/* Accessibility checklist per component type */
Button:
[ ] aria-label when icon-only
[ ] disabled state with aria-disabled
[ ] focus-visible ring
Modal:
[ ] aria-modal + role='dialog'
[ ] aria-labelledby pointing to title
[ ] Focus trap on open
[ ] Escape key closes
[ ] Return focus to trigger on close
Dropdown:
[ ] role='listbox' + aria-expanded on trigger
[ ] role='option' + aria-selected on items
[ ] Keyboard navigation (up/down/enter/escape)घटकों के लिए नामकरण परंपराएँ
एक भी घटक लिखने से पहले नामकरण परंपराएँ तय करें। घटक नामों (PascalCase), वैरिएंट प्रॉप नामों (variant: primary | secondary | danger) और आकार प्रॉप नामों (size: sm | md | lg) के लिए एक शैली चुनें। इसे अपनी योगदान मार्गदर्शिका में लिखें, ताकि सभी योगदानकर्ता नामों को लेकर कोड समीक्षा में मतभेद की आवश्यकता के बिना पूर्वानुमेय और आसानी से खोजे जा सकने वाले API बनाएँ।
/* Component API convention examples */
/* Variant prop: primary, secondary, ghost, danger */
<Button variant='primary'>Save</Button>
<Button variant='ghost'>Cancel</Button>
/* Size prop: sm, md, lg */
<Button size='sm'>Compact</Button>
<Button size='lg'>Large CTA</Button>
/* State props: boolean adjectives */
<Button loading={true}>Saving...</Button>
<Button disabled={true}>Unavailable</Button>रिपॉज़िटरी संरचना की योजना
कोड लिखने से पहले रिपॉज़िटरी की संरचना तय करें। एक सामान्य डिज़ाइन प्रणाली पैकेज में src/components/ निर्देशिका (प्रति घटक एक उपनिर्देशिका), src/tokens/ निर्देशिका, src/index.ts बैरल निर्यात और tailwind.config.js होता है। निकटता बनाए रखने के लिए स्टोरीबुक की कहानियाँ अपने घटकों के साथ ComponentName.stories.tsx फ़ाइलों में रहती हैं।
packages/ui/
├── src/
│ ├── components/
│ │ ├── Button/
│ │ │ ├── Button.tsx
│ │ │ ├── Button.test.tsx
│ │ │ └── Button.stories.tsx
│ │ └── Card/
│ │ ├── Card.tsx
│ │ └── Card.stories.tsx
│ ├── tokens/
│ │ ├── colors.ts
│ │ └── typography.ts
│ └── index.ts # barrel export
├── tailwind.config.js
└── package.jsonशासन और योगदान प्रक्रिया
शासन के बिना डिज़ाइन प्रणाली असंगत हो जाती है। एक योगदान प्रक्रिया निर्धारित करें: इंजीनियर नए घटकों का प्रस्ताव कैसे देते हैं (RFC दस्तावेज़ या समस्या साँचा), उनकी समीक्षा कौन करता है (डिज़ाइन प्रणाली टीम और एक अन्य डिज़ाइनर), और स्वीकृति मानदंड क्या हैं (WCAG AA, TypeScript प्रकार, स्टोरीबुक कहानी, इकाई परीक्षण)। इसे पैकेज की मूल निर्देशिका में मौजूद CONTRIBUTING.md में लिखें।
# CONTRIBUTING.md
## Proposing a new component
1. Open a GitHub issue with the Component Proposal template
2. Tag @design-system-team for review
3. Await approval before implementing
## Component acceptance criteria
- [ ] TypeScript props with JSDoc
- [ ] All variants documented in Storybook
- [ ] WCAG AA accessibility (checked with axe-core)
- [ ] Unit tests for behavior
- [ ] Changelog entryसंस्करण निर्धारण और विघटनकारी बदलाव नीति
सिमेंटिक वर्ज़निंग का उपयोग करके डिज़ाइन प्रणाली का संस्करण निर्धारित करें: बग सुधारों के लिए पैच, नए घटकों या जोड़ात्मक बदलावों के लिए माइनर, और मौजूदा API में विघटनकारी बदलावों के लिए मेजर। हर रिलीज़ के साथ मशीन द्वारा पढ़े जा सकने वाले बदलाव-विवरण प्रकाशित करें। हटाने से पहले पुराने API कितने समय तक समर्थित रहेंगे, इसकी नीति बनाएँ—आमतौर पर दो मेजर संस्करण—ताकि उपभोक्ताओं को बिना अटकाए स्थानांतरित होने का समय मिल सके।
/* Versioning policy */
Patch (1.0.x) — non-breaking:
Bug fixes, accessibility improvements, style tweaks
Minor (1.x.0) — non-breaking:
New components, new optional props, new variants
Major (x.0.0) — breaking:
Removed props, renamed components, changed APIs
Deprecate 2 minor versions before removal
Provide codemod where possibleडिज़ाइन हस्तांतरण और टोकन समन्वयन
अपनी Figma फ़ाइलों और कोड के बीच डिज़ाइन टोकन का समन्वय बनाए रखें। स्टाइल डिक्शनरी या टोकन स्टूडियो जैसे उपकरण Figma डिज़ाइन टोकन को सीधे JSON प्रारूप में निर्यात कर सकते हैं, जिससे Tailwind कॉन्फ़िगरेशन भर जाता है। सत्य का यह एकल स्रोत उस सामान्य स्थिति को रोकता है जिसमें डिज़ाइनर Figma में रंग बदल देते हैं, लेकिन कोड कई सप्ताह बाद भी पुराने हेक्स मानों का उपयोग करता रहता है।
# Style Dictionary: transforms design tokens to Tailwind-compatible output
# tokens/raw/colors.json (from Figma export)
{
"brand": {
"blue": { "500": { "value": "#3b82f6" } }
}
}
# After running Style Dictionary:
# tokens/tailwind/colors.js
module.exports = {
brand: { blue: { 500: '#3b82f6' } }
};
# Consumed in tailwind.config.js:
colors: { ...require('./tokens/tailwind/colors') }त्वरित जाँच
इस पाठ में Tailwind CSS Mastery की अवधारणाओं की अपनी समझ जाँचें।
पाठ का पुनरावलोकन
इस पाठ में आपने सीखा: उत्पादों, घटक सूची और रखरखाव की ज़िम्मेदारी सहित प्रणाली का दायरा निर्धारित करना, मूल और अर्थपूर्ण टोकन के साथ दो-स्तरीय टोकन वर्गीकरण की योजना बनाना, और योगदान प्रक्रियाओं, संस्करण नीति तथा डिज़ाइन से कोड तक टोकन समन्वयन के साथ शासन स्थापित करना। अब हम टोकन और कॉन्फ़िगरेशन परत लागू करेंगे।
एआई शिक्षक के साथ HTML सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 30
- पाठ
- 120
अक्सर पूछे जाने वाले प्रश्न
क्या “डिज़ाइन सिस्टम की योजना बनाना” पाठ निःशुल्क है?
हाँ—“डिज़ाइन सिस्टम की योजना बनाना” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Tailwind CSS Academy पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Tailwind CSS Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“डिज़ाइन सिस्टम की योजना बनाना” में मैं क्या सीखूँगा?
अपने डिज़ाइन सिस्टम का दायरा परिभाषित करें, जिसमें टोकन वर्गीकरण, कंपोनेंट सूची और आपके द्वारा उपयोग किए जाने वाले दस्तावेज़ीकरण टूल शामिल हों। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Tailwind CSS Academy का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Tailwind CSS Academy शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Tailwind CSS Academy शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 1वाँ पाठ है।
“डिज़ाइन सिस्टम की योजना बनाना” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Tailwind CSS Academy पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Tailwind CSS Academy पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- डिज़ाइन सिस्टम की योजना बनाना
- टोकन और कॉन्फ़िगरेशन लेयर बनाना
- कंपोनेंट लाइब्रेरी का निर्माण
- दस्तावेज़ीकरण और टीम को हस्तांतरण