परंपरागत Design Case Study मर रही है
फूली हुई 47-स्क्रीन case study एक session में ship किए गए working app से हार रही है। क्या बदला, आपका portfolio अब कैसा होना चाहिए, और thinking अभी भी क्यों मायने रखती है।
फूली हुई design case study मर रही है। Case study खुद नहीं।
यही फर्क पूरा argument है, तो इसे पकड़े रखिए। छह हफ्तों की process documentation वाला 47-स्क्रीन deck उस तीन मिनट के Loom से हार रहा है जिसमें कोई एक session में बना working product दिखाता है। जब hiring manager दस सेकंड में live URL click कर सकता है, तो आपका double-diamond walkthrough उन्हें वो homework जैसा लगने लगता है जो आप उन्हें assign कर रहे हैं।
यह thinking की मौत का notice नहीं है। यह notice है कि proof की जगह बदल गई है। Artifact argument बन रहा है, और artifact को explain करने वाला slide deck optional होता जा रहा है।
वो thread जिसने designer Twitter को दो हिस्सों में बांट दिया
लड़ाई तब public हुई जब designer @andrewk ने एक thread post किया जिसमें पूछा कि क्या traditional case study अब obsolete हो गई है। वो thread जमकर चला: करीब 9.8k reposts और 400 से ज़्यादा replies, और designers बिल्कुल बीच में बंटे हुए।
यही split signal है। आधे कमरे ने argue किया कि case study पवित्र craft है। दूसरे आधे ने अपने live demos की तरफ इशारा किया और पूछा कि जब product सामने है तो deck की ज़रूरत ही क्या है।
दोनों गलत नहीं हैं, इसीलिए यह इतना फैला। यह disagreement इस बारे में नहीं है कि designers को सोचना चाहिए या नहीं। यह इस बारे में है कि उस thinking का सबूत अब कहां रहना चाहिए, जब shipping लगभग free है।
असल में क्या बदला (एक session, real auth, real payments, उसी दिन ship)
जो बदला वो यह है: working artifact बनाने की cost बिल्कुल गिर गई। Indie designers और founders अब complete, functional apps post कर रहे हैं, auth के साथ, payments के साथ, real data flows के साथ, एक single extended session में generate किए और उसी दिन ship किए।
Tools ने यह credible बनाया, और तेज़ी से। Claude Code या Cursor में एक long-running build अब पूरे session में एक coherent plan पकड़े रह सकता है, तीसरी file के बाद बिखरने के बजाय। Fable 5 की long-horizon reliability और हाल के CursorBench wins की वजह से "one take" एक demo trick जैसा लगना बंद हो गया और Tuesday जैसा लगने लगा।
तो math पलट गया। पुरानी case study इसलिए थी क्योंकि real चीज़ बनाना expensive, slow था और engineering के पीछे बंद था। आप process document करते थे क्योंकि process ही वो ज़्यादातर काम था जो आप actually दिखा सकते थे।
अब real चीज़ बनाना सस्ता है। जब आप दिन के अंत तक किसी को live URL दे सकते हैं, तो आप उसे कैसे बनाते उसका static reconstruction उस evidence का बदतर version लगता है जो आपके पास already है।
पुरानी deliverable बनाम working artifact (सच वाली table)
यहां वो comparison है जो इसे concrete बनाती है। यह hype नहीं है, यह एक real difference है कि हर format उस इंसान के लिए actually क्या करता है जो आपको evaluate कर रहा है।
| Dimension | पुरानी case-study deliverable | Working-artifact deliverable |
|---|---|---|
| Format | 30 से 50 static screens, narrated process | एक live URL और एक short walkthrough |
| क्या prove करती है | आप एक method describe कर सकते हैं | आप कुछ ऐसा ship कर सकते हैं जो चलता है |
| Evaluate करने का समय | 8 से 15 मिनट पढ़ना | 10 सेकंड click करना, 3 feel करना |
| क्या छुपा सकती है | कि उसमें से कोई चीज़ actually काम आई या नहीं | लगभग कुछ नहीं, चलती है या नहीं |
| Common failure | Process theater, substance पर polish | चिकनी surface के पीछे thin thinking |
| Reviewer को क्या याद रहता है | एक vibe और कुछ screenshots | वो पल जब product ने कुछ किया |
"क्या छुपा सकती है" row को दो बार पढ़ें। Static case study यह छुपा सकती है कि design real data, real states, या real backend से संपर्क में कभी बची नहीं। Working artifact यह नहीं छुपा सकती, क्योंकि reviewer उसके अंदर खड़ा है।
इसीलिए artifact trust में जीतता है। एक चलने वाली चीज़ को fake करना उससे ज़्यादा मुश्किल है जो सिर्फ render हो।
Case study मरी नहीं है, फूली हुई case study मरी है
अब honest counterpoint, क्योंकि obituary वाला version lazy है।
Live demo यह prove करता है कि surface काम करता है। यह अपने आप यह prove नहीं करता कि आपने problem समझी, tradeoffs तौले, या तीन बुरे alternatives पर इस shape को choose किया। एक खूबसूरत app जो गलत problem solve करे, वो अभी भी गलत problem है, बस तेज़ ship हुई।
यही trap है "case study मर गई" में। लोग इसे सुनते हैं और slide bloat के साथ thinking भी delete कर देते हैं। वो same नहीं हैं। Bloat वो 12 slides हैं जिनमें persona quotes और वो moodboard है जो किसी ने नहीं मांगा। Thinking वो दो decisions हैं जिन्होंने actually product shape किया।
तो move यह नहीं है कि "अपना काम explain करना बंद करो।" Move यह है "padding बंद करो।" Judgment रखो, theater काटो। बिना कहानी के एक working artifact "मैं यहां prompt करके पहुंचा" जैसा लग सकता है, और senior roles के लिए यह real liability है।
आपके portfolio को अब क्या prove करना है (taste, judgment, problem framing)
जब shipping लगभग free हो, तो scarce चीज़ output नहीं है। यह वो तीन चीज़ें हैं जो एक one-shot app अकेले prove नहीं कर सकता।
Taste. जब कोई भी एक passable interface generate कर सकता है, तो passable और right के बीच का gap ही पूरी job है। Taste वो हज़ार छोटे calls हैं जो model आपके लिए नहीं करेगा: क्या काटना है, क्या slow करना है, कहां जानबूझकर friction add करनी है।
Judgment. Fork दिखाओ। वो version दिखाओ जो आपने kill किया और वो एक sentence reason जो आपने उसे kill किया। एक "हमने X try किया, checkout पर trust टूटी, इसलिए Y किया" बिना किसी fork वाले 40-slide narrative से ज़्यादा prove करता है।
Problem framing. Demo यह answer करता है "क्या आपने इसे बनाया।" Framing यह answer करती है "क्या यह होना चाहिए था, और इस shape में।" यही वो सवाल है जहां senior designers title earn करते हैं, और model इसे आपको देने में सबसे बुरा है।
Notice करें इनमें से किसी को भी 50 screens की ज़रूरत नहीं। इन्हें एक live thing और कुछ honest sentences चाहिए उन calls के बारे में जो आपने बनाते वक्त लिए।
इस महीने अपना portfolio कैसे rebuild करें (live thing से lead करें, एक short decisions log रखें)
आप इसे एक महीने में rebuild कर सकते हैं बिना जो है उसे जलाए। Shape simple है: artifact से lead करो, judgment से back करो, बाकी काटो।
-
Live thing से lead करो। हर project की first screen एक clickable URL या product running का 60 से 90 second walkthrough है। Hero shot नहीं, actual product। Reviewer को कुछ real touch करना चाहिए एक भी word पढ़ने से पहले।
-
एक short decisions log रखो। हर project में तीन से पांच decisions, हर एक line। Decision, वो alternative जो reject किया, reason। यही judgment evidence है जो demo अकेले carry नहीं कर सकता।
-
हर project में एक fork दिखाओ। वो version जो ship नहीं हुआ और क्यों। यह prove करने का सबसे तेज़ तरीका है कि आप सोच रहे थे, सिर्फ generate नहीं कर रहे थे।
-
Process theater काटो। Persona slides delete करो, empathy maps जो आपने कभी use नहीं किए, moodboard, "ideation" screens। अगर इसने product नहीं बदला, तो इसे space नहीं मिलनी चाहिए।
-
Ship date लगाओ। "एक session में idea से live" या "weekend में ship" अब credential है। यह signal करता है कि आप उस speed से move कर सकते हैं जिस speed से काम actually 2026 में चलता है।
बस यही migration है। Artifact से lead करो, पांच lines में judgment prove करो, वो padding फेंको जो हमेशा padding ही थी।
FAQ
क्या design case study पूरी तरह मर गई है?
नहीं। Bloated, process-heavy case study default के रूप में मर रही है। जो इसने prove किया, कि आप सोच सकते हैं और ship कर सकते हैं, वो अब एक working artifact और एक short decisions log में बेहतर रहता है।
क्या मुझे बिना explanation के बस एक working prototype post करना चाहिए?
नहीं, और यह सबसे common overcorrection है। बिना कहानी के demo "मैं यहां prompt करके पहुंचा" जैसा लगता है, जो senior roles के लिए आपको hurt करता है। Live artifact के साथ तीन से पांच one-line decisions और एक reject किया हुआ fork pair करें।
One-shot app exactly क्या है?
एक complete, functional product, अक्सर auth, payments, और real data के साथ, एक extended session में Claude Code या Cursor जैसे tool में बना और उसी दिन ship किया। Human judgment अभी भी involved है। जो collapse हुई वो idea से live चीज़ तक की distance है।
क्या इसका मतलब junior designers मुसीबत में हैं?
Bar "क्या आप एक method describe कर सकते हैं" से "क्या आप ship और defend कर सकते हैं" पर गई है। यह किसी के लिए भी helpful है जो build कर सकता है, क्योंकि एक clickable artifact एक deck से ज़्यादा honest है। Risk उन portfolios के लिए है जो thin substance को process slides के पीछे छुपाते थे।
अगर case study चली गई तो मैं अपनी thinking कैसे prove करूं?
Thinking prove करने के लिए आपको long-form case study की ज़रूरत नहीं। एक short decisions log use करें: वो call जो आपने की, वो option जो reject किया, एक-sentence reason। एक live artifact के साथ तीन से पांच ऐसे entries 40-screen narrative से ज़्यादा judgment prove करती हैं।
Complex enterprise या systems work के बारे में क्या जो one-shot नहीं हो सकता?
तो आपका artifact अलग होगा, लेकिन principle वही रहेगा। एक working slice या functioning component दिखाओ, और उसके साथ decisions log attach करो। Shift यह है "किसी real और clickable चीज़ से lead करो," यह नहीं कि "weekend में अपना पूरा SaaS rebuild करो।"
Takeaway (artifact ही argument है)
Artifact अब argument है। जब आप किसी को एक चलने वाली चीज़ दे सकते हैं, तो यह explaining करने वाला deck कि आप इसे कैसे बनाते, उस evidence की कमज़ोर copy बन जाती है जो आपके पास पहले से है।
@andrewk thread ने 9.8k reposts और 400-plus replies पर designers को बांटा क्योंकि दोनों पक्ष कुछ सच का बचाव कर रहे थे। एक पक्ष ने thinking का बचाव किया। दूसरे ने proof का। Resolution यह है कि proof working thing में चला गया, और thinking उसके साथ पांच honest lines में।
तो case study का मातम मत करो। Bloated वाली retire करो, judgment रखो, और live thing से lead करो। Process out, product in।
2026 में कमरा जीतने वाले designers वो नहीं हैं जिनके पास सबसे मोटा deck है। वो हैं जो कह सकते हैं "यह click करो," और फिर पांच lines में बिल्कुल explain कर सकते हैं कि यह इस shape में क्यों है।
Want a portfolio that ships working product, not slide decks? Let's build it.
Get Started
