डिज़ाइन सिस्टम: ज़्यादातर क्यों विफल होते हैं और एक सफल सिस्टम कैसे बनाएँ
ज़्यादातर डिज़ाइन सिस्टम एक साल के भीतर खत्म हो जाते हैं. यहाँ बताया गया है कि वे क्यों विफल होते हैं, सफल सिस्टम में क्या समानताएँ हैं, और एक ऐसा सिस्टम कैसे बनाएँ जिसका आपकी टीम वास्तव में उपयोग करेगी.
हर टीम जो एक निश्चित आकार तक पहुँचती है, अंततः वही बात कहती है: "हमें एक डिज़ाइन सिस्टम की ज़रूरत है." फिर उनमें से ज़्यादातर छह महीने एक ऐसा सिस्टम बनाने में बिताते हैं जिसका कोई उपयोग नहीं करता, और एक साल बाद वे उसी असंगति पर वापस आ जाते हैं जिससे उन्होंने शुरुआत की थी.
समस्या कभी भी कंपोनेंट्स में नहीं होती. समस्या डिज़ाइन सिस्टम को एक प्रोजेक्ट की तरह मानने में है, न कि एक प्रोडक्ट की तरह. प्रोजेक्ट खत्म हो जाते हैं. प्रोडक्ट विकसित होते हैं. एक डिज़ाइन सिस्टम जो विकसित होना बंद कर देता है, वह लॉन्च के दिन ही खत्म होना शुरू हो जाता है.
डिज़ाइन सिस्टम वास्तव में क्या है
एक डिज़ाइन सिस्टम कंपोनेंट लाइब्रेरी नहीं है. एक कंपोनेंट लाइब्रेरी पुन: प्रयोज्य UI टुकड़ों का एक फ़ोल्डर है. एक डिज़ाइन सिस्टम मानकों, दस्तावेज़ों और उपकरणों का एक पूरा सेट है जो यह नियंत्रित करता है कि किसी प्रोडक्ट को कैसे डिज़ाइन और बनाया जाता है.
इसमें शामिल हैं:
- डिज़ाइन टोकन. परमाणु मान (रंग, स्पेसिंग, टाइपोग्राफी, शैडो) जिनका बाकी सब कुछ संदर्भ लेता है.
- कंपोनेंट्स. टोकन से बने पुन: प्रयोज्य UI तत्व.
- पैटर्न. बार-बार आने वाली डिज़ाइन समस्याओं (फ़ॉर्म, नेविगेशन, त्रुटि स्थितियाँ) के लिए दस्तावेज़ित समाधान.
- दिशानिर्देश. प्रत्येक टुकड़े का कब और कैसे उपयोग करना है, इसके नियम.
- शासन. सिस्टम का मालिक कौन है, परिवर्तनों का प्रस्ताव कैसे किया जाता है, और निर्णय कैसे लिए जाते हैं.
इनमें से किसी को भी हटा दें और आपके पास एक आंशिक सिस्टम होगा. आंशिक सिस्टम आंशिक अपनाने को जन्म देते हैं. आंशिक अपनाने से वही असंगति पैदा होती है जिसे आप हल करने की कोशिश कर रहे थे.
ज़्यादातर डिज़ाइन सिस्टम क्यों विफल होते हैं
विफलता 1: अलगाव में निर्मित. एक छोटी टीम तीन महीने के लिए गायब हो जाती है, एक सुंदर सिस्टम बनाती है, और इसे एक ऐसे संगठन के सामने प्रस्तुत करती है जिसका कोई इनपुट नहीं था. सिस्टम बिल्डरों की धारणाओं को दर्शाता है, न कि उपयोगकर्ताओं की वास्तविकता को. अपनाने की प्रक्रिया पहले तो विनम्र होती है, फिर चुपचाप छोड़ दी जाती है.
विफलता 2: बहुत जल्दी बहुत कठोर. सिस्टम हर परिदृश्य के लिए सख्त नियमों के साथ लॉन्च होता है. डिज़ाइनर और इंजीनियर जो एक ऐसे मामले का सामना करते हैं जिसकी सिस्टम ने उम्मीद नहीं की थी, उनके पास दो विकल्प होते हैं: सिस्टम से लड़ना या उसके आसपास काम करना. ज़्यादातर लोग काम के आसपास का रास्ता चुनते हैं. सिस्टम एक ऐसा संदर्भ बन जाता है जिसका कोई संदर्भ नहीं लेता.
विफलता 3: कोई समर्पित स्वामित्व नहीं. सिस्टम एक स्प्रिंट के दौरान बनाया गया था. इसे बनाए रखने के लिए किसी को नियुक्त नहीं किया गया है. टोकन कोडबेस से भटक जाते हैं. कंपोनेंट्स प्रोडक्ट से पीछे रह जाते हैं. दस्तावेज़ बासी हो जाते हैं. छह महीने बाद, सिस्टम पिछले साल प्रोडक्ट कैसा दिखता था, उसका एक स्नैपशॉट होता है.
विफलता 4: कंपोनेंट-फर्स्ट सोच. टीम एक भी टोकन परिभाषित करने या एक भी दिशानिर्देश लिखने से पहले 47 कंपोनेंट्स बनाती है. कंपोनेंट्स Figma फ़ाइल में काम करते हैं लेकिन प्रोडक्शन में टूट जाते हैं क्योंकि अंतर्निहित मानों को कभी व्यवस्थित नहीं किया गया था.
विफलता 5: पूर्णता का पक्षाघात. टीम कुछ भी लॉन्च करने से पहले हर किनारे के मामले को हल करने की कोशिश करती है. सिस्टम कभी शिप नहीं होता. इस बीच, प्रोडक्ट इसके बिना रोज़ाना शिप होता है.
सफल सिस्टम में क्या समानताएँ हैं
वास्तव में टिकने वाले सिस्टम (Shopify Polaris, Atlassian Design System, IBM Carbon, GitHub Primer) का अध्ययन करने के बाद, तीन पैटर्न सामने आते हैं:
उन्होंने छोटे से शुरुआत की और विकसित हुए. उनमें से किसी ने भी 200 कंपोनेंट्स के साथ लॉन्च नहीं किया. उन्होंने टोकन, कुछ मुख्य कंपोनेंट्स और स्पष्ट दस्तावेज़ों के साथ लॉन्च किया. फिर उन्होंने वास्तविक प्रोडक्ट की ज़रूरतों के आधार पर विस्तार किया, न कि सैद्धांतिक पूर्णता के आधार पर.
उनके पास समर्पित टीमें हैं. एक व्यक्ति नहीं. एक टीम. बड़े पैमाने पर डिज़ाइन सिस्टम के लिए कम से कम एक डिज़ाइनर, एक इंजीनियर, एक दस्तावेज़ लेखक और एक प्रोडक्ट मालिक की आवश्यकता होती है. Shopify में Polaris पर दर्जनों लोग काम कर रहे हैं. आपको दर्जनों की ज़रूरत नहीं है, लेकिन आपको शून्य से ज़्यादा की ज़रूरत है.
वे योगदान को एक सुविधा के रूप में मानते हैं. सबसे अच्छे सिस्टम प्रोडक्ट टीमों के लिए जोड़ का प्रस्ताव करना, मुद्दों को चिह्नित करना और कंपोनेंट्स का योगदान करना आसान बनाते हैं. सिस्टम किनारों से बढ़ता है, न कि केवल केंद्र से. एक सिस्टम जो केवल एक टीम के निर्णयों से बढ़ता है, वह हमेशा प्रोडक्ट से पीछे रहेगा.
डिज़ाइन टोकन ही असली नींव हैं
टोकन आदिम मान होते हैं जिनसे बाकी सब कुछ विरासत में मिलता है. एक टोकन बदलें, और हर कंपोनेंट जो इसे संदर्भित करता है, स्वचालित रूप से अपडेट हो जाता है. यही एक सिस्टम को एक संग्रह के बजाय एक सिस्टम बनाता है.
टोकन स्तर:
| स्तर | उदाहरण | उद्देश्य |
|---|---|---|
| ग्लोबल | color-blue-500: #3B82F6 | कच्चे पैलेट मान |
| सिमेंटिक | color-primary: {color-blue-500} | अर्थ-आधारित उपनाम |
| कंपोनेंट | button-bg: {color-primary} | कंपोनेंट-विशिष्ट बाइंडिंग |
ग्लोबल टोकन कच्चे मानों को परिभाषित करते हैं. सिमेंटिक टोकन अर्थ (प्राथमिक, खतरा, सतह) प्रदान करते हैं. कंपोनेंट टोकन उन अर्थों को विशिष्ट UI तत्वों से जोड़ते हैं. यह तीन-परत संरचना का मतलब है कि आप एक भी कंपोनेंट को छुए बिना सिमेंटिक टोकन बदलकर रीब्रांड कर सकते हैं.
पहले परिभाषित करने के लिए टोकन प्रकार:
- रंग (पृष्ठभूमि, टेक्स्ट, बॉर्डर, इंटरैक्टिव स्थितियाँ)
- स्पेसिंग (4px ग्रिड: 4, 8, 12, 16, 24, 32, 48, 64)
- टाइपोग्राफी (फ़ैमिली, साइज़ स्केल, वज़न, लाइन हाइट)
- बॉर्डर रेडियस (कोई नहीं, छोटा, मध्यम, बड़ा, पूर्ण)
- शैडो (एलिवेशन स्तर)
- मोशन (अवधि, ईज़िंग कर्व्स)
यदि आप कुछ और परिभाषित नहीं करते हैं, तो इन्हें परिभाषित करें. वे आपकी टीम द्वारा रोज़ाना लिए जाने वाले 90% विज़ुअल निर्णयों को कवर करते हैं.
ऐसे कंपोनेंट्स बनाना जो टिके रहें
टोकन पर बने कंपोनेंट्स हार्डकोडेड मानों पर बने कंपोनेंट्स की तुलना में स्वाभाविक रूप से अधिक लचीले होते हैं. लेकिन टोकन-आधारित कंपोनेंट्स भी गलत तरीके से बनाए जाने पर विफल हो जाते हैं.
टिकने वाले कंपोनेंट्स के लिए नियम:
कॉन्फ़िगरेशन पर कंपोज़िशन. 14 प्रॉप्स वाला बटन लचीला नहीं होता. यह नाजुक होता है. हर वेरिएंट को प्रॉप्स के माध्यम से संभालने वाला एक मेगा-कंपोनेंट बनाने के बजाय, छोटे, कंपोज़ेबल टुकड़े बनाएँ जो पैटर्न में संयोजित होते हैं. एक कार्ड एक कंपोनेंट नहीं है. यह एक कार्ड कंटेनर, एक कार्ड हेडर, एक कार्ड बॉडी और एक कार्ड फ़ूटर है जो एक साथ मिलकर बनते हैं.
स्टेट्स वैकल्पिक नहीं हैं. हर इंटरैक्टिव कंपोनेंट को इसकी आवश्यकता होती है: डिफ़ॉल्ट, होवर, सक्रिय, फ़ोकस, अक्षम, लोडिंग और त्रुटि स्थितियाँ. सभी सात स्टेट्स के बिना एक कंपोनेंट शिप करने का मतलब है कि कोई उन स्टेट्स को तदर्थ रूप से बनाएगा, और वे मेल नहीं खाएंगे.
"कब" दस्तावेज़ करें, न कि केवल "क्या." आपके बटन के दस्तावेज़ों में केवल यह नहीं दिखाना चाहिए कि यह कैसा दिखता है. इसमें यह बताया जाना चाहिए कि प्राथमिक बटन का उपयोग कब करना है बनाम द्वितीयक बटन बनाम घोस्ट बटन का उपयोग कब करना है. निर्णय ढाँचा विज़ुअल संदर्भ से ज़्यादा मायने रखता है.
पैटर्न उन समस्याओं को हल करते हैं जो कंपोनेंट्स नहीं कर सकते
एक ड्रॉपडाउन कंपोनेंट आपको बताता है कि एक ड्रॉपडाउन कैसा दिखता है. यह आपको यह नहीं बताता कि ड्रॉपडाउन का उपयोग कब करना है बनाम रेडियो ग्रुप बनाम सेगमेंटेड कंट्रोल का उपयोग कब करना है. वह निर्णय एक पैटर्न है.
जल्दी दस्तावेज़ करने के लिए पैटर्न:
- फ़ॉर्म लेआउट. लेबल प्लेसमेंट, त्रुटि प्रदर्शन, आवश्यक फ़ील्ड संकेत, मल्टी-स्टेप फ़्लो.
- नेविगेशन. टैब बनाम साइडबार बनाम ब्रेडक्रंब का उपयोग कब करना है. मोबाइल नेविगेशन कोलैप्स व्यवहार.
- खाली स्थितियाँ. जब कोई डेटा नहीं होता तो क्या दिखाता है. चित्रण? CTA? शैक्षिक सामग्री?
- लोडिंग स्थितियाँ. स्केलेटन स्क्रीन बनाम स्पिनर बनाम प्रोग्रेसिव लोडिंग. प्रत्येक कब उपयुक्त है.
- त्रुटि प्रबंधन. इनलाइन सत्यापन बनाम टोस्ट नोटिफिकेशन बनाम पूर्ण-पृष्ठ त्रुटि स्थितियाँ.
ये पैटर्न "हमने एक ही फ़ॉर्म को पाँच अलग-अलग तरीकों से बनाया" की समस्या को रोकते हैं जो बिना सिस्टम वाली टीमों को परेशान करती है.
शासन अपनाने को बनाता या बिगाड़ता है
शासन के बिना एक डिज़ाइन सिस्टम एक सुझाव है. शासन तीन सवालों के जवाब देता है:
- कौन तय करता है? क्या कोई समीक्षा बोर्ड है? एक अकेला मालिक? एक लोकतांत्रिक वोट? आप जो भी चुनें, उसे स्पष्ट करें.
- परिवर्तन कैसे होते हैं? RFC प्रक्रिया? GitHub मुद्दा? Slack थ्रेड? "मुझे लगता है कि हमें एक नए कंपोनेंट की ज़रूरत है" से "यह सिस्टम में है" तक का रास्ता परिभाषित करें.
- वर्जनिंग रणनीति क्या है? टोकन पैकेज के लिए सिमेंटिक वर्जनिंग? प्रति रिलीज़ चेंजलॉग? ब्रेकिंग चेंज पॉलिसी?
जो टीमें शासन को छोड़ देती हैं, वे एक ऐसे सिस्टम के साथ समाप्त होती हैं जो विभाजित हो जाता है. डिज़ाइन वर्जन 2.3 का उपयोग करता है. इंजीनियरिंग वर्जन 1.8 का उपयोग करती है. मार्केटिंग साइट स्थानीय ओवरराइड के साथ वर्जन 2.0 का उपयोग करती है. उस बिंदु पर, आपके पास तीन डिज़ाइन सिस्टम और शून्य संगति होती है.
अक्सर पूछे जाने वाले प्रश्न
डिज़ाइन सिस्टम बनाने में कितना समय लगता है?
प्रारंभिक नींव (टोकन, 10-15 मुख्य कंपोनेंट्स, बुनियादी दस्तावेज़) एक समर्पित टीम के साथ 2-4 महीने लगते हैं. लेकिन एक डिज़ाइन सिस्टम कभी "पूरा" नहीं होता. एक डिज़ाइन इंजीनियरिंग टीम की क्षमता का 15-25% निरंतर निवेश की योजना बनाएँ.
क्या छोटी टीमों को डिज़ाइन सिस्टम की ज़रूरत होती है?
हाँ, लेकिन एक आनुपातिक. एक 3-व्यक्ति टीम को Polaris की ज़रूरत नहीं होती. उन्हें टोकन, 8-10 मुख्य कंपोनेंट्स और एक-पृष्ठ निर्णय मार्गदर्शिका के साथ एक साझा Figma लाइब्रेरी की ज़रूरत होती है. सबसे ज़्यादा दर्द देने वाली चीज़ (आमतौर पर असंगत स्पेसिंग और रंग का उपयोग) से शुरू करें और वहीं से आगे बढ़ें.
डिज़ाइन सिस्टम और कंपोनेंट लाइब्रेरी में क्या अंतर है?
एक कंपोनेंट लाइब्रेरी पुन: प्रयोज्य UI तत्वों का एक संग्रह है. एक डिज़ाइन सिस्टम में कंपोनेंट लाइब्रेरी के साथ-साथ डिज़ाइन टोकन, उपयोग दिशानिर्देश, पैटर्न, दस्तावेज़ और शासन शामिल होते हैं. लाइब्रेरी सिस्टम की एक परत है.
महत्वाकांक्षा से नहीं, समस्या से शुरुआत करें
एक डिज़ाइन सिस्टम इसलिए न बनाएँ क्योंकि यह पेशेवर लगता है. इसे इसलिए बनाएँ क्योंकि आपकी टीम बार-बार एक ही समस्या को हल करने में समय बर्बाद कर रही है. उन तीन चीज़ों से शुरू करें जो अभी सबसे ज़्यादा असंगति पैदा करती हैं. उन्हें व्यवस्थित करें. उन्हें शिप करें. फिर टीम आगे क्या माँगती है, उसके आधार पर विस्तार करें, न कि उस पर जो किसी केस स्टडी में प्रभावशाली लगे.
Need a design system that scales with your product? We build those.
Get Started
