डिज़ाइन और अनुसंधान

जनवरी 2003

(यह लेख NEPLS की शरद ऋतु 2002 की बैठक में एक मुख्य भाषण से लिया गया है।)

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

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

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

आज मैं जिस बारे में बात करने जा रहा हूँ वह यह है कि आपका लक्ष्य पीछे से कैसा दिखता है। जब आप प्रोग्रामिंग भाषाओं को एक शोध विषय के बजाय एक डिज़ाइन समस्या के रूप में मानते हैं तो आप क्या अलग करते हैं?

सबसे बड़ा अंतर यह है कि आप उपयोगकर्ता पर अधिक ध्यान केंद्रित करते हैं। डिज़ाइन यह पूछकर शुरू होता है कि यह किसके लिए है और उन्हें इससे क्या चाहिए? एक अच्छा वास्तुकार, उदाहरण के लिए, एक ऐसा डिज़ाइन बनाकर शुरुआत नहीं करता जिसे वह उपयोगकर्ताओं पर थोपता है, बल्कि इच्छित उपयोगकर्ताओं का अध्ययन करके और यह पता लगाकर कि उन्हें क्या चाहिए।

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

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

फिर भी, जो उपयोगकर्ता के लिए काम करता है उसे बनाना केवल वही बनाना नहीं है जो उपयोगकर्ता आपसे कहता है। उपयोगकर्ताओं को सभी विकल्पों के बारे में पता नहीं होता है, और वे अक्सर इस बारे में गलत होते हैं कि वे वास्तव में क्या चाहते हैं।

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

उपयोगकर्ता पर यह ध्यान एक प्रकार का स्वयंसिद्ध है जिससे अच्छे डिज़ाइन का अधिकांश अभ्यास प्राप्त किया जा सकता है, और जिसके चारों ओर अधिकांश डिज़ाइन मुद्दे केंद्रित होते हैं।

यदि अच्छे डिज़ाइन को वह करना है जो उपयोगकर्ता को चाहिए, तो उपयोगकर्ता कौन है? जब मैं कहता हूँ कि डिज़ाइन उपयोगकर्ताओं के लिए होना चाहिए, तो मेरा यह तात्पर्य नहीं है कि अच्छे डिज़ाइन का लक्ष्य किसी प्रकार का न्यूनतम सामान्य भाजक है। आप किसी भी उपयोगकर्ता समूह को चुन सकते हैं जिसे आप चाहते हैं। यदि आप एक उपकरण डिज़ाइन कर रहे हैं, उदाहरण के लिए, आप इसे शुरुआती से लेकर विशेषज्ञों तक किसी के लिए भी डिज़ाइन कर सकते हैं, और जो एक समूह के लिए अच्छा डिज़ाइन है वह दूसरे के लिए बुरा हो सकता है। बात यह है कि आपको कुछ उपयोगकर्ता समूह चुनना होगा। मुझे नहीं लगता कि आप किसी इच्छित उपयोगकर्ता के संदर्भ के बिना अच्छे या बुरे डिज़ाइन के बारे में बात भी कर सकते हैं।

आपको अच्छा डिज़ाइन मिलने की सबसे अधिक संभावना है यदि इच्छित उपयोगकर्ताओं में स्वयं डिज़ाइनर शामिल हो। जब आप अपने अलावा किसी समूह के लिए कुछ डिज़ाइन करते हैं, तो यह उन लोगों के लिए होता है जिन्हें आप अपने से कम परिष्कृत मानते हैं, न कि अधिक परिष्कृत।

यह एक समस्या है, क्योंकि उपयोगकर्ता को नीचा दिखाना, चाहे वह कितनी भी दयालुता से क्यों न हो, अनिवार्य रूप से डिज़ाइनर को भ्रष्ट करता है। मुझे संदेह है कि अमेरिका में बहुत कम आवास परियोजनाओं को उन वास्तुकारों द्वारा डिज़ाइन किया गया था जो उनमें रहने की उम्मीद करते थे। आप प्रोग्रामिंग भाषाओं में भी यही देख सकते हैं। C, Lisp, और Smalltalk अपने डिजाइनरों के उपयोग के लिए बनाए गए थे। Cobol, Ada, और Java, अन्य लोगों के उपयोग के लिए बनाए गए थे।

यदि आप सोचते हैं कि आप मूर्खों के लिए कुछ डिज़ाइन कर रहे हैं, तो संभावना है कि आप कुछ अच्छा डिज़ाइन नहीं कर रहे हैं, यहाँ तक कि मूर्खों के लिए भी नहीं।

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

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

पसंद हो या न हो, प्रोग्रामिंग भाषाएं भी लोगों के लिए होती हैं, और मुझे संदेह है कि मानव मस्तिष्क मानव शरीर की तरह ही गांठदार और विलक्षण है। कुछ विचार लोगों के लिए समझना आसान है और कुछ नहीं। उदाहरण के लिए, हमारे पास विवरण से निपटने की बहुत सीमित क्षमता प्रतीत होती है। यही वह तथ्य है जो प्रोग्रामिंग भाषाओं को पहली जगह में एक अच्छा विचार बनाता है; यदि हम विवरण को संभाल सकते, तो हम मशीन भाषा में प्रोग्राम कर सकते थे।

यह भी याद रखें कि भाषाएं मुख्य रूप से तैयार कार्यक्रमों के लिए एक रूप नहीं हैं, बल्कि कुछ ऐसा हैं जिनमें कार्यक्रमों को विकसित किया जाना है। कलाओं में कोई भी आपको बता सकता है कि आप दो स्थितियों के लिए अलग-अलग माध्यम चाहते होंगे। उदाहरण के लिए, संगमरमर तैयार विचारों के लिए एक अच्छा, टिकाऊ माध्यम है, लेकिन नए विचारों को विकसित करने के लिए एक निराशाजनक रूप से अनम्य माध्यम है।

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

हम अक्सर ऐसा व्यवहार करते हैं जैसे कि किसी भाषा का परीक्षण यह है कि उसमें तैयार प्रोग्राम कितने अच्छे दिखते हैं। जब आप एक ही प्रोग्राम को दो भाषाओं में लिखा हुआ देखते हैं, और एक संस्करण बहुत छोटा होता है, तो यह बहुत आश्वस्त करने वाला लगता है। जब आप समस्या को कला की दिशा से देखते हैं, तो आप इस तरह के परीक्षण पर कम निर्भर होने की संभावना रखते हैं। आप एक प्रोग्रामिंग भाषा नहीं चाहते हैं जो संगमरमर की तरह हो।

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

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

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

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

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

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

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

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

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

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

मनोबल एक और कारण है कि किसी अनुभवहीन उपयोगकर्ता के लिए कुछ डिज़ाइन करना कठिन है। ऐसी चीज़ में रुचि बनाए रखना कठिन है जो आपको स्वयं पसंद नहीं है। कुछ अच्छा बनाने के लिए, आपको यह सोचना होगा, "वाह, यह वास्तव में बहुत बढ़िया है," न कि "क्या बकवास है; वे मूर्ख इसे पसंद करेंगे।"

डिज़ाइन का मतलब मनुष्यों के लिए चीजें बनाना है। लेकिन यह सिर्फ उपयोगकर्ता ही नहीं है जो मानव है। डिज़ाइनर भी मानव है।

ध्यान दें कि इस पूरे समय मैं "डिज़ाइनर" के बारे में बात कर रहा हूँ। डिज़ाइन को आमतौर पर किसी एक व्यक्ति के नियंत्रण में होना चाहिए ताकि वह अच्छा हो सके। फिर भी, ऐसा लगता है कि कई लोगों के लिए एक शोध परियोजना पर सहयोग करना संभव है। यह मुझे शोध और डिज़ाइन के बीच सबसे दिलचस्प अंतरों में से एक लगता है।

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

मैं यह नहीं कह रहा हूँ कि अच्छे डिज़ाइन के लिए एक व्यक्ति को सब कुछ सोचना पड़ता है। किसी ऐसे व्यक्ति की सलाह से अधिक मूल्यवान कुछ भी नहीं है जिसके निर्णय पर आप भरोसा करते हैं। लेकिन बात खत्म होने के बाद, क्या करना है इसका निर्णय एक व्यक्ति के पास होना चाहिए।

ऐसा क्यों है कि शोध सहयोगियों द्वारा किया जा सकता है और डिज़ाइन नहीं? यह एक दिलचस्प सवाल है। मुझे इसका जवाब नहीं पता। शायद, यदि डिज़ाइन और शोध अभिसरण करते हैं, तो सबसे अच्छा शोध भी अच्छा डिज़ाइन है, और वास्तव में सहयोगियों द्वारा नहीं किया जा सकता है। कई सबसे प्रसिद्ध वैज्ञानिकों ने अकेले काम किया है। लेकिन मुझे यह कहने के लिए पर्याप्त नहीं पता कि क्या यहाँ कोई पैटर्न है। यह सिर्फ इतना हो सकता है कि कई प्रसिद्ध वैज्ञानिकों ने तब काम किया जब सहयोग कम आम था।

विज्ञान में कहानी जो भी हो, कलाओं में सच्चा सहयोग दुर्लभ लगता है। समिति द्वारा डिज़ाइन खराब डिज़ाइन का पर्याय है। ऐसा क्यों है? क्या इस सीमा को पार करने का कोई तरीका है?

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

संबंधित: