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

जनवरी 2003

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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