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

 (blog.janestreet.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डिज़ाइन workflow अब spec documents और Figma mockups के ज़रिए implementation review करने से आगे बढ़कर, वास्तविक codebase में काम करने वाली prototype features बनाने की दिशा में जा रहा है
  • Copilot, Cursor और Gemini उन कामों में उम्मीद पर खरे नहीं उतरे जिनमें मैं पहले से अच्छा था—जैसे game tweaks, product briefs और wireframes—लेकिन नए सीखे जाने वाले OCaml और Bonsai environment में AI support एक अनिवार्य तत्व बन गया
  • समस्या और प्रस्ताव को prompt के रूप में देने के बाद, basic functionality implement करना, बार-बार सुधार करना, dev environment में deploy करना, user feedback देखना, और feature submit करना—यह पूरी प्रक्रिया वास्तविक implementation-केंद्रित है
  • JSQL input में LLM prompting जोड़ने वाले एक prototype ने button, shortcut, copy, prompts और confirmation messages को कई बार refine करवाया, और Figma components या document formatting की बजाय मेहनत वास्तविक output पर केंद्रित रही
  • अब designer अपने ideas को सीधे उपयोग योग्य रूप में बदल सकता है, लेकिन तैयार feature जैसे दिखने वाले prototypes review participation के तरीके और creative exploration के लिए नई चुनौतियाँ भी लाते हैं

LLM पर संदेह से अनिवार्य support tool तक

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

Figma और documents की जगह वास्तविक codebase prototype

  • spec document लिखने, Figma mockup बनाने, proposal लिखने और developers के साथ implementation review करने की बजाय, अब मैं दिमाग में मौजूद feature को ठीक उसी तरह करने वाली prototype feature बनाता हूँ
  • वास्तविक flow यह है: समस्या और प्रस्ताव समझाने वाला एक वाक्य लिखना, editor में build, server और Claude चलाना, और उसी विवरण को prompt की तरह इस्तेमाल करना
    • पहले basic functionality को चलाकर संभावना देखना, फिर जितनी बार चाहें उतनी बार सुधार दोहराना
    • changes को dev environment में डालना, users से feedback लेना, और मनचाहा रूप व व्यवहार मिलने पर feature submit करना
    • Jane Street में feature, pull request के समान प्रक्रिया है
    विज्ञापन
  • वास्तविक codebase के भीतर बनी prototype feature, mockup और documents की तुलना में लगभग हर मायने में बेहतर अनुभव देती है
  • हाल का एक prototype, जिसमें JSQL input में LLM prompting जोड़ी गई, वास्तव में काम करता था, और इसे कई दिनों तक खुद इस्तेमाल करके test किया गया
    • JSQL कई user-facing tools में इस्तेमाल होने वाली एक internal SQL dialect है
    • Claude 50वीं बार राय बदलने या छोटे-छोटे tweak माँगने पर भी बिना झुंझलाहट के खुला और लगभग असीम iteration देता है
    • Submit button, keyboard shortcuts, copy, prompts और generated confirmation messages तक में सुधार किया गया
  • पिछली नौकरी में ऐसे workflow improvements के लिए engineering और design के बीच कई दिन या कई हफ्तों का आना-जाना पड़ता, या अधिक संभावना यह थी कि वे होते ही नहीं
  • इस feature पर की गई मेहनत Figma components बनाने या document formatting जैसे intermediate deliverables पर नहीं, बल्कि वास्तविक output को बेहतर बनाने पर केंद्रित थी

पिछले दो महीनों में दायरे का तेज़ विस्तार

  • इस flow तक पहुँचने में समय लगा, और शुरुआत में AI का उपयोग केवल छोटे कामों के लिए हुआ, जैसे UX की छोटी असुविधाओं को ठीक करना
  • बड़े ideas के लिए तब भी Figma और documents का उपयोग होता था, और Claude से उन्हें बनाने की कोशिशें असफल रहीं
  • पिछले 2 महीनों में Figma खोलने की ज़रूरत तेज़ी से कम हुई है; बेहतर models, tools में दक्षता, और सही scope चुनने—इन सबने साथ मिलकर असर डाला
  • AI अब सिर्फ JSQL prompts ही नहीं, बल्कि user-facing, data model और library changes वाले लगभग 6 prototypes में भी काम कर चुका है
    • कुछ prototypes में 2000 lines से ज़्यादा diff था
    • Figma में डिज़ाइन किए गए नए app के interactive prototype implementation में भी इसका उपयोग हुआ
    • कुछ नए apps में Figma को छोड़कर शुरुआत से ही Claude के साथ visual design iterate किया गया
विज्ञापन

डिज़ाइनर की agency का विस्तार और review के तरीके की नई परिभाषा

  • engineers के पास idea आने पर काम करने वाला proof of concept बनाने की क्षमता होती है, लेकिन designers को अक्सर किसी और को उसे बनाने के लिए मनाना पड़ता है
  • “JSQL input में सीधे LLM prompting” जैसे ideas की feasibility शुरुआत में साफ़ नहीं होती, इसलिए किसी और से prototype बनवाना समय की बर्बादी भी हो सकता है
  • कुछ proposals user needs को स्पष्ट रूप से पूरा नहीं कर पाते, लेकिन Claude से idea को वास्तविक रूप देने पर दूसरे लोग उसे खुद इस्तेमाल करके आसानी से evaluate कर सकते हैं
  • कमी यह है कि reviewers को मानो एक तैयार feature मिलती है, जिससे यह अस्पष्ट हो जाता है कि क्या उन्हें feature पर input दिए बिना सिर्फ code review करना है
  • डिज़ाइन की भाषा में कहें तो यह वैसा है जैसे PM detailed wireframes देकर सिर्फ उसे सुंदर बना देने को कहे—यह कोई सुखद review task नहीं है
  • proposals स्पष्ट और पर्याप्त रूप से पूर्ण होने चाहिए, लेकिन engineering साथियों को उसे Figma mockup की तरह एक design space में साथ मिलकर iterate करने वाली चीज़ के रूप में देखना होगा
  • अभी का समाधान feature description में एक छोटा-सा notice जोड़ना है
    • prototype एक living proposal document है
    • code को फेंका जा सकता है
    • reviewer की भूमिका design और user experience feedback देना है
  • अंततः reviewer idea को अपने हाथ में लेकर अलग feature में implement करता है; prototype संदर्भ के रूप में रहता है, लेकिन production code की ownership reviewer के पास होती है
  • वास्तविक काम में अभी भी यह समझा जा रहा है कि इस नए workflow में क्या उचित है और क्या स्वाभाविक लगता है

iteration की सीमाएँ और वास्तविक medium में लौटने का एहसास

  • Claude के साथ डिज़ाइन करते समय यह चिंता रहती है कि कहीं सोच का तरीका कम fluid और कम creative न हो जाए, और iteration सिर्फ उन्हीं नतीजों के भीतर सीमित न रह जाए जिनके बारे में लगता है कि Claude उन्हें बना सकता है
  • जब बदलाव incremental हों, जैसे किसी mature tool में, तब यह ठीक है; लेकिन कुछ बिल्कुल नया बनाते समय ideas छूट जाने का जोखिम रहता है
  • 2011 में पेशेवर करियर शुरू करने के आसपास designers should code पर बहुत चर्चा होती थी, और आलोचकों का कहना था कि programming शुरू करने पर ideas में बड़े बदलाव करना कठिन हो जाता है
  • मुझे websites बनाना और programming पसंद था, इसलिए मैंने code लिखना जारी रखा; लेकिन React जैसे frontend frameworks आम होने और frontend development के जटिल होने के बाद मैंने specialization चुना
  • व्यक्तिगत React projects ने developers के साथ बेहतर interaction में मदद की, लेकिन नौकरी में लगभग सारा समय Figma और documents में बीतता था
  • अगर LLM से पहले Jane Street join किया होता, तो शायद मैं Figma में और गहराई से फँस गया होता; JavaScript के विपरीत, OCaml और Bonsai मेरे लिए पूरी तरह नए थे, इसलिए technical contribution कुछ दूर और लगभग छू न सकने वाली चीज़ लगती
  • अब मैं फिर से वास्तविक output बना रहा हूँ, उसी medium में काम कर रहा हूँ, और कुछ भी आज़माने की आज़ादी पहले से ज़्यादा महसूस होती है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
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 को छूकर देख और अनुभव कर सकें