डिज़ाइन सिस्टम की सफलता और विफलता पर 6 सवाल

इन दिनों डिज़ाइन सिस्टम की शुरुआती डिज़ाइन में भाग लेते हुए काफी सोच-विचार चल रहा है.

इसी से जुड़ा UX Collective का एक लेख पिछले हफ्ते पढ़ा था. कंपनी के भीतर डिज़ाइन सिस्टम के सदस्यों के लिए इसका अनुवाद किया था, तो लगा इसे यहां भी साझा करूं.

कहा गया है कि यह डिज़ाइन सिस्टम पर काम करने वाले 10 डिज़ाइनरों के इंटरव्यू का संक्षिप्त सार है.

सवाल 1. DS भूमिका में विफल होने के लिए क्या करें?:

• पुलिस बन जाएं

• डिज़ाइनर की ताकत का इस्तेमाल करें (राजनीति की बात)

• कंपोनेंट्स को एकीकृत तो करें, लेकिन उनका उपयोग न करें

• टीम की आवश्यकताओं का अनुमान लगाने के बजाय बाद में प्रतिक्रिया देने वाले ढंग से काम करें

• उपयोगकर्ताओं (अन्य डिज़ाइनर या डेवलपर) की आवाज़ न सुनें और न ही रिसर्च करें

• DS के लिए बनाया गया DS

• काम के लिए स्पष्ट roadmap और process बनाए न रखें

• ऐसा आदर्श अनुभव बनाएं जिसे लागू ही न किया जा सके

• टीम के साथ टेस्ट न करें

• DS को एक product की तरह न समझें

• tools तो बनाएं, लेकिन लोगों को उनका उपयोग करना न सिखाएं

• वास्तविक काम करने के तरीकों से अलग बहुत ज़्यादा सिद्धांत ले आएं

• सोचें कि यह काम आप अकेले कर सकते हैं

• tech टीम के किसी व्यक्ति के साथ knowledge sharing पर 100% फोकस न करें

• बहुत कम flexible कंपोनेंट्स बनाएं और detaching की अनुमति न दें

• मदद न मांगें और लोगों से जुड़ें भी नहीं (चाहे अंदर हो या बाहर)

• बिल्कुल पास रहकर साथ काम करने के बजाय दूर से नियम थोपें

सवाल 2. DS की सफलता के लिए कौन-सी soft skills ज़रूरी हैं?

• communication, communication, communication!!!

• उपयोगकर्ताओं के साथ रहना, सुनना, पूछना और रिसर्च करना बेहद महत्वपूर्ण है.

• अपनी विफलताओं को विनम्रता से स्वीकार करें

• धैर्य रखें

• सुरक्षित माहौल बनाने की क्षमता

• सिखाना

• reuse के तरीकों पर एक व्यवस्थित vision प्रस्तुत करना

• scale होने पर भी दृढ़ता के साथ consistency बनाए रखनी चाहिए

• सामने वाले को समझते समय ज़रूरत से ज़्यादा भावनात्मक रूप से जुड़ने की आवश्यकता नहीं है. नियमों को जैसे हैं वैसे स्वीकार करें.

• 95% hard skills हैं और 5% soft skills उन स्थितियों के लिए हैं जब नियमों से बाहर जाना पड़े.

• लोगों की growth को बढ़ावा दें और उसे साझा करें

• autonomy

• product (DS) को लगातार बेचते रहें

• रणनीतिक रूप से सोचें

• सभी लोगों को भाग लेने दें

• DS के बारे में शोर पैदा करें

• जितना संभव हो उतना समय लगाकर जितने संभव हों उतने scenarios खोजें

• भाषा को एक जैसा करें.

सवाल 3. क्या DS का संचालन अधिक centralised होना चाहिए या अधिक distributed?

दो तरीके होते हैं: एक centralised team जो देखती है कि लोग कैसे डिज़ाइन कर रहे हैं और उसकी ज़िम्मेदारी लेती है, और दूसरा तरीका जिसमें हर कोई उसकी ज़िम्मेदारी लेता है. लोगों से पूछा गया कि इनमें से कौन-सा विकल्प सही होगा.

• हमारी टीम बहुत ज़्यादा centralised है, इसलिए bottleneck बनता है. लेकिन distributed model में ownership कमज़ोर पड़ने की समस्या भी हो सकती है.

• हमारे पास 100 से अधिक लोगों की डिज़ाइनर टीम है जो DS को centralise करने के लिए काम करती है.

• लोग जो alpha libraries बनाते हैं, हम उनके साथ सहयोग करते हैं और वहीं से DS टीम का backlog बनाते हैं.

• हम लोगों को स्वेच्छा से कंपोनेंट्स बनाने के लिए प्रशिक्षित करते हैं.

• centralise करना है या नहीं, यह काफ़ी हद तक political issue है. इसे तय करने से पहले यह ठीक से समझना चाहिए कि कितनी scalability चाहिए.

• expectations को align करना होगा और लोगों को DS बनाने में शामिल करना होगा.

• हम सहयोग करना चाहते थे, लेकिन तरीका नहीं जानते थे, इसलिए process बनाया. (Culture vs Process)

• शुरुआत में delivery के लिए अपेक्षाकृत कम collaborative होना पड़ सकता है. maturity आने पर इसे और collaborative बनाया जा सकता है.

• अब हम उस चरण में पहुंच गए हैं जहां इसे decentralise करना चाहिए; लोगों को contribution करना सिखाना होगा.

• अगर आप लोगों को प्रशिक्षित नहीं करेंगे, तो वे contribution नहीं करेंगे.

• जब डिज़ाइनर standard से आगे बढ़कर बेहतर output बनाना चाहें, तब साथ ही यह भी सोच पाना चाहिए कि उसे standardise कैसे किया जाए.

• DS को 1~2 लोग मिलकर नहीं कर सकते. क्योंकि यह system बनाने का काम है, इसलिए DS की शुरुआत squad स्तर से होनी चाहिए.

• यह टीम के आकार पर बहुत निर्भर करता है; कभी-कभी DS टीम core components के development पर ध्यान दे सकती है और दूसरे ambassadors उसे फैलाते हैं.

-आख़िरकार हम एक centralised team हैं, लेकिन ambassadors के साथ collaborative तरीके से काम करते हैं. अंतिम निर्णय DS टीम ही लेती है.

4. क्या आप DS को अधिक विस्तृत और सीमित बनाने वाले नियमों के रूप में देखते हैं? या इसे अधिक व्यापक और ऐसा खुला ढांचा मानते हैं जो डिज़ाइनरों को नए layouts बनाने की आज़ादी देता है?

बंद या खुला? अगर आप डिज़ाइन सिस्टम का काम करते हैं, तो यह सवाल निश्चित ही आपको रुचिकर लगेगा. मुझे भी लगा, इसलिए मैंने लोगों से यह पूछा.

• "accessibility" से जुड़ी चीज़ों में अधिक restrictive approach रखें

• हमने सबने एक बुनियादी संरचना से शुरुआत की, लेकिन कुछ inconsistencies बनने लगीं. इसलिए हमने तय किया कि हम 100% बंद नहीं होंगे, लेकिन कुछ constraints ज़रूर रखेंगे. साथ ही हम हमेशा यह खोजने की कोशिश करते हैं कि डिज़ाइनर को बदले में कुछ कैसे लौटाया जाए

• यह context पर निर्भर करता है, इसलिए पहले risk मापें और फिर निर्णय लें. आम तौर पर छोटी टीम = अधिक flexibility

• बात सिर्फ creative होकर नए कंपोनेंट्स बनाने की नहीं है. ऐसे कंपोनेंट्स चाहिए जो लोगों की ज़रूरतों के हिसाब से ढल सकें

• DS एक business है. कंपोनेंट्स जितने कम हों, उतना बेहतर.

• लोगों को DS का उपयोग करना अच्छा लगना चाहिए. ऊपर से देखने पर यह uniform जैसा लग सकता है, इसलिए यह सोचना आसान है कि flexibility की ज़रूरत नहीं होगी (लेकिन ऐसा नहीं है)

• शुरुआत से ही बहुत restrictive नहीं हुआ जा सकता. पर्याप्त समय बीतने पर यह कुछ patterns वगैरह की दिशा में evolve करना शुरू कर सकता है.

• कंपनी में नए शामिल होने वाले डिज़ाइनरों के लिए अधिक constraints मददगार हो सकते हैं. नियम तोड़ने के लिए पहले नियमों से शुरुआत करनी पड़ती है.

• हम लोगों को इतना material देते हैं कि वे अपनी खुद की recipes बना सकें.

• यह टीम की maturity पर निर्भर करता है. अगर juniors ज़्यादा हों, तो वे कम दस्तावेज़ समझ पाते हैं, इसलिए ज़्यादा design guidance मांगते हैं. इससे training की ज़रूरत बढ़ती है, लेकिन फिर भी हम कोशिश करते हैं कि उन्हें बांधकर न रखा जाए और वे स्वतंत्र रूप से काम कर सकें. सबसे बड़ी चुनौती लोगों को दस्तावेज़ वास्तव में पढ़ने और उपयोग करने के लिए प्रेरित करना है, इसलिए संभव है कि इसे Figma जैसे डिज़ाइनर के और निकट स्थानों तक लाया जाए.

• अगर बात accessibility और aesthetics की है, तो अधिक restrictive होना चाहिए.

• tokens consistency बनाए रखने में महत्वपूर्ण हैं.

• अच्छे दस्तावेज़ लोगों के साथ तालमेल और उन्हें स्वतंत्रता देने के बीच संतुलन बनाते हैं.

सवाल 5. branding और marketing से जुड़े DS के बारे में आप क्या सोचते हैं?

(यह मेरा परिचित क्षेत्र नहीं है, इसलिए इसका अनुवाद थोड़ा कठिन था.)

मैं समझता हूं कि डिज़ाइन सिस्टम का केंद्र अंततः digital products होने चाहिए, लेकिन चूंकि product सबसे महत्वपूर्ण brand platforms में से एक हो सकता है, इसलिए मैं जानना चाहता था कि लोग इस संबंध को कैसे देखते हैं.

• DS से जुड़ी branding के बारे में सोचने का एक तरीका यह है कि उल्टा यह देखें कि उसका DS पर क्या प्रभाव पड़ता है.

• हमने brand के look and feel को align करने के लिए डिज़ाइन सिस्टम को brand के अनुरूप बनाना शुरू किया.

• DS scalability और brand ID, दोनों के लिए है, लेकिन इनके बीच का संबंध branding team पर निर्भर करता है.

• Since DS is a language, MKT could support with assets for it;

• branding team को बुनियादी नियम बनाने के लिए शुरुआत से ही DS में शामिल होना चाहिए.

• यह कंपनी पर निर्भर करता है. DS brand को मज़बूत करने का एक tool है, इसलिए alignment महत्वपूर्ण है. इन दो क्षेत्रों के बीच का संबंध DS की accessibility को भी प्रभावित करता है.

• strategy को align करने के लिए branding team के साथ sync करने का तरीका खोजना महत्वपूर्ण है.

• They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;

• कभी-कभी documentation और system को साथ में इस्तेमाल किया जा सकता है, लेकिन अधिकतर मामलों में ऐसा नहीं होता. DS interface है. brand team के पास अलग "branding system" होता है और आम तौर पर libraries के बीच interaction होता है. दोनों पूरी तरह एक जैसे नहीं होते.

सवाल 6. DS की सफलता को कैसे मापा जा सकता है?

• engagement, adoption और टीम की स्थिति को समझने के लिए perception survey

• component coverage (DS कितना उपयोग हो रहा है बनाम कितना hardcoded है)

• Adoption

• Time to market

• ROI

• Figma Analytics

• development teams की प्रतिक्रिया

• accessibility

• कंपोनेंट्स कितनी बार उपयोग हुए

[xguru]

वाह, बढ़िया है। संकलित करने के लिए धन्यवाद!