मुख्य सामग्री पर जाएं
DataCamp में जीवन

डिज़ाइन सिस्टम को समझना

DataCamp में, हम डिज़ाइन करने के अधिक स्केलेबल तरीके की ओर काम कर रहे हैं। इस पोस्ट में डिज़ाइन सिस्टम के बारे में पढ़ें और जानें कि हम अपने सिस्टम को कैसे समझने की कोशिश कर रहे हैं!
Kristof For Goran's photo
Kristof For Goran
अपडेट किया गया · 6 मि॰ पढ़ें

AI के साथ खोजें

ChatGPTClaudePerplexity

अपना निःशुल्क खाता बनाएँ

अभ्यास और ट्रैक अपनी प्रगति को।

Google के साथ जारी रखें
जारी रखने पर, आप हमारी उपयोग की शर्तें, हमारी गोपनीयता नीति को स्वीकार करते हैं और यह भी कि आपका डेटा संयुक्त राज्य अमेरिका में संग्रहीत किया जाता है।

DataCamp में हमारा मिशन है कि हर किसी के लिए डेटा साइंस शिक्षा को सुलभ बनाया जाए, और दुनिया भर में 20 लाख से अधिक छात्रों के साथ हम तेज़ी से आगे बढ़ रहे हैं। इस गति से बढ़ना कंपनी के सभी लोगों से काफी प्रयास मांगता है और कई नए, रोमांचक चुनौती भी लाता है।

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

यह लेख बताता है कि हम डिज़ाइन सिस्टम को समझना कैसे शुरू कर रहे हैं।

डिज़ाइन सिस्टम क्या है?

डिज़ाइन सिस्टम उन सभी घटकों को एक साथ लाता है जो किसी डिज़ाइन समाधान को वितरित और दोहराने के लिए आवश्यक होते हैं। यह कोई नई या केवल डिजिटल प्रोडक्ट डिज़ाइन तक सीमित चीज़ नहीं है — इतिहास में इसके कई उदाहरण मिलते हैं।

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

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

हमें डिज़ाइन सिस्टम क्यों रखना चाहिए?

जब हर पेज अलग-थलग डिज़ाइन किया जाता है, तो कई घटकों की डुप्लिकेट कॉपी या मिलते-जुलते विकल्प बन जाते हैं। इससे डिजिटल प्रोडक्ट उपयोगकर्ताओं के लिए समझना और इंजीनियरिंग के लिए मेंटेन करना मुश्किल हो जाता है। DataCamp में, हमने अपने प्रोडक्ट में 20 से अधिक अलग-अलग बटन खोजे, जिनमें से हर एक की अपनी विशेषताएँ थीं (अलग होवर स्टेट, असंगत डिसेबल्ड स्टेट, आदि)। किसी तेज़ी से बढ़ते प्रोडक्ट में इन सबका हिसाब रखना कठिन होता है और मेंटेन करना लगभग नामुमकिन। यहीं पर डिज़ाइन सिस्टम काम आता है।

किसी डिजिटल प्रोडक्ट के लिए, डिज़ाइन सिस्टम उन यूज़र इंटरफ़ेस घटकों का वर्णन करता है जिनकी मदद से एक ऐसा इंटरफ़ेस बनाया जा सकता है जो समस्या का समाधान करे और उपयोगकर्ता के लिए एक सुसंगत अनुभव दे।

अगर डिज़ाइन सिस्टम को अच्छी तरह लागू किया जाए तो इसका प्रभाव श्रृंखलाबद्ध रूप से यह करेगा …

  • गलतफहमी कम करेगा
  • इम्प्लीमेंटेशन समय कम करेगा
  • मेंटेनेंस का काम कम करेगा
  • बग्स कम करेगा
  • सपोर्ट टिकट्स कम करेगा
  • गुणवत्ता बढ़ाएगा
  • दक्षता बढ़ाएगा
  • दीर्घायु बढ़ाएगा
  • सीखने-योग्यता बढ़ाएगा
  • उपयोगिता बढ़ाएगा
  • अभिगम्यता बढ़ाएगा
  • नवाचार बढ़ाएगा
  • फोकस बढ़ाएगा
  • बिक्री बढ़ाएगा

यह आसान नहीं है …

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

DataCamp में डिज़ाइन सिस्टम 101

1. घटक इन्वेंटरी बनाएं

लक्ष्य: सुनिश्चित करें कि हर कोई किसी घटक के अस्तित्व और स्थिति से परिचित हो।

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

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

2. नामकरण मानक अपनाएं

लक्ष्य: डिज़ाइन और इंजीनियरिंग के बीच गलतफहमी से बचना।

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

3. डिज़ाइन वर्कफ़्लो का अनुकूलन

लक्ष्य: काम खोने से बचना और पारदर्शी वर्कफ़्लो रखना।

डिज़ाइन टीम के रूप में साथ काम करने की अपनी चुनौतियाँ होती हैं। हम डिज़ाइन को Dropbox में रखते थे, लेकिन जब हमारी टीम बढ़ने लगी, तो काम खोने का जोखिम और बदलावों पर नज़र रखने का प्रयास बहुत बढ़ गया।

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

4. बेहतर डाक्यूमेंटेशन + ऑनबोर्डिंग

लक्ष्य: कर्मचारियों का तेज़ ऑनबोर्डिंग और अनावश्यक संचार से बचाव।

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

5. डिज़ाइन रिव्यू

लक्ष्य: डिज़ाइन और इंजीनियरिंग के बीच अपेक्षाएँ तय करना।

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

निष्कर्ष

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

हम यह जानने के इच्छुक हैं कि अन्य संगठन डिज़ाइन सिस्टम को कैसे समझते हैं। अगर आप अपना अनुभव साझा करना चाहें तो मुझे ईमेल करें।

DataCamp में हम हमेशा प्रतिभाशाली लोगों की तलाश में रहते हैं। रुचि है? हमारी खुली पदों की सूची देखें।

विषय
DataCamp में जीवन