5.2 UI डिज़ाइन और डिज़ाइन सिस्टम

अवलोकन और प्रेरणा

यूज़र इंटरफ़ेस (UI) डिज़ाइन लोग जो देखते और छूते हैं उसे आकार देने की कला है: लेआउट, टाइपोग्राफी, रंग, स्पेसिंग, नियंत्रण, और स्थितियां। एक डिज़ाइन सिस्टम उस कला को लेकर एक साझा, पुन: उपयोग-योग्य, गवर्न की गई संपत्ति में बदल देता है: सिद्धांतों, कंपोनेंट, पैटर्न, और टोकन का एक दस्तावेज़ीकृत सेट जिससे हर टीम आकर्षित होती है, ताकि पूरा उत्पाद एक इकाई के रूप में दिखे और व्यवहार करे। UI डिज़ाइन तय करता है कि एक स्क्रीन कैसी दिखनी चाहिए। एक डिज़ाइन सिस्टम तय करता है कि कई टीमों में दस हज़ार स्क्रीन कैसे सुसंगत रहें।

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

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

मुख्य सिद्धांत

• सुसंगति संज्ञानात्मक भार को कम करती है; एक बटन को हर जगह एक जैसा दिखना और व्यवहार करना चाहिए।
• डिज़ाइन निर्णय संपत्तियां हैं: उन्हें एक बार पुन: उपयोग-योग्य कंपोनेंट और टोकन के रूप में कैप्चर करें।
• टोकन दृश्य निर्णयों के लिए सत्य का स्रोत हैं; कंपोनेंट टोकन का उपभोग करते हैं, कभी हार्ड-कोडेड मान का नहीं।
• एक्सेसिबिलिटी और रेस्पॉन्सिवनेस कंपोनेंट में निर्मित हैं, प्रति स्क्रीन जोड़े नहीं गए हैं।
• एक डिज़ाइन सिस्टम उपयोगकर्ताओं (डेवलपर और डिज़ाइनर) वाला एक उत्पाद है, एक बार की डिलीवरेबल नहीं।
• दृश्य पदानुक्रम ध्यान का मार्गदर्शन करता है: टाइप, रंग, और स्थान को महत्व को स्पष्ट बनाना चाहिए।
• गवर्नेंस एक सिस्टम को सुसंगत रखता है; योगदान इसे जीवित रखता है।

अनुशंसाएँ

सिस्टम को परतों में संरचित करें: टोकन, कंपोनेंट, पैटर्न

डिज़ाइन टोकन रंग, स्पेसिंग, टाइपोग्राफी, रेडियस, एलिवेशन, और गति के लिए नामित, प्लेटफ़ॉर्म-अज्ञेय मान हैं: परमाणु निर्णय। इन्हें स्तरों में बनाएं: एक प्रिमिटिव पैलेट (कच्चे मान), सिमेंटिक टोकन (color-action-primary, space-inset-md) जो अर्थ वहन करते हैं, और कंपोनेंट-स्तरीय टोकन जहां आपको उनकी ज़रूरत हो। कंपोनेंट सिमेंटिक टोकन का उपभोग करते हैं, इसलिए एक ही परिवर्तन हर जगह प्रसारित होता है। कंपोनेंट के ऊपर पैटर्न बैठते हैं: सिद्ध संयोजन जैसे एक डेटा टेबल, एक बहु-चरणीय फ़ॉर्म, या एक खाली स्थिति। लाइव उदाहरणों और उपयोग मार्गदर्शन के साथ तीनों परतों को एक ही जगह दस्तावेज़ीकृत करें।

दृश्य मूल सिद्धांतों को सही करें

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

रेस्पॉन्सिव और मोबाइल-फर्स्ट डिज़ाइन करें

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

डिज़ाइन-से-डेव हैंडऑफ़ और समानता को प्रथम-श्रेणी की चिंता बनाएं

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

उद्यम पैमाने पर थीमिंग और व्हाइट-लेबलिंग का समर्थन करें

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

सिस्टम को एक उत्पाद के रूप में गवर्न करें

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

समझौते: फायदे और नुकसान

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

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

अपनी टीम के साथ चर्चा करने योग्य प्रश्न

1. हमारी टोकन आर्किटेक्चर कैसे स्तरित है, और क्या कंपोनेंट को हार्ड-कोडेड मान उपयोग करने से प्रतिबंधित किया गया है? एक डिज़ाइन सिस्टम का पूरा फल (सस्ते रीब्रांड, बहु-ब्रांड थीमिंग, एक बार हल की गई एक्सेसिबिलिटी) इस पर निर्भर करता है कि कंपोनेंट कोड में बिखरे कच्चे रंगों और पिक्सेल मानों के बजाय color-action-primary जैसे सिमेंटिक टोकन का उपभोग करें। अभी स्तर तय करें: एक प्रिमिटिव पैलेट, सिमेंटिक टोकन जो अर्थ वहन करते हैं, और कंपोनेंट-स्तरीय टोकन केवल वहां जहां आपको वास्तव में उनकी ज़रूरत हो। अत्यधिक एब्स्ट्रैक्शन एक वास्तविक जोखिम है, इसलिए सहमत हों कि कितनी परतें बहुत ज़्यादा हैं और एक डेवलपर सही टोकन जल्दी कैसे ढूंढता है। बहाव के प्रमाण के रूप में अपने कोडबेस में हार्ड-कोडेड रंगों और स्पेसिंग की एक grep लाएं। यदि ब्रांड तर्क कंपोनेंट में बेक किया गया है, तो एक रीब्रांड एक कॉन्फ़िग परिवर्तन के बजाय एक कोड फिर-लेखन बन जाता है, जो ठीक वही आपदा है जिसे रोकने के लिए टोकनाइज़ेशन मौजूद है।

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

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

4. हम यह कैसे गारंटी देते हैं कि एक्सेसिबिलिटी कंपोनेंट के अंदर एक बार हल हो जाए, और किसी टीम को एक अनएक्सेसिबल एक-बार का कंपोनेंट शिप करने से क्या रोकता है? एक डिज़ाइन सिस्टम के लिए सबसे मज़बूत तर्क यह है कि रंग कंट्रास्ट, फ़ोकस स्थितियां, कीबोर्ड संचालन, और स्क्रीन-रीडर सिमेंटिक्स को एक बार हल किया जाता है और हर जगह विरासत में मिलता है, लेकिन वह वादा उसी क्षण ढह जाता है जब टीमें अपने खुद के नियंत्रण हाथ से बनाती हैं। एक बड़े संगठन के लिए, यही वह जगह है जहां सबसे बड़ा कानूनी और प्रतिष्ठा जोखिम बैठा है, क्योंकि एक भी अनएक्सेसिबल भुगतान फ़ॉर्म या डेट पिकर वास्तविक उपयोगकर्ताओं को रोक सकता है और उसे कॉपी करने वाले हर उत्पाद में शिकायतें ट्रिगर कर सकता है। केंद्रीय प्रवर्तन (एक्सेसिबल कंपोनेंट प्लस एक लिंटर या समीक्षा गेट जो कच्चे मार्कअप को अस्वीकार करता है) को टीम स्वायत्तता के विरुद्ध तौलें, और तय करें कि कठोर रेखा कहां है। एक एक्सेसिबिलिटी ऑडिट के परिणाम, उनकी अनुरूपता स्थिति के साथ कंपोनेंट की एक सूची, और उन बीस्पोक नियंत्रणों की गिनती लाएं जिन्हें टीमों ने सिस्टम के बाहर फिर से बनाया। उद्यम और सरकारी परिस्थितियों में यह कोई शिष्टाचार नहीं है: WCAG, Section 508, और EN 301 549 जैसे दायित्व अनुरूपता को एक खरीद और ऑडिट आवश्यकता बनाते हैं, इसलिए दस्तावेज़ीकृत अनुरूपता वाली एक कंपोनेंट लाइब्रेरी स्वयं एक अनुपालन संपत्ति है।

5. इस सिस्टम को कितने ब्रांड, किरायेदारों, और थीम की सेवा करनी चाहिए, और क्या हमने अभी उसके लिए टोकन परत को आर्किटेक्ट किया है बजाय इसे बाद में रेट्रोफ़िट करने के? थीमिंग सस्ती है यदि आपने इसके लिए डिज़ाइन किया है और क्रूर है यदि नहीं, क्योंकि एक ऐसा ब्रांड या किरायेदार जिसकी कभी अपेक्षा नहीं की गई, ब्रांड तर्क को वापस कंपोनेंट में धकेल देता है और टोकनाइज़ेशन के पूरे उद्देश्य को पूर्ववत कर देता है। एक बड़ी टीम के लिए यह निर्णय वर्षों के काम को आकार देता है: एक प्लेटफ़ॉर्म जिसे कई ब्रांड, एक लाइट और डार्क थीम, एक हाई-कंट्रास्ट मोड, और प्रति-किरायेदार ब्रांडिंग की सेवा करनी चाहिए, उसे एक सिमेंटिक टोकन परत की ज़रूरत है जो इतनी साफ़ हो कि एक थीम केवल मानों का एक अलग सेट हो। उस लचीलेपन को अत्यधिक एब्स्ट्रैक्शन के विरुद्ध तौलें, क्योंकि एक टोकन ट्री जिसे कोई नेविगेट नहीं कर सकता, अपनी खुद की विफलता है। उन ब्रांडों और किरायेदारों का रोडमैप लाएं जिनकी आप कल्पना कर सकते हैं, आज कितनी थीम चलन में हैं, और कोई भी कंपोनेंट जो पहले से ब्रांड-विशिष्ट तर्क लीक कर रहे हैं। उद्यम और सरकारी संदर्भों में विलय, अधिग्रहण, और एजेंसी पुनर्गठन नियमित रूप से ऐसे ब्रांड जोड़ते हैं जिनकी आपने योजना नहीं बनाई थी, इसलिए शुरुआत से बहु-ब्रांड के लिए आर्किटेक्ट करना एक डेटा परिवर्तन और एक बहु-वर्षीय फिर-लेखन के बीच का अंतर है।

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

क्षेत्रीय दृष्टिकोण

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

लघु व्यवसाय। बिना किसी समर्पित डिज़ाइनर और सीमित बजट के, बनाने के बजाय खरीदें: एक सिद्ध कंपोनेंट लाइब्रेरी या UI किट अपनाएं और इसे अपने ब्रांड के अनुसार हल्के से थीम करें। आपका लक्ष्य एक डिज़ाइन-सिस्टम टीम को स्टाफ किए बिना एक सुसंगत, एक्सेसिबल उत्पाद है, इसलिए ऐसे सिस्टम को प्राथमिकता दें जो बॉक्स में एक्सेसिबिलिटी और रेस्पॉन्सिवनेस शिप करता है। इसे फोर्क करने के आग्रह का विरोध करें, क्योंकि एक कस्टमाइज़्ड कॉपी जिसे आप बनाए नहीं रख सकते, उस क्षण एक देयता बन जाती है जब अपस्ट्रीम प्रोजेक्ट आगे बढ़ जाता है।

उद्यम। समस्या कई टीमों और दीर्घकालिक उत्पादों में सुसंगति है, इसलिए डिज़ाइन सिस्टम को एक समर्पित टीम, वर्ज़निंग, और एक रोडमैप वाले गवर्न किए गए साझा इंफ्रास्ट्रक्चर के रूप में मानें। डिज़ाइन-कोड समानता को एक वास्तविक मीट्रिक के रूप में ट्रैक करें, CI में विज़ुअल रीग्रेशन परीक्षण जोड़ें, और शुरुआत से कई ब्रांड और थीम के लिए टोकन परत को आर्किटेक्ट करें। गवर्नेंस और माइग्रेशन लागत का स्पष्ट रूप से बजट बनाएं, और यह मान लेने के बजाय कि टीमें अपने आप सिस्टम पर बहक जाएंगी, अपनाने को एक पोर्टफोलियो के रूप में प्रबंधित करें।

सरकार। खरीद नियम, पारदर्शिता, और सार्वजनिक जवाबदेही हर विकल्प को आकार देते हैं। WCAG, Section 508, और EN 301 549 जैसे मानकों के लिए एक्सेसिबिलिटी अनुरूपता एक कानूनी आवश्यकता है, एक प्राथमिकता नहीं, इसलिए दस्तावेज़ीकृत अनुरूपता वाली एक कंपोनेंट लाइब्रेरी एक अनुपालन संपत्ति बन जाती है। एक साझा सार्वजनिक डिज़ाइन सिस्टम को प्राथमिकता दें या विस्तारित करें ताकि नागरिक सेवाओं में वही पैटर्न देखें, विक्रेता अनुबंधों में डिज़ाइन-सिस्टम उपयोग लिखें, और अपने कंपोनेंट और मार्गदर्शन को खुले रूप से प्रकाशित करें ताकि एजेंसियां और उनके आपूर्तिकर्ता उन्हें अपना सकें और उनके लिए जवाबदेह ठहराए जा सकें।

उदाहरण

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

उद्यम। दर्जनों उत्पाद टीमों वाली एक वैश्विक सॉफ़्टवेयर कंपनी ने एक साझा कोडेड कंपोनेंट लाइब्रेरी के साथ एक टोकनाइज़्ड डिज़ाइन सिस्टम बनाया। सिमेंटिक टोकन ने उन्हें हफ्तों में सभी उत्पादों में एक पूरा ब्रांड रीफ्रेश शिप करने दिया, बहु-वर्षीय प्रति-टीम कठिन काम के बजाय, क्योंकि परिवर्तन हज़ारों हार्ड-कोडेड रंग संपादनों के बजाय एक नया टोकन सेट था। एक डैशबोर्ड मीट्रिक के रूप में ट्रैक की गई डिज़ाइन-कोड समानता बढ़ी जैसे-जैसे टीमों ने बीस्पोक कंपोनेंट को बदला, जिसने दोहराए गए UI रखरखाव को कम किया।

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

व्यवसाय मामला: प्रेरणाएं, ROI, और TCO

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

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

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

एंटी-पैटर्न और नुकसान

• स्टिकर शीट के रूप में डिज़ाइन सिस्टम: बिना कोडेड कंपोनेंट के एक स्थिर डिज़ाइन फ़ाइल, इसलिए इंजीनियर फिर भी सब कुछ फिर से बनाते हैं।
• हर जगह हार्ड-कोडेड मान: कोड में बिखरे रंग और स्पेसिंग, थीमिंग और रीब्रांड को असंभव बनाते हुए।
• कोई गवर्नेंस नहीं: टीमों द्वारा भिन्न प्रकार जोड़ने पर सिस्टम खंडित हो जाता है; सुसंगति क्षीण होती है।
• योगदान के बिना गवर्नेंस: केंद्रीय टीम एक बाधा बन जाती है और टीमें इसके आसपास घूमती हैं।
• समानता की अनदेखी: कोडेड UI डिज़ाइन इरादे से बहक जाता है और कोई भी अंतर नहीं मापता।
• अत्यधिक एब्स्ट्रैक्शन: इतने सारे टोकन और परतें कि कोई भी सही टोकन ढूंढ या उपयोग नहीं कर सकता।
• ब्रांड तर्क कंपोनेंट में बेक किया गया: बहु-ब्रांड और थीमिंग को कॉन्फ़िग परिवर्तन के बजाय कोड फिर-लेखन बनाता है।
• माइग्रेशन समर्थन के बिना तोड़ने वाले परिवर्तन: उपभोग करने वाली टीमें रुक जाती हैं या सिस्टम को फोर्क करती हैं।

परिपक्वता मॉडल

स्तर 1: आरंभ (Initiate)। हर टीम अपना UI तदर्थ और प्रतिक्रियात्मक रूप से बनाती है। कोई साझा कंपोनेंट नहीं, असंगत रूप और व्यवहार, रंग और स्पेसिंग प्रति स्क्रीन हार्ड-कोडेड। हर रीब्रांड एक मैनुअल स्क्रीन-दर-स्क्रीन कठिन काम है।

स्तर 2: विकास (Develop)। एक साझा स्टाइल गाइड या कंपोनेंट लाइब्रेरी मौजूद है लेकिन आंशिक, वैकल्पिक, और अक्सर डिज़ाइन और कोड के बीच बेमेल है। कुछ टीमें इसका उपयोग करती हैं, बाकी नहीं, और बुनियादी प्रथाएं टीम-दर-टीम व्यापक रूप से भिन्न होती हैं।

स्तर 3: मानकीकरण (Standardize)। एक बनाए रखी गई कोडेड लाइब्रेरी, दस्तावेज़ीकरण, और गवर्नेंस वाला एक टोकनाइज़्ड डिज़ाइन सिस्टम पूरे संगठन में दस्तावेज़ीकृत और लागू है। कंपोनेंट सिमेंटिक टोकन का उपभोग करते हैं, थीमिंग समर्थित है, और एक्सेसिबिलिटी व रेस्पॉन्सिवनेस प्रति स्क्रीन जोड़े जाने के बजाय निर्मित हैं।

स्तर 4: प्रबंधन (Manage)। सिस्टम को बेसलाइन के विरुद्ध डेटा के साथ मापा और नियंत्रित किया जाता है। डिज़ाइन-कोड समानता को प्रति उत्पाद लक्ष्यों के साथ एक स्पष्ट मीट्रिक के रूप में ट्रैक किया जाता है, बहाव पकड़ने के लिए CI में विज़ुअल रीग्रेशन परीक्षण चलता है, और एक्सेसिबिलिटी अनुरूपता को मान लेने के बजाय मानकों के विरुद्ध मापा जाता है। अपनाने वाले डैशबोर्ड टीम के अनुसार कंपोनेंट कवरेज दिखाते हैं, और रीब्रांड की लागत तथा अवधि दर्ज की जाती है ताकि सुधार समय के साथ दिखाई दे।

स्तर 5: ऑर्केस्ट्रेशन (Orchestrate)। डिज़ाइन सिस्टम एक निरंतर सुधरता हुआ उत्पाद है जो पूरे संगठन में एकीकृत और परिवर्तन के प्रति अनुकूली है। इसके पास वर्ज़निंग, एक रोडमैप, और एक कार्यशील योगदान मॉडल है, इसलिए यह वास्तविक ज़रूरतों के साथ विकसित होता है। रीब्रांड और नई थीम नियमित टोकन परिवर्तन हैं, बहु-ब्रांड और बहु-किरायेदार थीमिंग सामान्य है, और टीम उपयोग डेटा से प्रमाण पर पैटर्न को सेवानिवृत्त, पुनः-स्कोप, और प्रमोट करती है, एकल स्रोत सत्य से डिज़ाइन टूलिंग और डिलीवरी पाइपलाइनों को फीड करते हुए।

चर्चा के लिए विचार

• आप बिना किसी को खंडित या बाधित किए केंद्रीय गवर्नेंस को टीम स्वायत्तता के विरुद्ध कैसे संतुलित करते हैं?
• “डिज़ाइन-कोड समानता” के लिए सही मीट्रिक क्या है, और आप इसे ईमानदार कैसे रखते हैं?
• एक टीम को सिस्टम का उपयोग करने के बजाय एक-बार का कंपोनेंट बनाने की अनुमति कब दी जानी चाहिए?
• आप एक डिज़ाइन सिस्टम को कैसे फंड और स्टाफ करते हैं ताकि यह बजट चक्रों और पुनर्गठनों में जीवित रहे?
• कितनी थीमिंग लचीलापन जोड़े गए एब्स्ट्रैक्शन लागत के लायक है?
• आप विरासत और विक्रेता-निर्मित एप्लिकेशन को एक साझा सिस्टम पर कैसे माइग्रेट करते हैं?

मुख्य निष्कर्ष

• एक डिज़ाइन सिस्टम एक-बार के डिज़ाइन निर्णयों को पुन: उपयोग-योग्य, गवर्न की गई पूंजी में बदल देता है।
• इसे परतों (टोकन, कंपोनेंट, पैटर्न) में संरचित करें, कंपोनेंट सिमेंटिक टोकन का उपभोग करते हुए।
• एक्सेसिबिलिटी और रेस्पॉन्सिवनेस को कंपोनेंट में बनाएं ताकि हर टीम उन्हें विरासत में पाए।
• डिज़ाइन-कोड समानता को एक धारणा के बजाय एक मापने योग्य स्वास्थ्य मीट्रिक के रूप में मानें।
• टोकनाइज़ेशन रीब्रांड और बहु-ब्रांड थीमिंग को फिर-लेखन के बजाय एक डेटा परिवर्तन बनाता है।
• सिस्टम को एक रोडमैप, वर्ज़निंग, और एक योगदान मॉडल वाले उत्पाद के रूप में गवर्न करें।
• उद्यम और सरकारी पैमाने पर, एक साझा सिस्टम उपलब्ध सबसे उच्च-लाभ वाला UI निवेश है।

संदर्भ और आगे का अध्ययन

• Brad Frost, Atomic Design
• Alla Kholmatova, Design Systems: A Practical Guide to Creating Design Languages
• Josef Müller-Brockmann, Grid Systems in Graphic Design
• Robert Bringhurst, The Elements of Typographic Style
• Ellen Lupton, Thinking with Type
• Luke Wroblewski, Mobile First
• Ethan Marcotte, Responsive Web Design
• Nathan Curtis, writings on design tokens and design system governance
• W3C Design Tokens Community Group, format specification
• Government design systems (e.g., UK Government Design System, U.S. Web Design System) as reference implementations