मैं अब Figma से ज़्यादा Claude के साथ डिज़ाइन करता हूँ
Claude Design जैसे AI-assisted “vibe coding” टूल्स कई डेवलपर्स और प्रोडक्ट टीमों के लिए Figma और पारंपरिक वायरफ़्रेमिंग की जगह लेना शुरू कर रहे हैं, क्योंकि वे पाते हैं कि किसी LLM को प्रॉम्प्ट देकर हाथ से डिज़ाइन सॉफ़्टवेयर में बनाने की तुलना में इंटरैक्टिव फ्रंट-एंड प्रोटोटाइप बहुत तेज़ी से बनाए जा सकते हैं। टिप्पणीकार गति, iteration, और गैर-इंजीनियरों को सशक्त बनाने में वास्तविक लाभ बताते हैं, लेकिन साथ ही सामान्य, एक जैसे UIs, edge cases को खराब तरीके से संभालने, और इस जोखिम की चेतावनी भी देते हैं कि stakeholders नाज़ुक प्रोटोटाइप्स को production-ready सिस्टम समझ लें। एक बार-बार उठने वाली चिंता यह है कि शुरुआती डिज़ाइन और architectural thinking को मॉडल्स को सौंपना clarity को कम कर सकता है, इंजीनियरों पर maintenance का बोझ बढ़ा सकता है, और तेज़ experimentation तथा ज़िम्मेदार software quality के बीच तनाव को गहरा कर सकता है.
UI डिज़ाइन और प्रोटोटाइपिंग के लिए Claude/LLMs का उपयोग
- कई टिप्पणीकार अब फ्रंटएंड, वायरफ़्रेम, और काम करने वाले प्रोटोटाइप बनाने के लिए Claude Design / Claude Code (और ऐसे ही अन्य टूल्स) का उपयोग करते हैं, अक्सर Figma से पहले या उसकी जगह।
- सामान्य पैटर्न: LLM के साथ कोड में प्रोटोटाइप बनाना, फिर Figma या किसी मौजूदा डिज़ाइन सिस्टम में उसे विज़ुअली परिष्कृत करना।
- कुछ टीम वर्कफ़्लो: डिज़ाइनर/प्रोडक्ट LLM के साथ इंटरैक्टिव प्रोटोटाइप बनाते हैं, फिर इंजीनियर बाद में उन्हें “वास्तव में” दोबारा लागू करते हैं, और प्रोटोटाइप को जीवंत प्रस्ताव दस्तावेज़ की तरह इस्तेमाल किया जाता है।
प्रॉम्प्टिंग, रचनात्मकता, और सामान्य आउटपुट
- विस्तृत सौंदर्यात्मक दिशा के बिना, मॉडल सुरक्षित, ट्रोप-भरे डिज़ाइनों की ओर झुकते हैं (Tailwind/Bootstrap क्लोन, “boarding pass” ट्रैवल UIs, आदि)।
- उपयोगकर्ताओं को अधिक मौलिकता तब मिलती है जब वे:
- अपरंपरागत रेफ़रेंस साइट्स या UI उदाहरण देते हैं।
- फ़ॉन्ट, लेआउट सीमाएँ, और ब्रांड/स्टाइल संकेत निर्दिष्ट करते हैं।
- तब भी, आउटपुट अक्सर विज़ुअली समान लगते हैं और लेआउट सीमाओं के साथ संघर्ष करते हैं (जैसे, बहुत लंबे स्लाइड्स)।
वर्कफ़्लो, भूमिकाओं, और स्पेक्स पर प्रभाव
- कुछ डिज़ाइनर/PMs खुद को UI और लॉजिक को “vibe code” करने में सक्षम महसूस करते हैं, जिससे शुरुआती iterations के लिए इंजीनियरों पर निर्भरता कम होती है।
- फ्रंटएंड इंजीनियर नई ज़िम्मेदारियों की रिपोर्ट करते हैं:
- गंदे AI-जनित PRs की समीक्षा करना।
- इच्छित व्यवहार और अनजाने “slop” के बीच अंतर करना।
- कम लिखित स्पेक्स और प्रोटोटाइप्स की अधिक reverse-engineering से निपटना।
- दूसरों को यह पसंद है कि प्रोटोटाइप केवल मौखिक/टेक्स्ट स्पेक्स की तुलना में आवश्यकताओं को अधिक ठोस बनाते हैं।
गुणवत्ता, रखरखाव, और जोखिम
- कई इंजीनियर LLM आउटपुट की तुलना एक जूनियर डेवलपर से करते हैं: उपयोगी, लेकिन छिपे हुए बग्स, छूटे हुए edge cases, और गलत धारणाओं से भरा हुआ।
- LLMs को कंपाइलरों की तरह “उच्च abstraction layer” मानने के विरुद्ध प्रतिक्रिया है, क्योंकि आउटपुट deterministic या भरोसेमंद रूप से सही नहीं होता।
- चिंता है कि गैर-तकनीकी stakeholders प्रोटोटाइप कोड को “95% पूरा” मान लेंगे और उसे जल्दी production में बदलने की मांग करेंगे, जबकि robustness, security, और data-integrity के काम को कम आँकेंगे।
AI और टूल्स के प्रति व्यापक दृष्टिकोण
- भावना विभाजित है:
- तेज़ iteration, tweaks के लिए अनंत धैर्य, और छोटे संगठनों या NGOs को महंगे contractors की जगह लेने में सक्षम बनाने को लेकर उत्साह।
- hype, “cult-like” inevitability narratives, और corporate marketing (AI में निवेशित trading firms सहित) को लेकर संदेह।
- कुछ लोग AI को disposable UI, images, और low-risk web pages के लिए विशेष रूप से उपयुक्त मानते हैं; अन्य चिंतित हैं कि यह गहरी सोच और डिज़ाइन rigor को कमज़ोर करता है।
- चर्चा में Figma का भविष्य, वहाँ AI features की perceived कमजोरी, और traditional design तथा website-building tools पर दबाव के शुरुआती संकेत शामिल हैं।