केवल स्टाइल गैलरी नहीं — निर्णयों को परिभाषित करें
डिज़ाइन सिस्टम केवल स्क्रीनशॉट से अधिक है। यह उन निर्णयों को रिकॉर्ड करता है जो बार-बार आते हैं: सेक्शनों के बीच का अंतर, प्राथमिक क्रिया का उपचार, फॉर्म त्रुटि कैसे काम करती है, और सफलता या विफलता के बाद प्रयुक्त भाषा। USWDS डिज़ाइन टोकन (design tokens) को टाइपोग्राफी, स्पेसिंग, रंग, लाइन हाइट और ओपेसिटी जैसे मानों के लिए पृथक पैलेट के रूप में बताता है। नियम, उद्देश्य, अनुमोदित वेरिएंट और मालिक को दस्तावेज़ करें। बुनियाद से शुरू करें और उन पाँच से आठ घटकों के साथ शुरू करें जिन्हें महत्वपूर्ण यात्राओं में सबसे अधिक उपयोग किया जाता है; एक ही बार में हर पृष्ठ मानकीकृत करने से अक्सर स्पष्टता के बजाय शोर बनता है।
स्वीकृत रंग भूमिकाएँ, टाइप, स्पेसिंग, बॉर्डर, रेडियस, ब्रेकपॉइंट और आपकी साइट जो मूवमेंट/मोटन विकल्प वास्तव में उपयोग करती है, रिकॉर्ड करें।
एकल दृश्य सजावट के बजाय, खाता बनाना या सर्च परिणाम जैसे दोहराए जाने वाले कार्य विन्यास के लिए एक पैटर्न का उपयोग करें।
दोहराए जाने वाले मानों को नियंत्रित करने के लिए टोकन का उपयोग करें
डिज़ाइन टोकन एक मान के साथ जुड़ा मानव-पठनीय नाम होता है। Design Tokens Community Group टोकन को प्लेटफ़ॉर्म-एग्नॉस्टिक तरीके के रूप में वर्णित करता है; न्यूनतम रूप में टोकन एक नाम और मान है। raw मानों को टेम्पलेट्स में बिखेरने के बजाय color-action-primary या space-section जैसे उद्देश्य-आधारित नामों का उपयोग करें। उद्देश्य टोकन से बेस मानों का एक दस्तावेजीकृत मैप रखें। टोकन समन्वित परिवर्तनों को आसान बनाते हैं, परन्तु वे कंट्रास्ट, ब्रांडिंग, या अच्छी हायरार्की की गारंटी नहीं देते। प्रत्येक रेंडर किए गए संयोजन और पृष्ठ स्थिति को वैध करें।
हर अपवाद के लिए नहीं, बल्कि दोहराए जाने वाले विकल्पों के लिए टोकन बनाएं; अन्यथा टोकन सूची बस असंगतियों को संरक्षित कर देगी।
किसी व्यापक रूप से उपयोग किए जाने वाले टोकन के लिए प्रभावित पृष्ठों की सूची बनाएं, प्रतिनिधि स्क्रीन पर परीक्षण करें, और आवश्यकता होने पर माइग्रेशन या रोलबैक मार्गदर्शन दें।
व्यवहार और सीमाओं के साथ घटक बनाएं
एक घटक केवल दृश्य आकृति नहीं बल्कि व्यवहार वाला पुन: प्रयोज्य इंटरफ़ेस हिस्सा होता है। सैमान्टिक संरचना, आवश्यक और वैकल्पिक इनपुट, वेरिएंट, प्रतिक्रियाशील व्यवहार, और सभी प्रासंगिक अवस्थाएँ—लोडिंग, अक्षम (disabled), त्रुटि, खाली, और सफलता—दस्तावेज़ करें। कीबोर्ड व्यवहार और सामग्री मार्गदर्शन शामिल करें। हर लेआउट को घटक में बाध्य न करें। GOV.UK साझा घटकों का मूल्यांकन उपयोगिता, विशिष्टता, प्रयोज्यता, सुसंगतता और बहुमुखी प्रतिभा के लिए करता है; यह तय करने के लिए एक उपयोगी अनुशासन है कि किसे साझा रखरखाव मिलना चाहिए। व्यापक रूप से प्रयुक्त घटक किसी दोष को व्यापक रूप से फैला सकता है, इसलिए उसे उन पृष्ठों पर परीक्षण करें जहाँ लोग वास्तव में उसका उपयोग करते हैं।
प्रत्येक उपयोगकर्ता-दिखने वाली स्थिति सूचीबद्ध करें और वास्तविक लेबल, लंबा टेक्स्ट, और त्रुटियों को दिखाएँ ताकि कार्यान्वयन सीमाएँ स्पष्ट हों।
पुराने वेरिएंट्स को स्पष्ट रूप से चिह्नित करें, प्रतिस्थापन का नाम बताएं, और प्रभावित यात्राओं की समीक्षा होने के बाद ही इन्हें हटाएँ।
रिलीज़ शर्त के रूप में एक्सेसिबिलिटी को लागू करें
एक्सेसिबिलिटी सिस्टम में निर्मित होनी चाहिए क्योंकि बार-बार की जाने वाली पसंदें बाधाएँ भी दोहरा सकती हैं। WCAG 2.2, लेवल A पर आवश्यकताओं में, जहाँ मूवमेंट पाथ स्वाभाविक न हो वहां कीबोर्ड से संचालन और जब क्रम महत्व रखता है तब अर्थपूर्ण फोकस क्रम शामिल है। घटक मार्गदर्शन का हिस्सा बनाएं: सैमान्टिक कंट्रोल, दिखाई देने वाला फोकस, लेबल, तार्किक फोकस मूवमेंट, त्रुटि पहचान और गैर-पॉइंटर कार्य पूरा करना। शुरुआती चरण में ऑटोमेटेड चेक का उपयोग करें, फिर मैनुअल कीबोर्ड, ज़ूम, प्रतिक्रियाशील और पृष्ठ परीक्षण करें। USWDS चेतावनी देता है कि सुलभ घटक सेवा की सुलभता की गारंटी नहीं देते; कस्टम कोड, कॉपी, एकीकरण और संदर्भ अभी भी समीक्षा मांगते हैं।
सुनिश्चित करें कि लोग माउस के बिना नियंत्रण तक पहुँच, संचालन, समझ और निकास कर सकते हैं और कोई कीबोर्ड ट्रैप न हो।
कानूनी दायित्व क्षेत्र, अनुबंध और संदर्भ के अनुसार भिन्न होते हैं। जब अनुपालन महत्वपूर्ण हो तो योग्य एक्सेसिबिलिटी और विधिक समीक्षा लें।
सामग्री मानकों को इंटरफ़ेस मानकों की तरह ट्रीट करें
शब्द घटक इनपुट हैं, डिजाइन के बाद की सजावट नहीं। क्रिया लेबल, फॉर्म लेबल, त्रुटियाँ, शीर्षक, लिंक, पदावली, तिथियाँ, संख्याएँ और संक्षेपण के नियम सेट करें। GOV.UK मार्गदर्शन जहाँ संभव हो सक्रिय वॉइस और उपयोगकर्ता को 'आप' के रूप में संबोधित करने की वकालत करता है; स्पष्ट, सुसंगत भाषा के सिद्धांत का पालन करें, और अपनी ऑडियन्स के अनुसार वॉइस को अनुकूलित करें। नियमों को एक सामग्री मॉडल के साथ जोड़ें: कौन से फ़ील्ड आवश्यक हैं, व्यवहार्य लंबाई मार्गदर्शन, और जब जानकारी अनुपस्थित हो तो क्या होता है। मार्गदर्शन को घटक दस्तावेजों और CMS वर्कफ़्लोज़ में रखें ताकि संपादक इसका उपयोग कर सकें।
बताएँ क्या असफल हुआ, कहाँ हुआ, और अगला कदम क्या है जब इसे बताना सुरक्षित और उपयोगी हो।
सीमा इस बात का संकेत है कि पुनःडिजाइन या पुनःलेखन की ज़रूरत है, न कि आवश्यक अर्थ हटाने की अनुमति।
जब सिस्टम भरोसे से तेज़ बढ़े तो शासन करें
गवर्नेंस वह हल्का-फुल्का प्रक्रिया है जो स्वामित्व, अनुरोध, समीक्षा, रिलीज़ और रिटायरमेंट के लिए ज़रूरी है। एक उत्तरदायी मालिक और एक समीक्षा समूह नामित करें जिसमें डिज़ाइन, इंजीनियरिंग, सामग्री और एक्सेसिबिलिटी विशेषज्ञता हो। साक्ष्य को विस्फोट-विस्तार (blast radius) के अनुरूप मिलाएँ। एक स्थानीय पैटर्न को समस्या कथन और पृष्ठ परीक्षण की आवश्यकता हो सकती है। एक साझा बटन या टोकन परिवर्तन में प्रभावित यात्राएँ, एक्सेसिबिलिटी चेक, दृश्य तुलना, माइग्रेशन नोट्स और रोलबैक निर्देश शामिल होने चाहिये। GOV.UK योगदानकर्ताओं से पूछता है कि एक घटक कई टीमों के लिए उपयोगी है, न कि एक डुप्लिकेट, और प्रतिनिधि उपयोगकर्ताओं के साथ परीक्षण किया गया है; इसे सार्वभौमिक नियम के बजाय व्यावहारिक मॉडल के रूप में उपयोग करें।
समस्या, विकल्प, निर्णय, मालिक, प्रभावित संस्करण और समीक्षा तिथि वह जगह सेव करें जहाँ टीमें इसे खोज सकें।
परिवर्तनों को patch, additive, या breaking के तौर पर लेबल करें ताकि उपभोक्ता यह जान सकें कि माइग्रेशन और संगतता अवधि कब ज़रूरी है।
रिलीज़ से पहले रेग्रेसन रोकें
सिस्टम को डिलीवरी से कनेक्ट करें। किसी परिवर्तन की आवश्यकता हो तो छोड़े गए टोकन और घटकों की पहचान करना अनिवार्य करें, फिर प्रभावित अवस्थाओं और प्रतिनिधि पृष्ठों का परीक्षण करें। दृश्य तुलना, इंटरैक्शन टेस्ट, सामग्री समीक्षा और एक्सेसिबिलिटी चेक विभिन्न दोष ढूँढते हैं। उच्च-परिणामी यात्राओं के साथ-साथ उच्च-ट्रैफ़िक यात्राओं को प्राथमिकता दें; खाता पहुँच और संपर्क फ़ॉर्म ट्रैफ़िक मामूली होने पर भी महत्वपूर्ण हो सकते हैं। यह Status Is UP के सक्रिय uptime ऑप्टिमाइज़ेशन और सुधार कार्य का समर्थन करता है क्योंकि यह दोष के दायरे को संकुचित कर देता है और अनुमोदित ठीक को सत्यापित करना आसान बनाता है। यह डाउनटाइम मॉनिटरिंग या घटना योजना का विकल्प नहीं है।
कम्पोनेंट संस्करण, परीक्षण परिणाम, निष्कर्ष, अनुमोदन और किसी भी स्वीकार किए गए जोखिम को रिलीज़ रिकॉर्ड के साथ रखें।
पिछला स्थिर संस्करण सुरक्षित रखें और कम-जोखिम रखरखाव के दौरान पुनर्स्थापना और सत्यापन चरण लिखित रूप में परीक्षण करें।