डिज़ाइन प्रोसेस मरा नहीं है, बस संकुचित हुआ है

• AI डिज़ाइन काम की गति बढ़ा रहा है, इसलिए "प्रोसेस को छोड़ दो" जैसी दलीलें फैल रही हैं, लेकिन यह कुशल डिज़ाइनरों के काम करने के तरीके की गलत समझ का नतीजा है
• जब अनुभवी डिज़ाइनर कहते हैं कि उन्होंने "बस बनाना शुरू कर दिया", तो असल में वे वर्षों के संचित अनुभव के आधार पर प्रोसेस को भीतर समाहित कर उसे संकुचित रूप में लागू कर रहे होते हैं
• अंतर्ज्ञान पर निर्भर तरीका कम अनुभव वाले जूनियर प्रैक्टिशनरों पर आसानी से लागू नहीं होता, और regulated industries में प्रोसेस नुकसान से बचाने वाली सुरक्षा व्यवस्था की भूमिका निभाता है
• solution-first डिज़ाइन केवल संकीर्ण संदर्भों में प्रभावी है, जहाँ product patterns अच्छी तरह स्थापित हों, और इसमें केवल सफल उदाहरणों को उभारने वाले survivorship bias का जोखिम रहता है
• आधुनिक डिज़ाइन की मुख्य क्षमता प्रोसेस को छोड़ना नहीं, बल्कि समस्या के अनुसार सही approach को जानबूझकर चुनने वाली process literacy है

---

"प्रोसेस को छोड़ दो" दावे का मतलब

• यह दावा कि पारंपरिक डिज़ाइन प्रोसेस पुराना हो चुका है और अच्छे नतीजे वास्तव में जिस तरह बनते हैं, उससे कटा हुआ है
• iteration, intuition, और steps को skip करना कमजोरी नहीं बल्कि ताकत है; इसलिए मज़बूत intuition बनाना, details पर गहराई से ध्यान देना, और स्थिति के अनुसार प्रोसेस को remix करना चाहिए
• बेहतरीन काम अक्सर problem definition से नहीं बल्कि solution से शुरू होता है, और कई बार किसी प्रभावशाली prototype को देखने के बाद ही समझ आता है कि वह असल में कौन-सी समस्या हल कर रहा है
• Anthropic की design lead Jenny Wen इस दावे की प्रमुख आवाज़ों में से एक हैं

जहाँ यह दावा टूटता है

• ऊपर की बातें पूरी तरह गलत नहीं हैं, लेकिन वे यह साबित नहीं करतीं कि प्रोसेस अनावश्यक है
• वे बस उसी चीज़ का वर्णन करती हैं जो अनुभवी डिज़ाइनर पहले से कर रहे हैं: यानी प्रोसेस को भीतर समाहित कर exploration, ideation, और evaluation के चरणों के बीच लचीले ढंग से आना-जाना
• जो चीज़ "प्रोसेस को skip करना" लगती है, वह असल में प्रोसेस को compress करना है — अनुभव के सहारे हर चरण से तेज़ी से गुजरना
• Double Diamond और Design Thinking प्रोसेस कोई शाब्दिक checklist या template नहीं हैं
  • इनका उद्देश्य risk management है: टीम समस्या को समझे, solutions को explore करे, और गलत चीज़ बनाने की संभावना घटे
• solution-first approach तभी प्रभावी होती है जब problem space mature हो, अंतर्निहित ज्ञान पर्याप्त हो, और लक्ष्य कुछ बिल्कुल नया गढ़ना नहीं बल्कि स्थापित patterns पर निर्माण करना हो

प्रोसेस का संकुचन, त्याग नहीं

• "डिज़ाइन प्रोसेस" को एक ही विशाल इकाई की तरह देखना ही समस्या है
• Double Diamond या Design Thinking cycle "वही प्रोसेस" नहीं, बल्कि creative problem-solving process के चरणों का सरल रूप हैं
  • क्या गलत है समझना → क्या बनाना है तय करना → बनाना → सीखना, इसका एक high-level वर्णन
• "प्रोसेस को छोड़ दो" वाला दावा काफी हद तक human-centered design के वास्तविक कामकाज की भ्रामक तस्वीर पर टिका है
  • अनुभवी प्रैक्टिशनर प्रोसेस को non-linear और context के हिसाब से चलाते हैं
  • औपचारिक frameworks इसलिए मौजूद हैं ताकि सोचने का तरीका अधिक सुलभ और साझा करने योग्य बन सके
• जब mature consumer products पर काम करने वाला अनुभवी डिज़ाइनर कहता है कि उसने "बस बनाना शुरू कर दिया", तो उसने प्रोसेस छोड़ा नहीं होता, बल्कि उसके भीतर समाहित संस्करण को संकुचित रूप में लागू किया होता है
  • इसका आधार user behavior research, competitor trends analysis, और कुशल टीमों के साथ किए गए research से संचित ज्ञान होता है
• जिसे "intuition" कहा जाता है, वह दरअसल वर्षों के काम से संकुचित और भीतर समाहित हुआ प्रोसेस होता है
  • जिस intuition पर डिज़ाइनर भरोसा करता है, उसे उसी प्रोसेस ने बनाया होता है जिसे वह नज़रअंदाज़ करने का दावा कर रहा होता है
• AI tools इस संकुचन को और तेज़ करते हैं और लोकतांत्रिक बनाते हैं
  • Vibecoding ideas और testable output के बीच का फ़ासला घटाता है
  • exploration, creation, learning, और improvement एक ही दोपहर में संभव हो सकते हैं
  • अगर अनुभवी डिज़ाइनर हमेशा औपचारिक frameworks से तेज़ डिज़ाइन loop चलाते आए हैं, तो AI अब कम अनुभवी प्रैक्टिशनरों को भी ऐसा करने की क्षमता दे रहा है

intuition प्रोसेस की जगह नहीं ले सकती

• डिज़ाइन प्रोसेस में intuition को अपनाने की सलाह सुनने में मुक्तिदायक लग सकती है, लेकिन यह जटिल वास्तविकता को जरूरत से ज़्यादा सरल बना देती है

हर कोई intuition के सहारे काम नहीं कर सकता

• Jenny Wen जैसी अनुभवी डिज़ाइनर ने मज़बूत डिज़ाइन संस्कृति और उच्च-स्तरीय टीमों वाली कंपनियों में वर्षों के काम से अपनी intuition विकसित की है
  • उनके पास intuition-driven निर्णयों का नेतृत्व करने के लिए skill, authority, track record, और team maturity है
• जिन junior practitioners ने अभी वह ज्ञान संचित नहीं किया जिससे intuition भरोसेमंद बनती है, उनके लिए intuition पर निर्भरता बहुत कम प्रभावी होती है
  • एक अनुभवी डिज़ाइनर का तेज़ और informed judgment देना, और किसी नए व्यक्ति से जो organizational knowledge, user behavior patterns, और business constraints से अभी परिचित नहीं है, "खुद पर भरोसा करो" कहना — ये बिल्कुल अलग बातें हैं

intuition में जवाबदेही की कमी होती है

• कई environments में निर्णयों के लिए documentation और justification की ज़रूरत होती है
  • research findings, usability test results, और analytics data जैसे process outputs stakeholder alignment और approvals के लिए आवश्यक होते हैं
• अधिकांश corporate environments में "मैंने intuition फॉलो की" जैसी व्याख्या तब टिक नहीं पाती जब कोई VP पूछे, "इसे support करने वाला evidence क्या है?"

अत्यधिक regulated industries में intuition काम नहीं करती

• healthcare, finance, government, और accessibility-critical systems जैसी high-risk या regulated industries में प्रोसेस कोई bureaucratic रस्म नहीं, बल्कि नुकसान रोकने की सुरक्षा व्यवस्था है
• medical device UI में research skip करना और whiteboard feature में research skip करना, दोनों एक ही स्तर की बात नहीं हैं

intuition में bias अंतर्निहित होता है

• अच्छी तरह विकसित intuition में भी blind spots होते हैं
  • अनुभवी डिज़ाइनर अनजाने में परिचित patterns में फँस सकते हैं या ऐसे edge cases को नज़रअंदाज़ कर सकते हैं जो उनके mental model में फिट नहीं बैठते
• intuition जितनी गहरी होती है, bias पहचानना उतना ही कठिन हो जाता है
• प्रोसेस assumptions को खुले में लाने के लिए मजबूर करता है, इससे पहले कि वे महँगी गलतियों में बदल जाएँ

solution-first डिज़ाइन केवल सीमित संदर्भ में मान्य है

• AI युग में कई विशेषज्ञ solution-first design का समर्थन कर रहे हैं — ऐसा approach जो नई technical capabilities से शुरू होकर पीछे की ओर यह समझता है कि वे कौन-सी समस्याएँ हल कर सकती हैं
  • यह पहले समस्या समझने और फिर solution खोजने वाले पारंपरिक मॉडल का उल्टा है
• Jenny Wen ने solution-first design के समर्थन में जिन उदाहरणों का उपयोग किया — संसाधन-समृद्ध कंपनियों द्वारा बनाए गए AI products की सफल और व्यापक रूप से अपनाई गई features — वे survivorship bias को दर्शाते हैं
  • जो दिखाई नहीं देता, वह है असफल solution-first experiments की बड़ी संख्या: ऐसे prototypes जिन्होंने internal teams को उत्साहित किया लेकिन users से जुड़ाव नहीं बनाया, या वे features जिन्हें launch के बाद कम adoption मिला क्योंकि वे किसी सार्थक ज़रूरत को पूरा नहीं कर पाईं
  • जब आप केवल success stories दिखाते हैं, तो कोई भी approach शानदार लग सकती है
• उभरती तकनीकों के लिए तेज़ implementation ज़रूरी है, लेकिन execution की गति उचित problem framing के महत्व को कम नहीं करती
  • भले ही औपचारिक problem statement या discovery sprint की ज़रूरत न हो, फिर भी यह जानना ज़रूरी है कि आप क्या ठीक करना चाहते हैं
• solution-first design risk को कम नहीं करती और उद्योग के सीमित हिस्से में ही उपयुक्त है
  • यह वहाँ सफल हो सकती है जहाँ product patterns पहले से समझे जा चुके हों, users परिपक्व हों, और डिज़ाइन challenge केवल differentiation तक सीमित हो
  • यह उच्च organizational और UX maturity को मानकर चलती है — ऐसी टीमों को जिनके पास मज़बूत domain knowledge और आशाजनक दिशा को जल्दी पहचानने का अनुभव हो
• अधिकांश teams ऐसी परिस्थितियों में काम नहीं करतीं
  • low-maturity environments, सीमित organizational knowledge, या नए और उच्च-जोखिम वाले contexts में solution से शुरुआत करने पर गलत assumptions की लागत बढ़ जाती है
  • ऐसे मामलों में कम-से-कम प्रारंभिक problem framing अब भी आवश्यक है

process literacy: समस्या के अनुसार प्रोसेस चुनना

• आधुनिक डिज़ाइन की असली क्षमता प्रोसेस को छोड़ने में नहीं, बल्कि process literacy में है — यानी समस्या के अनुसार सही approach और tools चुनने की क्षमता
  • यह जानना ज़रूरी है कि किस काम के लिए कौन-सा प्रोसेस उपयुक्त है, और उसे न अपनाने पर क्या risks हैं
  • अगर आप सिर्फ प्रोसेस को अलग तरीके से लागू कर रहे हैं, तो यह दावा नहीं करना चाहिए कि आप प्रोसेस का उपयोग ही नहीं कर रहे
• इसका यह मतलब नहीं कि हर project को 6 हफ्तों का discovery phase चाहिए, और न ही यह कि हर डिज़ाइन समस्या को medical device development की तरह संभालना चाहिए
  • problem के अनुसार process matching ही कुंजी है: कुछ समस्याओं में गहरी जाँच ज़रूरी होती है, जबकि कुछ में तेज़ experiments और iteration अधिक प्रभावी होते हैं
  • यह चयन इसलिए होना चाहिए क्योंकि आपने जानबूझकर ऐसा तय किया है, न कि इसलिए कि किसी ने घोषणा कर दी कि "प्रोसेस मर चुका है"
• AI tools पहले कभी न देखी गई गति से rapid prototyping और iteration को संभव बनाते हैं, लेकिन वे डिज़ाइन प्रोसेस द्वारा कम की जाने वाली अनिश्चितता और risk को खत्म नहीं करते
  • डिज़ाइनरों को अब भी समस्या समझनी होती है और ideas का मूल्यांकन करना होता है
• Double Diamond, Design Thinking, और Jobs-to-be-Done जैसे process frameworks कठोर procedures नहीं, बल्कि scaffolding हैं
  • एक बार भीतर समाहित हो जाने पर, वे सोचने के उस तरीके को सिखाते हैं जो अनुभवी प्रैक्टिशनरों के काम में implicit रूप से घुल-मिल जाता है
• असली सवाल यह नहीं है कि प्रोसेस फॉलो करना है या नहीं, बल्कि यह है कि हम जो काम कर रहे हैं, वह जिस समस्या को हल करना चाहता है, उससे कैसे map होता है
  • जैसे-जैसे AI और workflows को संकुचित करेगा, और agent systems कार्रवाई करने, context याद रखने, और हमारी ओर से निर्णय लेने लगेंगे, इस सवाल को skip करने की कीमत कम नहीं बल्कि और अधिक होगी