अब मैं Figma से ज़्यादा Claude के साथ डिज़ाइन करता हूँ

 (blog.janestreet.com)
3 पॉइंट द्वारा GN⁺ 2026-06-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • स्पेक दस्तावेज़ और Figma mockup लिखने के बजाय, दिमाग में मौजूद आइडिया को सीधे काम करने वाले prototype feature के रूप में बनाने वाले डिज़ाइन workflow की ओर बदलाव
  • पहले Copilot, Cursor, Gemini जैसे LLM को लेकर संदेह था, लेकिन Jane Street जॉइन करने के बाद महसूस हुआ कि AI support अब अनिवार्य है
  • Claude मुफ़्त और असीमित iteration की अनुमति देता है, इसलिए 50 बार बदलने पर भी बिना शिकायत Submit बटन, shortcut, कॉपी जैसी बारीक सुधार किए जा सकते हैं
  • डिज़ाइनर भी इंजीनियरों की तरह काम करने वाला proof of concept (POC) खुद बना सकते हैं, ताकि दूसरे लोग उसे सीधे इस्तेमाल करके उसका मूल्यांकन कर सकें
  • सभी प्रयास सीधे वास्तविक output पर केंद्रित होने से, बीच के सहायक काम हटते हैं और collaboration का एक नया मॉडल बनता है

LLM को लेकर संदेह से बदलाव

  • लंबे समय तक LLM को लेकर संदेह रहा, और हर बार इस्तेमाल करने पर नतीजों से निराशा हुई
    • पिछले साल अपने बनाए गेम में बदलाव करने के लिए Copilot और Cursor आज़माए, लेकिन दोनों काम करने वाला बदलाव नहीं बना सके
    • पिछली नौकरी में Gemini से product brief का outline और wireframe बनवाए, लेकिन सब छोड़ दिए गए
    • जिन कामों में LLM को आज़माया, वे सभी ऐसे क्षेत्र थे जिनमें मैं पहले से अच्छा था, और नतीजा खुद करने से बदतर था
  • पिछले गर्मियों में Jane Street जॉइन करने के बाद महसूस हुआ कि AI support ज़रूरी है
    • क्योंकि OCaml और Bonsai जैसे कई नए और अभी अपरिचित क्षेत्र थे
    • सबसे बड़ा आश्चर्य यह था कि मेरा सबसे मज़बूत क्षेत्र, यानी डिज़ाइन workflow, भी बदल गया

prototype-केंद्रित workflow

  • स्पेक दस्तावेज़, Figma mockup, proposal लिखने और डेवलपर के साथ implementation review करने के बजाय, इच्छित काम को वैसा ही करने वाला prototype feature सीधे बनाना

  • वास्तविक काम करने का प्रवाह

    • समस्या और प्रस्ताव को लिखना
    • editor खोलना और build, server, Claude चलाना, फिर लिखे गए विवरण को prompt के रूप में इस्तेमाल करना
    • संभावना साबित करने के लिए पहले बुनियादी functionality को काम करने लायक बनाना
    • जितनी बार चाहें उतनी iteration करना
    • बदलावों को development environment में push करना और user feedback लेना
    • इच्छित रूप और व्यवहार वाला feature सबमिट करना, जो इस कंपनी में pull request के बराबर है
  • वास्तविक codebase के अंदर बना prototype, mockup और दस्तावेज़ों की तुलना में लगभग हर मायने में बेहतर निकला

JSQL input prototype का उदाहरण

  • हाल ही में JSQL input में LLM prompting जोड़ने वाला एक prototype बनाया
    • JSQL कई तरह के user-facing tools में इस्तेमाल होने वाली एक internal SQL dialect है
    • यह वास्तव में काम करता था, और इसे कई दिनों तक इस्तेमाल और test करते हुए इसके साथ रहा गया
  • Claude मुफ़्त और असीमित iteration देता है, इसलिए 50वीं बार राय बदलने या छोटे सुधार माँगने पर भी उसे फ़र्क नहीं पड़ता
    • Submit बटन को refine करना, keyboard shortcut जोड़ना, कॉपी बदलना, prompt समायोजित करना, generative confirmation message जोड़ना
    • पिछली नौकरी में ऐसे सुधारों के लिए कई दिन या कई हफ्तों तक engineering और design के बीच आना-जाना पड़ता, या वे होते ही नहीं
  • सारा प्रयास वास्तविक output को बेहतर बनाने में जाता है, न कि Figma component बनाने या document formatting जैसे सहायक कामों में

workflow को स्थापित करने की प्रक्रिया

  • इस तरीके तक पहुँचने में समय लगा
    • शुरुआती दिनों में AI का इस्तेमाल केवल UX की छोटी-मोटी खामियाँ ठीक करने जैसे छोटे कामों में किया
    • बड़े आइडिया के लिए अब भी Figma और दस्तावेज़ों का इस्तेमाल होता था, और Claude से कोशिश करने पर असफलता मिलती थी
  • पिछले दो महीनों में Figma की ओर हाथ बढ़ाने की ज़रूरत बहुत कम हो गई
    • model improvements, अपनी skill में बढ़ोतरी, और सही scope चुनने के मेल से बड़े कामों में भी AI काम करने लगा
    • JSQL prompt के अलावा भी user-facing, data model, और library changes से जुड़े कई prototype बने, जिनमें कुछ 2000 lines से अधिक diff वाले थे
    • कभी Figma में डिज़ाइन करने के बाद interactive prototype लागू किया गया, और कुछ नए app में Figma को पूरी तरह छोड़कर शुरुआत से Claude के साथ visual design iterate किया गया

डिज़ाइनरों को मिलने वाली ताकत

  • इंजीनियरों के पास यह क्षमता होती है कि आइडिया आते ही वे खुद काम करने वाला proof of concept बना लें, लेकिन डिज़ाइनरों को अक्सर दूसरों को मनाना पड़ता है
    • JSQL input के भीतर direct LLM prompting जैसा आइडिया शुरुआत में संभव भी होगा या नहीं, यह स्पष्ट नहीं होता; ऐसे में किसी और से prototype बनवाना समय की बर्बादी बन सकता है
    • यह ऐसा प्रस्ताव भी हो सकता है जो user need को स्पष्ट रूप से पूरा न करता हो
  • Claude के साथ जब आइडिया को वास्तव में लागू किया जाता है, तो दूसरे लोगों के लिए उसे खुद इस्तेमाल करके मूल्यांकन करना कहीं आसान हो जाता है

review के तरीके की चुनौती

  • इसका नुकसान यह है कि reviewer के पास एक पूरा feature पहुँचता है
    • क्या इसका मतलब यह है कि feature पर input देने के बिना उन्हें सिर्फ code review करना होगा?
    • यह कुछ वैसा है जैसे डिज़ाइन में PM से detailed wireframe लेकर कहा जाए कि अब इसे बस "अच्छा दिखने वाला" बना दो
    • प्रस्ताव को जितना हो सके स्पष्ट और पूरा बनाने की कोशिश रहती है, लेकिन इच्छा यह है कि इंजीनियर साथी Figma mockup की तरह डिज़ाइन स्पेस में साथ iterate करें

  • मौजूदा समाधान

    • feature को अलग नज़रिए से देखने का फैसला किया गया है, और विवरण में एक छोटा मार्गदर्शन लिखा जाता है
    • prototype एक जीवित proposal document है, code अस्थायी है, और reviewer की भूमिका design और user experience पर feedback देना है
    • अंततः reviewer उस आइडिया को लेकर अलग feature में implementation करता है, prototype को reference की तरह इस्तेमाल करते हुए भी production code का स्वामित्व सीधे वही रखता है
    • क्या चीज़ व्यावहारिक और सही महसूस होती है, इसकी खोज अभी जारी है

चिंताएँ और पुराना तनाव

  • Claude के साथ डिज़ाइन करने पर यह डर रहता है कि लचीली और रचनात्मक सोच से हटकर, सोच केवल उन नतीजों तक सीमित हो जाए जिन्हें Claude बना सकता है, यानी दोहराव वाली सोच में फँसने का खतरा
    • धीरे-धीरे बदलने वाले mature tools के लिए यह ठीक हो सकता है, लेकिन पूरी तरह नई चीज़ों में आइडिया छूट सकते हैं
  • यह एक जाना-पहचाना तनाव है, और 2011 की उस बहस से जुड़ता है: क्या डिज़ाइनरों को code लिखना चाहिए?
    • आलोचकों का कहना था कि programming शुरू करते ही आइडिया में बड़े बदलाव करना कठिन हो जाता है
    • लेकिन वेबसाइट बनाना और programming दोनों पसंद होने के कारण code लिखना जारी रखा गया
  • React जैसे frontend framework आम होने और development जटिल होने पर specialization चुना गया
    • personal project अब भी React में बनाए जाते हैं, और इससे डेवलपरों से संवाद में मदद मिलती है
    • काम का ज़्यादातर समय Figma और दस्तावेज़ों में जाता था
  • अगर LLM से पहले Jane Street जॉइन किया होता, तो शायद Figma में और गहराई से फँस गया होता
    • JavaScript का कुछ अनुभव था, लेकिन OCaml और Bonsai पूरी तरह नए थे, इसलिए तकनीकी योगदान पहुँच से बाहर लगता
    • इसके बजाय अब फिर से वास्तविक output बनाया जा रहा है; उस माध्यम में लौटना रोमांचक लगता है और कुछ भी आज़माने की आज़ादी कहीं अधिक महसूस होती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-06-08
Hacker News की राय

  • बिज़नेस पक्ष के लोग अक्सर अपनी आवश्यकताओं को अपने सोचे हुए solution के रूप में लेकर आते हैं, और ज़्यादातर वह किसी Rube Goldberg मशीन जैसी चीज़ होती है, इसलिए बातचीत के ज़रिए reverse engineering करके ही असली requirement तक पहुँचना पड़ता है
    आगे चलकर वे शायद पहले से “तैयार” और “काम करने वाला” solution लेकर आएँगे, और design व architecture को समग्र रूप से देखने की बात के लिए कम खुले होंगे
    बात शायद ऐसी हो जाएगी: “बस इसे ऐसे बना देते हैं। लगभग सब हो चुका है, फिर X insight की क्या ज़रूरत है?”

    • मैंने ऐसा पहले ही देखा है, और वह शुरू से अंत तक पूरी तरह vibe coding से बना था
      दिक्कत यह है कि बिज़नेस पक्ष यह नहीं समझता कि उस app को वैसे का वैसा production में deploy क्यों नहीं किया जा सकता
      “AI के साथ हम तेज़ी से आगे बढ़ सकते हैं” वाला दबाव बढ़ेगा, और आखिरकार बात healthy organizational dynamics पर आ टिकेगी
      फायदा यह है कि napkin sketch की तुलना में idea कहीं ज़्यादा अच्छी तरह validate हो चुका होता है
      Claude शायद पहले ही edge cases और design decisions के बारे में पूछ चुका होगा, और किसी बिंदु पर संभव है कि सामने वाले ने साफ़ कहा हो, “उसकी चिंता मत करो, मान लो ऐसा है” या “इसे कुछ बार इस्तेमाल किया, यह interaction अच्छा नहीं लगा, इसे अलग करो”
      अभी “क्या दिक्कत है, बस deploy कर दो” वाला दबाव बहुत ज़्यादा, मूर्खतापूर्ण और मनोबल तोड़ने वाला है, इसलिए लगभग शुद्ध नुकसान जैसा है, लेकिन अगर यह स्थिर हो गया तो भविष्य के projects में शुद्ध लाभ भी बन सकता है
    • बहुत बार चीज़ें इस तरह आती हैं: “लगभग सब हो चुका है, production deploy से पहले बस कुछ छोटे fixes चाहिए”
      लेकिन वे छोटे fixes दरअसल ऐसी चीज़ें होती हैं जैसे browser की चौड़ाई ठीक 1920px न हो तो layout टूट जाता है, filter और sorting कभी-कभी सही काम नहीं करते, या किसी action के बाद नया value app में सही update नहीं होता
      समस्या चाहे जो भी हो, बिज़नेस पक्ष यह मान चुका होता है कि वे 95% काम कर चुके हैं, इसलिए पहले से ही सोच लेते हैं कि “कोई skilled developer इसे झट से ठीक कर देगा”
    • जैसे home demo music professional quality के काफ़ी करीब पहुँचने लगा, audio engineering की दुनिया में यह बात कुछ समय से आम रही है
      लोग अपने पास मौजूद result के इतने अभ्यस्त हो जाते हैं कि नए professional mix में हुए बदलावों को स्वीकार करना उनके लिए और मुश्किल हो जाता है
    • हमारे यहाँ भी बिज़नेस पक्ष अपनी सोची हुई solution को requirement की तरह लेकर आता है, जबकि ज़्यादातर मामलों में वह ग्राहक जो चाहता है वह नहीं होता
      कुछ PM, CSM, TAM ऐसे होते हैं जिनमें customer problem को अच्छी usability वाले product feature में बदलने की समझ होती है, लेकिन अगर problem definition को छोड़कर किसी दूसरे functional org से solution बनवाया जाए, तो आम तौर पर engineering और दूसरे resources की भारी बर्बादी वाली त्रासदी बनती है
      जब कोई solution लेकर आता है, तो यह बड़ा जोखिम होता है कि कई महीनों तक production-grade software बनाने के बाद ही पता चले कि ग्राहक उसे नापसंद करते हैं, वह समस्या हल नहीं करता, या नई समस्या पैदा कर देता है
    • यह अभी सचमुच हो रहा है
      जहाँ मैं अभी काम करता हूँ वहाँ नहीं, बल्कि मेरी पिछली कंपनी में, और वह data loss तथा security issues के साथ ही production में deploy भी हो गया

  • मेरी जानकारी के अनुसार Jane Street, Anthropic का investor है, इसलिए इस बात को ध्यान में रखना चाहिए

    • इसे बहुत बड़े salt pinch के साथ लेना चाहिए
      यह भी है कि जुलाई 2025 में भारत के securities regulator SEBI ने Jane Street पर कई entities का इस्तेमाल करके market manipulation करने का आरोप लगाया था और उसका market access प्रतिबंधित किया था
    • मेरी समझ में Jane Street ने OCaml में बड़ा योगदान दिया है और अपना web framework भी बनाता है
      इतना बड़ा money machine है तो dashboards की भरमार तो होगी ही
      यहाँ designer शायद ग़लत दिशा में जा रहा है, और ऐसा लगता है कि वह engineering envy में फँसा है, जहाँ prototype को जितना हो सके उतना गहरा और वास्तविक बनाना चाहता है
      लेकिन design work का सबसे महत्वपूर्ण हिस्सा वह नहीं है
      सबसे महत्वपूर्ण बात यह है कि सही चीज़ बनाई जाए
      “JSQL input box की ज़रूरत ही क्यों है? वास्तव में चाहत क्या है? और कौन से तरीके हो सकते हैं?” जैसे सवाल अक्सर pen-and-paper sketch, meetings, observation और discussion से बेहतर हल होते हैं
      यह किसी खास design पर बहुत जल्दी सिमट जाने और फिर यह बहस करने से बेहतर है कि button बाईं ओर हो या दाईं ओर, या LLM का बारीक व्यवहार कैसा हो
    • चाहे investor न भी हो, मुझे यह साफ़ नहीं कि quant trading company की frontend design संबंधी राय की कितनी परवाह करनी चाहिए
    • अब पूरा HN एक विशाल AI billboard जैसा लगने लगा है
    • किसी random employee की थोड़ी-सी दिलचस्प blog post को भी psychological warfare मानने की ज़रूरत शायद नहीं है
      हालाँकि, हो सकता है वे ठीक यही चाहें कि लोग ऐसा ही सोचें

  • कभी-कभी यह साफ़ दिखता है
    अभी LLM पुनरावृत्ति से आगे नहीं देख पाता, इसलिए मुझे ही दायरे से बाहर सोचते हुए कहना पड़ता है, “अगर इसे इस नज़रिए से देखें तो?” तभी अचानक design का नया तरीका निकलता है
    कभी-कभी LLM को उसके मौजूदा progression stage से आगे दिखाने के लिए flowchart बनाना पड़ता है

  • “Claude ने मुझे free, unlimited iteration दी, उसे फ़र्क नहीं पड़ता कि मैं 50वीं बार अपना मन बदलूँ या कोई छोटा बदलाव माँगूँ” — तो क्या Claude का पैसा नहीं देना पड़ता?

    • यहाँ “free, unlimited iteration, फ़र्क नहीं पड़ता” का मतलब शायद ज़्यादा यह है कि third-party project basis या freelance designer के साथ काम करते समय आम तौर पर “draft + 1 revision” वाला pricing होता है, और उसके बाद हर बदलाव पर extra fee लगती है
      छोटे design studio भी अक्सर ऐसे ही होते हैं, और developers की तरह प्रति घंटा charge नहीं करते
    • 2025 में Jane Street का प्रति कर्मचारी net profit revenue नहीं बल्कि profit के आधार पर कई मिलियन डॉलर के ऊपरी हिस्से में था
    • यहाँ free का मतलब शायद कीमत नहीं, बल्कि बिना manual labor के creative freedom होना है
    • थोड़ा संबंधित किस्सा: एक बार मेरा interview था जिसमें CEO, lead developer और lead designer थे, और उन्होंने वही घिसा-पिटा सवाल पूछा, “तुम्हारी weakness क्या है?”
      मैंने ईमानदारी से कहा कि मैं design में बहुत ख़राब हूँ, और design system को extrapolate करने में भी दिक्कत होती है
      किसी acceptable बिंदु तक पहुँचना मेरे लिए बहुत मुश्किल होता है, और उस प्रक्रिया में मैं लगभग हमेशा चीज़ को और बदतर बना देता हूँ
      interview ले रहे designer ने इसे व्यक्तिगत रूप से ले लिया और मुझे काफ़ी घेरा
      पहले भी ऐसा हुआ है
      designers को यह लगातार पूछे जाने से चिढ़ होती थी कि चीज़ें कैसी दिखनी चाहिए, और वे ऐसा handoff चाहते थे जिसे एक बार दे दिया जाए और बात ख़त्म हो
      marketing और advertising agencies में भी मुझे इस बात पर लड़ना पड़ता था कि design spec में जो चीज़ें नहीं थीं, उनके लिए sample दिए जाएँ कि वे कैसी दिखेंगी
      मैं यह नहीं कह रहा कि मैं सही था, लेकिन यह मेरी बड़ी Achilles heel है
      इसलिए जब मैं “free, unlimited iteration, फ़र्क नहीं पड़ता” सुनता हूँ, तो मेरे दिमाग में पैसे से पहले समय और धैर्य आता है
      prototyping के लिए जो Bolt मैं इस्तेमाल करता हूँ, वह मुझ पर गुस्सा नहीं होता
      वह शायद सबसे बेहतरीन design नहीं बनाता, लेकिन जो मैं कर सकता हूँ उससे काफ़ी बेहतर बनाता है, और जब काम पूरा हो जाए तो किसी असली designer से उसे और बेहतर बनवाया जा सकता है
      तब तक मुझे यह चिंता नहीं करनी पड़ती कि कहीं मैं किसी को नाराज़ न कर दूँ

  • मैंने फ्रंटएंड में Claude Design का इस्तेमाल किया है
    आउटपुट का लुक और फील काफ़ी अच्छा होता है, लेकिन डिज़ाइन अक्सर एक जैसे दिखते हैं और ज़्यादातर आधुनिक वेब के घिसे-पिटे पैटर्न को फॉलो करते हैं
    जानना चाहता हूँ कि क्या किसी ने इससे कुछ गैर-पारंपरिक, रचनात्मक प्रयोग किए हैं

    • पोर्टफोलियो साइट देखिए, इसे डेस्कटॉप पर देखना बेहतर है
      अब तक लगभग 3 हफ्ते लगे हैं और यह अभी अधूरी है, लेकिन अंदाज़ा मिल जाएगा
      जैसे पिछले 10 सालों में SaaS boilerplate था, वैसे ही इंटरनेट पर ट्रेन किए गए LLM boilerplate भी हैं
      फिर भी, अगर आप काफ़ी मेहनत करें तो अब भी कुछ भी संभव है
    • मेरा अनुभव भी ऐसा ही रहा, इसलिए मैंने अलग-अलग prompts और inputs टेस्ट करने शुरू किए
      मज़ेदार बात यह है कि आप requirements दें तो यह उसी के हिसाब से चलता है, और दिशा न दें तो safe choices चुनता है
      अगर आप आउटपुट की aesthetics और user experience·content को evaluate करने वाले हैं, लेकिन aesthetics वाले prompts लगभग देते ही नहीं, तो आपको सिर्फ safe defaults ही मिलेंगे
      bootstrap/tailwind की नकल जैसे डिज़ाइन यह अच्छी तरह बना देता है, लेकिन उस हिस्से को आपको जानबूझकर push करना पड़ता है
      साधारण वेब पेजों में मैंने शुरुआती iterations का एकमात्र फोकस visual style पर रखना शुरू किया है
    • ज़्यादातर applications को गैर-पारंपरिक रचनात्मकता की ज़रूरत नहीं होती
    • मैं भी ऐसा ही हूँ
      बस साफ़-साफ़ निर्देश देना होता है कि यह standard जैसा न दिखे, और जिस वेबसाइट स्टाइल की चाहत है उसके examples दे दो
      थोड़ा जूझो तो यह थोड़ा ज़्यादा creative महसूस होता है, लेकिन prompt work करनी पड़ती है
    • मैं भी Claude Design इस्तेमाल करता हूँ
      बहुत सम्मानित और अनुभवी designers ने इसकी सिफ़ारिश की थी, और वे अब लगभग पूरी तरह Claude में prototype बनाते हैं, फिर पसंद आने पर Figma में polish करते हैं
      शुरुआत में detailed style prompts दिए बिना अगर आप generic UI माँगेंगे, तो generic design ही मिलेगा

  • यहाँ फ़ायदा यह है कि designers coding सीखते हैं
    मुझे हमेशा अजीब लगा कि software कैसे बनता है यह जाने बिना designers software को shape करते हैं
    वैसे, मैं भी designer हूँ
    लेकिन code में design करना एक technology-first approach है
    अगर design का मकसद मानवीय उद्देश्यों के हिसाब से output को shape करना है, तो code के सख़्त नियमों से शुरू न करना बेहतर माना जा सकता है
    सिर्फ़ सुंदर आउटपुट की वजह से नहीं, सोच को आगे बढ़ाने में अब भी pen और paper को हराना मुश्किल है

    • 6 साल तक full-stack और frontend-केंद्रित engineer के रूप में काम किया, फिर हाथ से code लिख-लिखकर थक गया और design में चला गया
      अब जबकि practically आवाज़ से coding की जा सकती है, मैं फिर से vibe coding और product बनाने की ओर लौट रहा हूँ, और यह शानदार है
      मेरा मैनेजर अभी इस नई स्थिति को समझ ही रहा है, लेकिन पुराना role separation मरना शुरू हो गया लगता है
      मेरे हिसाब से अभी intersection पर होना सबसे अच्छी जगह है
      लगता है जैसे मेरी पूरी ज़िंदगी मुझे इसी पल के लिए तैयार कर रही थी
    • माध्यम की सीमाओं को समझना मददगार है, लेकिन silicon के भीतर electron कैसे चलते हैं, इस स्तर तक हर layer जानना ज़रूरी नहीं
    • LLM आम तौर पर coding को भुला देता है, इसलिए इस तरह इस्तेमाल करना सीखने के लिए अच्छा होगा या नहीं, इस पर शक है
      designers के लिए यह शायद Figma जैसा होगा, जहाँ वे visual editor की जगह नतीजा देखकर भाषा में edits करते हैं
    • designers coding नहीं सीख रहे
      मेरी पत्नी FAANG में product manager है, और उसकी टीम AI से vibe coding पर बेहद निर्भर है उन software pieces के लिए, जो पहले Word या Excel जैसी चीज़ों में किए जाते
      वे coding नहीं सीखते, और code को एक सेकंड भी नहीं देखते
    • ऐसे designers चाहिए जो engineers के साथ क़रीब से काम कर चुके हों और जिनका judgment सही हो

  • “prototype एक जीवित proposal document है, code को फेंका जा सकता है, और reviewer का काम architecture और user experience पर feedback देना है
    आखिर में reviewer idea को लेकर अलग feature के रूप में implement करता है, prototype को reference की तरह रखता है, लेकिन production code का ownership खुद लेता है” — यह approach उन समस्याओं को हल कर देती है जिनसे मैं हर POC में जूझता था
    यह सच में बहुत अच्छा तरीका है

    • वह लेख किसी ऐसे व्यक्ति ने नहीं लिखा जो Figma से रोज़ी-रोटी कमाता हो
      किसी खास product के किसी खास issue को handle करते समय उसे “proposal document” कहना आसान है
      लेकिन अब भी बहुत से designers Figma का इस्तेमाल पूरे product और platform में design system को define और maintain करने के लिए करते हैं, और उस स्थिति में Figma ही source of truth है

  • हमारी टीम भी यही कर रही है, और मैं frontend engineer हूँ, लेकिन सच कहूँ तो मुझे पुराना तरीका बहुत याद आता है
    लिखी हुई spec को working prototype से replace कर देने के कारण अब code पढ़कर यह समझने का अतिरिक्त cognitive load आ गया है कि intended change क्या है और कौन-सा हिस्सा फेंक देने लायक noise है
    generated PR मिलती है, फिर तय करना पड़ता है कि ज़रूरी बदलाव करूँ या शुरू से दोबारा बनाऊँ, और दोनों ही स्थितियों में friction है
    कई बार ढेर सारे unintended changes generate हो गए, मैंने reimplementation में समय लगा दिया, और बाद में सुनना पड़ा, “ओह, sorry, वह बदलना तो था ही नहीं”
    empowerment वाली बात समझता हूँ, लेकिन इससे मेरे पुराने काम का कुछ आनंद छिन गया है और वह सिरदर्द बन गया है

    • मैं भी लगभग उसी स्थिति में हूँ
      design और product वाले Claude से features या experiences को vibe design·coding कराते हैं, जल्दी prototype बनाते हैं, और न्यूनतम engineering समय में उसे customer के सामने ले जाकर feedback लेते हैं
      शानदार
      लेकिन हैरानी की बात है कि इससे कुल मिलाकर faster shipping में ज़्यादा मदद नहीं मिली
      मुझे लगता है वजह यह है कि इस प्रक्रिया में सोच खो गई
      काफ़ी सारा विचार अब language model को outsource कर दिया गया है
      यह prompt की खाली जगहों पर रंग भर देता है, और जो behavior explicitly नहीं बताया गया, उसे hallucination से भर देता है
      पहले जहाँ हम रुक जाते थे — “यह ठीक से fit नहीं बैठ रहा”, “इस idea को कैसे communicate करें”, “इस case में क्या होगा” — वे सब ग़ायब हो गए, और अब ऐसी details को सही तरीके से बनाने के बाद के लिए टाल दिया जाता है
      हाँ, process को बेहतर किया जा सकता है और इस नई technique का ज़्यादा अच्छा इस्तेमाल सीखा जा सकता है, लेकिन क्या यह पहले से बेहतर है, कह नहीं सकता
    • क्या Claude Design से ऐसा दस्तावेज़ नहीं लिखवाया जा सकता जो prototype को पूरी तरह specification कर दे?
    • पुराना तरीका धीमा था, feedback cycle लंबी थी, और UI की gatekeeping करता था
      वह अब ढलान पर है
      अब backend वाले भी frontend कर रहे हैं
    • code अब पढ़ने के लिए बनाया ही नहीं जाता
      यही भ्रम है
      क्या आप compiler से बने assembly को देखते हैं? नहीं
      फिर यह code क्यों देख रहे हैं?
      हमने बस abstraction layer को ऊपर उठा दिया है

  • मैं भी यही approach बहुत इस्तेमाल करता हूँ
    AI से पहले भी मैं इसे मैन्युअली ऐसे ही करता था
    पहले यूज़र के साथ सिर्फ पेन और कागज़ लेकर बैठता था, फिर जल्दी से frontend POC या demo बनाता था, यूज़र को उसे छूकर देखने देता था, और जब तक वह उनकी चाहत के मुताबिक काम न करे तब तक उसे tweak करता था
    मेरे लिए, production quality के बजाय तेज़ frontend demo को code में बनाना, Figma में सटीक interaction बनाने से अक्सर पहले ही ज़्यादा तेज़ होता था
    क्योंकि उसमें पूरी interaction संभव थी, इसलिए user experience के edge cases कहीं ज़्यादा पकड़ पाता था
    अब Claude Code की वजह से फेंक देने वाले prototype और भी तेज़ी से बन जाते हैं, लेकिन फर्क बहुत बड़ा नहीं है
    कुल समय का 80% तो यूज़र से चर्चा करने और यह सोचने में जाता है कि चीज़ें कैसे काम करनी चाहिए, इसलिए Claude बस बाकी 20% को, खुद तेज़ी से बनाने की तुलना में, आधा कर देता है
    पहला version ज़रूर जल्दी बन जाता है, लेकिन जब समझ पूरी न हो तो iteration और धीमा हो जाता है

  • Edwin, तुम्हारी पोस्ट देख कर अच्छा लगा
    याद है, 2012/2013 के आसपास हमने साथ में hackathon किया था
    काम करने वाले prototype तक और जल्दी पहुँचने की क्षमता बहुत ताकत देती है, भले ही उसमें अधूरे ideas को वैसे ही ship कर देने का प्रलोभन हो
    design और user experience requirements को storyboard और wireframe से आगे बढ़कर तब बहुत फायदा मिलता है, जब लोग असली flow को छूकर देख और अनुभव कर सकें