विषय 3.2 — डिज़ाइन सिस्टम और प्रोटोटाइपिंग

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

यह स्वास्थ्य और देखभाल में क्यों महत्वपूर्ण है#

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

एक डिज़ाइन सिस्टम है कि आप बार-बार वही गलतियों के लिए भुगतान करना कैसे बंद करते हैं। जब एक अभिगम्य, अच्छी तरह से परखा गया घटक एक बार बनाया जाता है और दर्जनों सेवाओं में पुनः उपयोग किया जाता है, तो आप एक जगह एक अभिगम्यता दोष या एक सुरक्षा अस्पष्टता ठीक करते हैं और हर सेवा फिक्स विरासत में लेती है। विकल्प — हर जगह कस्टम फ्रंट-एंड — का अर्थ है अज्ञात, असमान गुणवत्ता: कुछ सेवाएं Web Content Accessibility Guidelines (WCAG) को पूरा करती हैं और कुछ चुपचाप ठीक उन्हीं लोगों को बाहर करती हैं जो सार्वजनिक स्वास्थ्य सेवाओं पर सबसे अधिक निर्भर करते हैं।

सुसंगतता एक समझ मुद्दा भी है। रोगी और स्टाफ सेवाओं के बीच चलते हैं — एक National Health Service (NHS) ऐप, एक ट्रस्ट का बाह्य रोगी पोर्टल, एक सामान्य अभ्यास बुकिंग उपकरण — और हर अपरिचित पैटर्न संज्ञानात्मक भार लगाता है। एक जनसंख्या में जिसमें अस्वस्थ, चिंतित, बुजुर्ग, डिजिटल रूप से बहिष्कृत, या सहायक प्रौद्योगिकी का उपयोग करने वाले लोग शामिल हैं, वह भार समान रूप से वितरित नहीं होता। साझा पैटर्न इसे सभी के लिए कम करते हैं। यह विषय उस मशीनरी के बारे में है — घटक, पैटर्न, टोकन, प्रोटोटाइप, और डिज़ाइन संचालन — जो सुरक्षित, अभिगम्य, सुसंगत डिज़ाइन को एक वीरता के कार्य के बजाय सबसे कम प्रतिरोध का मार्ग बनाती है।

मुख्य अवधारणाएं#

एक डिज़ाइन सिस्टम डिजिटल सेवाओं के एक समूह को बनाने के लिए उपयोग किए जाने वाले पुनः उपयोग करने योग्य घटकों, पैटर्न, शैलियों, और मार्गदर्शन के लिए एक एकल सत्य स्रोत है। यह एक शैली गाइड से अधिक है: यह कामकाजी, कोडित घटकों को डिज़ाइन तर्क, अभिगम्यता नोट्स, और उपयोग मार्गदर्शन के साथ जोड़ता है जो आपको बताते हैं कब और कैसे हर एक का उपयोग करना है। दो सबसे प्रासंगिक सार्वजनिक उदाहरण NHS डिज़ाइन सिस्टम (NHS England द्वारा बनाए रखा गया, NHS.UK फ्रंट-एंड पर निर्मित) और GOV.UK Design System हैं, जिसे Government Digital Service (GDS) बनाए रखता है। दोनों खुले, स्वतंत्र रूप से उपलब्ध, और लाखों बातचीत में युद्ध-परखे गए हैं।

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

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

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

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

DesignOps (डिज़ाइन संचालन) पैमाने पर डिज़ाइन चलाने का अनुशासन है — लोग, वर्कफ़्लो, प्रशासन, योगदान मॉडल, और टूलिंग जो एक संगठन या एकीकृत देखभाल प्रणाली (ICS) में एक साझा डिज़ाइन सिस्टम को स्वस्थ, वित्तपोषित, और विश्वसनीय रखते हैं। यह डिज़ाइन के लिए वही है जो कोड के लिए प्लेटफ़ॉर्म इंजीनियरिंग है: जब यह काम करता है तो ज़्यादातर अदृश्य, जब यह नहीं करता तो दर्दनाक रूप से स्पष्ट। प्रोटोटाइपिंग Figma जैसे डिज़ाइन उपकरणों में या सीधे एक डिज़ाइन सिस्टम के फ्रंट-एंड का उपयोग करके कोड में की जाती है, जो हमें फ्रंट-एंड वेब डेवलपमेंट तक लाता है — HTML, CSS, और JavaScript परत जहां पुनः उपयोग वास्तव में दोहराव, लागत, और जोखिम कम करता है।

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

सर्वोत्तम प्रथाएं#

1. बनाने से पहले अपनाएं। अपना खुद का आविष्कार करने के बजाय NHS डिज़ाइन सिस्टम और GOV.UK Design System से शुरू करें। वे पहले से ही स्वास्थ्य और सरकारी सेवाओं में वर्षों की अभिगम्यता परीक्षण, सामग्री डिज़ाइन, और वास्तविक-दुनिया उपयोग को एनकोड करते हैं। एक तारीख चुनने वाले या एक त्रुटि सारांश को फिर से आविष्कार करना दुर्लभ, महंगी डिज़ाइन और इंजीनियरिंग क्षमता का अच्छा उपयोग नहीं है, और एक घर में उगाया गया संस्करण लगभग हमेशा कम अभिगम्य होगा। स्थानीय आवश्यकताओं के लिए इन सिस्टमों का विस्तार और थीम करें; बिना किसी सोच-समझकर, दस्तावेज़ीकृत कारण के उन्हें फोर्क न करें।

2. साझा घटकों में अभिगम्यता और क्लिनिकल सुरक्षा बनाएं, व्यक्तिगत स्क्रीनों में नहीं। एक डिज़ाइन सिस्टम के लिए पूरा आर्थिक और सुरक्षा मामला यह है कि आप एक बार कुछ ठीक करते हैं और इसे हर जगह विरासत में लेते हैं। एक अभिगम्य, कीबोर्ड-नेविगेट करने योग्य, स्क्रीन-रीडर-परखा जन्म-तिथि घटक, एक बार बनाया और सुनिश्चित किया गया, इसका उपयोग करने वाली हर सेवा की रक्षा करता है। WCAG अनुरूपता, समझदार त्रुटि हैंडलिंग, और सुरक्षा-संबंधित व्यवहार (विनाशकारी कार्रवाइयों की स्पष्ट पुष्टि, खुराक और माप के लिए स्पष्ट इकाइयां) को घटक में ही बनाएं, ताकि टीमें उन्हें आसानी से गलत न कर सकें (देखें विषय 1.9 — डिजिटल समावेशन और अभिगम्यता, और विषय 1.6 — क्लिनिकल सुरक्षा और जोखिम प्रबंधन)।

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

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

5. निर्माण से पहले वास्तविक उपयोगकर्ताओं के साथ प्रोटोटाइप परखें। एक प्रोटोटाइप जो कभी प्रतिनिधि उपयोगकर्ताओं के सामने नहीं रखा जाता वह बस एक महंगी राय है। उन लोगों के साथ परखें जो आपकी वास्तविक जनसंख्या को प्रतिबिंबित करते हैं — बुजुर्ग लोगों, विकलांगता वाले लोगों, कम डिजिटल आत्मविश्वास वाले लोगों, और समय दबाव में काम कर रहे स्टाफ सहित। यहां तक कि पांच प्रतिभागी अधिकांश गंभीर उपयोगिता और समझ समस्याओं को सामने लाएंगे, और उन्हें एक प्रोटोटाइप में खोजना प्रोडक्शन में खोजने से परिमाण के क्रम सस्ता है (देखें विषय 3.7 — परीक्षण और गुणवत्ता आश्वासन)।

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

7. एक दीवार वाला बगीचा नहीं, एक योगदान मॉडल चलाएं। एक डिज़ाइन सिस्टम जो केवल एक केंद्रीय टीम से इनपुट स्वीकार करता है वह हमेशा वास्तविक सेवा आवश्यकताओं से पीछे रहेगा और डिलीवरी टीमों द्वारा नाराज़ किया जाएगा। टीमों के नए घटकों और पैटर्न प्रस्तावित करने के लिए एक स्पष्ट मार्ग प्रकाशित करें, इसके साथ कि क्या स्वीकार किया जाता है, इसकी समीक्षा कौन करता है, और साझा लाइब्रेरी में कुछ भी प्रोमोट होने से पहले अभिगम्यता और सुरक्षा कैसे सुनिश्चित की जाती है। यह मुख्य DesignOps काम है: यह सिस्टम को सड़ने या खंडित होने दिए बिना स्थानीय लचीलेपन और साझा सुसंगतता के बीच तनाव को संतुलित करता है।

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

9. अस्तित्व नहीं, अपनाना और गुणवत्ता मापें। एक डिज़ाइन सिस्टम केवल तभी मूल्य देता है जब इसका उपयोग किया जाता है। ट्रैक करें कि कौन सी सेवाएं साझा घटकों का उपयोग करती हैं, टीमों को कहां कस्टम विकल्प बनाने पड़े (और क्यों), और क्या अपनाना बढ़ने पर अभिगम्यता अनुरूपता में सुधार होता है। स्थानीय वर्कअराउंड की उच्च दरें एक संकेत हैं कि सिस्टम में कुछ वास्तविक चीज़ की कमी है — उन्हें अवज्ञा के रूप में नहीं, बैकलॉग के रूप में मानें।

आपकी टीम के साथ चर्चा करने के लिए प्रश्न#

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

2. हमारे घटकों के अंदर अभिगम्यता और क्लिनिकल सुरक्षा वास्तव में कैसे सुनिश्चित की जाएगी — और इस पर हस्ताक्षर कौन करता है? यह दावा करना आसान है कि अभिगम्यता और सुरक्षा "शामिल" हैं; इसकी गारंटी देना कठिन है। यह प्रश्न आपको आश्वासन पाइपलाइन के बारे में ठोस होने के लिए मजबूर करता है: कौन हर घटक को WCAG के विरुद्ध परखता है, किन सहायक प्रौद्योगिकियों के साथ, और किन विकलांग उपयोगकर्ताओं के साथ; सुरक्षा-संबंधित व्यवहारों की आपकी क्लिनिकल सुरक्षा प्रक्रिया (DCB0129/DCB0160) के विरुद्ध कैसे समीक्षा की जाती है; और "पुनः उपयोग के लिए सुरक्षित" के रूप में प्रकाशित होने से पहले एक घटक के साथ कौन सा साक्ष्य जुड़ा है। बहस को ईमानदार अंतरालों को सामने लाना चाहिए — शायद आपके पास स्वचालित कंट्रास्ट जांच है लेकिन कभी वास्तविक स्क्रीन-रीडर उपयोगकर्ता के साथ परीक्षण नहीं किया, या आपके Clinical Safety Officer ने कभी साझा घटक लाइब्रेरी की समीक्षा नहीं की। एक मज़बूत उत्तर एक नामित स्वामी, एक परिभाषित परीक्षण व्यवस्था, और एक नियम उत्पन्न करता है कि कोई भी घटक दस्तावेज़ीकृत अभिगम्यता और सुरक्षा साक्ष्य के बिना साझा लाइब्रेरी में प्रवेश नहीं करता, क्योंकि पचास सेवाओं द्वारा विरासत में लिया गया एक दोष नुकसान का पचास गुना है।

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

4. अपस्ट्रीम NHS और GOV.UK सिस्टमों के साथ हमारा संबंध क्या है — और जैसे वे बदलते हैं हम उनके साथ कैसे कदम मिलाकर रहेंगे? एक राष्ट्रीय डिज़ाइन सिस्टम अपनाना एक बार का डाउनलोड नहीं है; यह उस बुनियादी ढांचे पर एक चल रही निर्भरता है जिसे आप नियंत्रित नहीं करते। यह प्रश्न आपको सोच-समझकर तय करने के लिए मजबूर करता है कि आप "हल्के थीम करें और अपस्ट्रीम को बारीकी से ट्रैक करें" से "फोर्क करें और अलग हों" के स्पेक्ट्रम पर कहां बैठते हैं। हर विकल्प की एक कीमत है: करीब रहने का अर्थ है किसी और की समय-सारणी पर अपस्ट्रीम परिवर्तनों (एक नई अभिगम्यता फिक्स, एक संशोधित पैटर्न) को अवशोषित करना और कभी-कभी स्थानीय अनुकूलनों को फिर से काम करना; फोर्किंग का अर्थ है कि आप हर भविष्य की अभिगम्यता और सुरक्षा फिक्स का स्वामित्व लेते हैं जो राष्ट्रीय टीम अन्यथा आपको मुफ़्त में देती। स्वास्थ्य और देखभाल में अलग होने का खिंचाव वास्तविक है — क्लिनिकल वर्कफ़्लो और स्थानीय ब्रांडिंग वास्तविक दबाव बनाते हैं — लेकिन हर भिन्नता एक स्थायी दायित्व है। एक अच्छा उत्तर नाम देता है कि अपस्ट्रीम रिलीज़ नोट्स कौन देखता है, स्थानीय एक्सटेंशन को कैसे संरचित किया जाता है ताकि वे एक अपस्ट्रीम अपडेट से बच सकें, और एक प्रस्तावित भिन्नता को अनुमति दिए जाने से पहले किस स्पष्ट परीक्षण को पास करना चाहिए, ताकि "हमें इसे अलग दिखने की आवश्यकता थी" कभी चुपचाप "हम अब NHS तारीख चुनने वाले का एक बासी, कम-अभिगम्य फोर्क बनाए रखते हैं" न बन जाए।

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

6. हमें कैसे पता चलेगा कि डिज़ाइन सिस्टम वास्तव में काम कर रहा है — और जब मीट्रिक असुविधाजनक हों तो हम क्या करेंगे? एक डिज़ाइन सिस्टम मौजूद हो सकता है, खूबसूरती से दस्तावेज़ीकृत हो सकता है, और फिर भी बहुत कम मूल्य दे सकता है अगर टीमें चुपचाप इसके आसपास रूट करती हैं। यह प्रश्न "हमारे पास एक डिज़ाइन सिस्टम है" से आगे "क्या यह अपनी जगह अर्जित कर रहा है" तक धकेलता है। तय करें कि आप क्या मापेंगे: सेवाओं में अपनाना, कस्टम वर्कअराउंड की दर और कारण, क्या अपनाना बढ़ने पर अभिगम्यता अनुरूपता वास्तव में बेहतर होती है, और फिर से बनाने के बजाय पुनः उपयोग करके टीमें कितना समय बचाती हैं। कठिन हिस्सा संख्याएं इकट्ठा करना नहीं बल्कि पहले से सहमत होना है कि आप उन्हें कैसे पढ़ेंगे — क्योंकि स्थानीय वर्कअराउंड की एक उच्च दर एक संकेत है कि साझा सिस्टम में कुछ वास्तविक चीज़ की कमी है, इसका साक्ष्य नहीं कि डिलीवरी टीमें अवज्ञाकारी हो रही हैं। एक अच्छा उत्तर असुविधाजनक अपनाने वाले डेटा को बैकलॉग और रोडमैप इनपुट के रूप में मानने के प्रति प्रतिबद्ध होता है, परिभाषित करता है कि इसकी समीक्षा कौन और कितनी बार करता है, और केवल चापलूसी करने वाली चीज़ (अस्तित्व, डाउनलोड गिनती) के बजाय मायने रखने वाली चीज़ (सुरक्षित, अधिक अभिगम्य, अधिक सुसंगत सेवाएं वास्तव में शिप की गईं) मापने के प्रलोभन का विरोध करता है।

व्यवहार में: एक स्वास्थ्य और देखभाल उदाहरण#

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

ICS एक छोटी, संयुक्त रूप से वित्तपोषित डिज़ाइन सिस्टम टीम खड़ी करता है। शुरू से बनाने के बजाय, वे NHS डिज़ाइन सिस्टम को अपनी नींव के रूप में अपनाते हैं और ICS-विशिष्ट ब्रांडिंग के लिए डिज़ाइन टोकन की एक पतली स्थानीय परत परिभाषित करते हैं, साथ ही वास्तव में स्थानीय पैटर्न की एक मुट्ठी (उदाहरण के लिए, दुभाषिया समर्थन बुकिंग के लिए एक साझा पैटर्न, जिसे कोई भी राष्ट्रीय सिस्टम कवर नहीं करता)। हर साझा घटक प्रकाशित होने से पहले दस्तावेज़ीकृत WCAG साक्ष्य और DCB0129 प्रक्रिया के तहत ICS Clinical Safety Officer का हस्ताक्षर रखता है।

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

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

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

स्टार्टअप#

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

छोटा व्यवसाय#

एक स्थापित छोटा प्रदाता — एक GP प्रैक्टिस, एक सामुदायिक फार्मेसी, एक केयर होम, या एक रोगी-सामना करने वाला उपकरण आयुक्त कर रहा एक एकल-साइट क्लिनिक — के पास लाइव रोगी हैं लेकिन कोई समर्पित डिज़ाइन या फ्रंट-एंड क्षमता नहीं, और कस्टम घटकों की लागत अवशोषित नहीं कर सकता। इसका सबसे शक्तिशाली कदम किसी भी आपूर्तिकर्ता पर NHS या GOV.UK फ्रंट-एंड पर बनाने के लिए ज़ोर देना है, ताकि अभिगम्यता और सुरक्षा गारंटी वादा किए जाने के बजाय विरासत में मिलें, और इसे एक आशा के बजाय अनुबंध की एक लिखित शर्त बनाना है। इसे शायद ही कभी अपना खुद का डिज़ाइन सिस्टम चलाने की आवश्यकता होती है; इसे एक को अच्छी तरह से उपभोग करने की आवश्यकता है, और यह पहचानने की कि एक आपूर्तिकर्ता का स्लिक डेमो एक अभिगम्य, सुनिश्चित लाइव सेवा का साक्ष्य नहीं है। जहां यह प्रोटोटाइप बनाता है — एक नए ऑनलाइन बुकिंग प्रवाह को अपने वास्तविक, अक्सर बड़े या कम डिजिटल रूप से आत्मविश्वासी रोगियों के साथ परखना — वास्तविक उपयोगकर्ताओं के साथ कुछ सत्र एक पॉलिश किए गए मॉकअप से कहीं अधिक पकड़ते हैं। वही वैधानिक अभिगम्यता और क्लिनिकल-सुरक्षा कर्तव्य एक बड़े ट्रस्ट के समान लागू होते हैं, इसलिए ईमानदार प्रश्न यह नहीं है कि अनुपालन करना है या नहीं बल्कि साझा राष्ट्रीय बुनियादी ढांचे से सस्ते में विरासत में मिला अनुपालन कैसे प्राप्त करें।

बड़ा संगठन#

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

सरकार#

NHS England या GDS जैसा एक राष्ट्रीय निकाय डिज़ाइन सिस्टम को सार्वजनिक बुनियादी ढांचे के रूप में संचालित करता है जिसका उपयोग वे संगठन करते हैं जिन्हें यह नियंत्रित नहीं करता, इसलिए खुलापन, स्थिरता, और पिछड़ी संगतता बहुत मायने रखते हैं। इसके दायित्व सबसे मज़बूत हैं: वैधानिक अभिगम्यता विनियम, समानता कर्तव्य, और यह वास्तविकता कि एक साझा राष्ट्रीय घटक में एक दोष लाखों नागरिकों तक फैलता है। काम आविष्कार के बारे में कम और प्रबंधन के बारे में अधिक है — स्पष्ट संस्करण, अप्रचलन नीति, विस्तृत अभिगम्यता साक्ष्य, और डाउनस्ट्रीम में सैकड़ों टीमों के प्रति प्रतिक्रियाशीलता। NHS डिज़ाइन सिस्टम और GOV.UK Design System ठीक संदर्भ उदाहरण हैं क्योंकि वे सिस्टम को एक दीर्घजीवी सार्वजनिक भलाई मानते हैं, एक परियोजना नहीं।

सामान्य विफलता मोड#

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

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

जांच-सूची#

• आपने NHS डिज़ाइन सिस्टम और/या GOV.UK Design System को शुरू से बनाने के बजाय अपनी नींव के रूप में अपनाया है।
• साझा घटक दस्तावेज़ीकृत WCAG अनुरूपता साक्ष्य रखते हैं, वास्तविक सहायक प्रौद्योगिकी और विकलांग उपयोगकर्ताओं के साथ परखे गए।
• सुरक्षा-संबंधित घटकों की पुनः उपयोग के लिए प्रकाशित होने से पहले आपकी क्लिनिकल सुरक्षा प्रक्रिया के तहत समीक्षा की गई है।
• डिज़ाइन टोकन रंग, स्पेसिंग, टाइपोग्राफी, और बातचीत स्थितियों को नियंत्रित करते हैं, एक जगह से सिस्टम-व्यापी परिवर्तन सक्षम करते हुए।
• एक एकल सत्य स्रोत है जहां कोडित घटक और उनका मार्गदर्शन एक साथ रहते और संस्करणित होते हैं।
• प्रोटोटाइप प्रश्न से निष्ठा में मेल खाते हैं, एक प्रतिनिधि उपयोगकर्ता नमूने के साथ परखे गए, और डिस्पोज़ेबल माने जाते हैं।
• बातचीत- और अभिगम्यता-महत्वपूर्ण प्रवाह कोड में प्रोटोटाइप किए जाते हैं, केवल एक डिज़ाइन उपकरण में नहीं।
• एक वित्तपोषित, नामित टीम डिज़ाइन सिस्टम को एक चल रहे उत्पाद के रूप में स्वामित्व में रखती है, एक रोडमैप और समर्थन चैनल के साथ।
• एक प्रकाशित योगदान और अपवाद प्रक्रिया डिलीवरी टीमों को नए घटक और पैटर्न प्रस्तावित करने देती है।
• अपनाना और गुणवत्ता मापी जाती है, और स्थानीय वर्कअराउंड की उच्च दरों को अवज्ञा नहीं, बैकलॉग माना जाता है।

मुख्य स्रोत#

• NHS डिज़ाइन सिस्टम — NHS England: NHS डिजिटल सेवाओं के लिए घटक, पैटर्न, शैलियां, और अभिगम्यता मार्गदर्शन।
• GOV.UK Design System — Government Digital Service: यूके सरकारी सेवाओं के लिए शैलियां, घटक, और पैटर्न।
• GOV.UK Service Manual — प्रोटोटाइपिंग और "एक प्रोटोटाइप बनाएं" — Government Digital Service: सीखने के लिए प्रोटोटाइपिंग और उपयोगकर्ताओं के साथ परीक्षण पर मार्गदर्शन।
• NHS Digital Service Standard — NHS England: वह मानक जिसके विरुद्ध साझा और सुसंगत सेवाओं का मूल्यांकन किया जाता है।
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative: अभिगम्यता अनुरूपता मानक।
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — यूके सरकार: सार्वजनिक क्षेत्र सेवाओं के लिए वैधानिक अभिगम्यता कर्तव्य।
• DCB0129 / DCB0160 क्लिनिकल जोखिम प्रबंधन मानक — NHS England: स्वास्थ्य IT सिस्टमों के निर्माण और तैनाती के लिए क्लिनिकल सुरक्षा मानक।
• Design Council Double Diamond — Design Council: डिस्कवरी और डिज़ाइन को आधार देने वाला खोज–परिभाषित–विकसित–दें मॉडल।

संदर्भ#

1. Design system — Wikipedia — https://en.wikipedia.org/wiki/Design_system
2. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
3. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
4. Usability testing — Wikipedia — https://en.wikipedia.org/wiki/Usability_testing
5. GOV.UK (and the GOV.UK Design System) — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
8. Component-based software engineering — Wikipedia — https://en.wikipedia.org/wiki/Component-based_software_engineering
9. Figma — Wikipedia — https://en.wikipedia.org/wiki/Figma
10. Front-end web development — Wikipedia — https://en.wikipedia.org/wiki/Front-end_web_development
11. NHS design system — NHS England — https://service-manual.nhs.uk/design-system
12. GOV.UK Design System — Government Digital Service — https://design-system.service.gov.uk/
13. Make a prototype — GOV.UK Service Manual — https://www.gov.uk/service-manual/design/making-prototypes
14. NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
15. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
16. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
17. Clinical Risk Management: its Application in the Manufacture of Health IT Systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation-for-clinical-risk-management-standards