डिजाइन और शोध

जनवरी 2003

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर आपको लगता है कि आप बेवकूफों के लिए कुछ डिजाइन कर रहे हैं, तो संभावना है कि आप बेवकूफों के लिए भी कुछ अच्छा डिजाइन नहीं कर रहे हैं।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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