‘मॉडल डिज़ाइनर’ का उदय: AI प्रोडक्ट्स में डिज़ाइन की भूमिका बदल रही है

• AI प्रोडक्ट डिज़ाइन में 8+ वर्षों का अनुभव रखने वाले Barron Webster इस समय Figma में दुनिया की पहली 'मॉडल डिज़ाइनर' भूमिका निभा रहे हैं, जो इस बात का संकेत है कि डिज़ाइनर अब LLM के साथ सीधे काम करने वाली नई हाइब्रिड भूमिका में उभर रहे हैं
• मॉडल डिज़ाइनर का मुख्य काम foundation models की सीमाओं की भरपाई करना और AI फीचर्स के डिज़ाइन के लिए नए tools और सोचने के तरीके को डिज़ाइन संगठन में लाना है
• पारंपरिक UI डिज़ाइन के विपरीत, AI प्रोडक्ट डिज़ाइन में पहले मॉडल के व्यवहार का prototype बनाना और उसके बाद UI डिज़ाइन करना ज़रूरी है; नहीं तो ऐसा UI बनने का जोखिम है जो वास्तविक कामकाज से मेल न खाए
• Evals सिस्टम बनाना AI प्रोडक्ट की quality management का मूल है, और डिज़ाइनरों को ऐसे tools चाहिए जिनसे वे तेज़ feedback loop में evaluation cases को बदलकर चला सकें
• AI युग के डिज़ाइनरों के लिए मॉडल की input-output संरचना को गहराई से समझना और पूरे सिस्टम को समझने की क्षमता अनिवार्य है; उन्हें सिर्फ UI बनाने वाला नहीं, बल्कि निर्णय-प्रक्रिया में भागीदार होना चाहिए

---

Barron Webster का परिचय

• ऐसे डिज़ाइनर जिन्होंने 8 साल से अधिक समय तक AI प्रोडक्ट्स में गहराई से काम किया है, और hype cycle को भेदकर देखने की अंतर्दृष्टि रखते हैं
• Google Creative Lab में 2017 में लॉन्च हुए Teachable Machine के डिज़ाइन में भाग लिया; यह उपभोक्ताओं के लिए AI मॉडल को train कराने वाला पहला tool था
• इसके बाद Replit में AI फीचर्स पर काम किया और startup से unicorn बनने की यात्रा में योगदान दिया
• हाल ही में Figma में दुनिया के पहले मॉडल डिज़ाइनर के रूप में शामिल हुए

मॉडल डिज़ाइनर की भूमिका

• Figma AI research team का हिस्सा होकर, दो प्रमुख मिशन निभा रहे हैं
  • ऐसी स्थितियों का समाधान करना जहाँ foundation model से अधिकतम performance निकालने पर भी पर्याप्त न हो
  • Figma का data proprietary format में होने के कारण foundation model उसे ठीक से संभाल नहीं पाते, इसलिए इस gap को भरने का काम
• डिज़ाइन संगठन में नए tools और AI-first mindset लाना
  • Figma एक बड़ी कंपनी है, इसलिए कई डिज़ाइनरों के पास AI experience डिज़ाइन करने का अनुभव नहीं है
  • AI फीचर डिज़ाइन पारंपरिक product design से अलग है
• लक्ष्य ऐसे tools बनाना है जिनसे डिज़ाइनर engineer बने बिना भी process की शुरुआती अवस्था में AI फीचर के मूल को prototype कर सकें
  • अगर किसी ऐसे फीचर का UI डिज़ाइन किया जाए जिसे स्वयं अनुभव नहीं किया गया, तो वास्तविक व्यवहार से न मेल खाने वाले perfect-case UI का जोखिम रहता है

AI डिज़ाइन tools का भविष्य

• सबसे अधिक जिस tool की उम्मीद है, वह ऐसा है जिसमें डिज़ाइनर तेज़ feedback loop में evaluation cases को बदलकर चला सकें
  • अगर Figma file में AI फीचर काम न करे, तो उसे तुरंत test case के रूप में जोड़ा जा सके
  • system prompt बदलना, दूसरे model आज़माना आदि तुरंत संभव होना चाहिए
• अभी समस्या यह है कि feedback loop बहुत धीमा है
  • हर अच्छे डिज़ाइन tool का मूल feedback loop को हटाना या छोटा करना है
  • evaluation set बनाने का बड़ा हिस्सा data साफ़ करने के manual काम में चला जाता है
• Figma में AI फीचर्स को अलग कैसे बनाया जाए, इस पर भी विचार जारी है
  • क्योंकि यह एक design platform है, इसलिए Claude Code या Cursor की तुलना में बेहतर डिज़ाइन किए गए outputs की उम्मीद है
  • targeted evaluation strategy और अच्छे डिज़ाइन के proxy ढूँढना अहम है
  • यह art school स्तर का एक दार्शनिक सवाल भी है

Barron का AI में शुरुआती अनुभव

• 2014-2015 RISD Computer Utopias class: LLM से पहले का दौर, जब machine learning research classifier-केंद्रित थी
  • image classification models सबसे दिलचस्प थे, जो Snapchat face filters या Google image search को चलाते थे
  • content moderation और recommendation systems मुख्य चर्चा के विषय थे
  • Facebook, Twitter, Cambridge Analytica के चरम दौर में algorithmic feed के आविष्कार ने डिज़ाइन के लिए नई सामग्री पैदा की
• 2016-2018 Google Creative Lab: Google Lens, Google Assistant, Teachable Machine पर काम
  • लगभग हर project में model innovation का उपयोग हुआ
  • text generation नहीं, बल्कि मौजूदा content को sort या annotate करने के लिए models का उपयोग
  • जापान के एक cucumber farmer द्वारा TensorFlow से खीरे classify करने के उदाहरण का promotion किया

Replit में अनुभव

• 3 साल से अधिक समय तक काम किया, और उस समय से शुरू किया जब कोई AI फीचर नहीं था; बाद में AI के उपयोग के तरीकों का आकलन करने की भूमिका निभाई
• models लगातार बेहतर होते जाने पर नई क्षमताओं का उपयोग करते हुए भरोसेमंद AI फीचर्स कैसे जोड़े जाएँ, इस पर काम किया
• शुरुआत बुनियादी manual trigger फीचर्स से हुई (code select करके AI से explanation, मौजूदा file में code generate करना)
• हर फीचर रिलीज़ के बाद user expectations बढ़ने का चक्र दोहराया गया
  • code snippet generation की अनुमति → पूरी file/project की मांग
  • पूरी generation संभव → specific edits की मांग
  • specific edits संभव → शुरू से नया बनाने की मांग
• मौजूदा model से फीचर आज़माना → न हो तो इंतज़ार → नया foundation model आने पर फिर प्रयास वाला पैटर्न
• programming environment की product constraints
  • model code लिखने में अच्छा हो, तब भी सही जगह edit करने का तरीका चाहिए
  • Sonnet 3.5 से पहले तक models line numbers संभालने में कमज़ोर थे
  • edit accuracy, content duplication रोकना, function replacement के लिए अस्थायी workarounds बनाने पड़े
  • इस तरह का ज़्यादातर काम 6 महीने से 1 साल बाद नए models आने पर बेकार हो जाता था

user validation की ओर बदलाव का उदाहरण

• जब Replit agent अपने आप files बनाता और code लिखता था, तब agent द्वारा बनाई गई application को test करना एक बड़ी technical समस्या थी
  • उदाहरण: login page काम करता है या नहीं, इसकी जाँच
• engineering पक्ष का approach: sandbox चलाना, screenshot feature बनाना, और multimodal model को screenshot देकर click/input की जगह तय कराना
  • मूलतः model का कंप्यूटर-जैसा उपयोग लागू करना
• Barron और एक दूसरे engineer का प्रस्ताव: user को website दिखाकर उससे सीधे test करने को कहना
  • validation और testing को user पर offload करके पूरी जटिल technical समस्या को bypass कर दिया गया
• अगर टीम में कोई ऐसा हो जो technical problem नहीं बल्कि user problem पर फोकस करे, तो बहुत कुछ छोड़ा या सरल किया जा सकता है

product-market fit की खोज

• पारंपरिक pre-AI product strategy: planning, मौजूदा user base, market/category expansion strategy बनाना
• AI के तेज़ बदलाव के कारण Replit की strategy कहीं ज़्यादा reactive हो गई
• education market में मज़बूत product-market fit था, खासकर COVID के बाद remote education में
• AI फीचर्स बेहतर होने पर दुविधा पैदा हुई
  • indie developers और hackers AI को पसंद करते थे
  • teachers इसका विरोध करते थे क्योंकि छात्र बुनियादी सीखने को bypass कर सकते थे
• Replit agent लॉन्च के समय target user स्पष्ट नहीं था
  • top-down project की तुलना में फीचर रिलीज़ करके प्रतिक्रिया देखना अधिक सफल रहा
  • लॉन्च के बाद बातचीत से users मिले: tech कंपनियों के operations लोग, जिन्हें sales data collection या dashboard building की ज़रूरत थी (Zapier या Retool users जैसे)

Evals सिस्टम

• Replit के पहले 2 वर्षों में evaluations का ज़्यादा उपयोग नहीं हुआ; उस समय यह practice व्यापक नहीं थी
• agent में evaluations का अधिक सक्रिय उपयोग हुआ, मुख्यतः product development metric के रूप में
  • नया model रिलीज़ होने पर programming eval performance देखकर तय किया जाता था कि app testing करनी है या नहीं
• Sandbar में model personality के evaluations लिखने पर काफ़ी समय लगाया गया
  • व्यापक industry benchmark evaluations के अलावा product-specific evaluations बनाना एक नया डिज़ाइन कार्य था
• workflow: prompt लिखना → prompt को adjust करना → evaluations बनाना → performance देखना → manual testing और subjective feedback के साथ जोड़ना
• evaluations के बिना AI के काम करने की पुष्टि के लिए manual काम बहुत बढ़ जाता है
• Sandbar evals के उदाहरण
  • अगर जवाब न पता हो, तो hallucination की जगह एक ही, ठोस और specific clarification question पूछा जाए
  • एक बार में दो से अधिक सवाल नहीं
  • जवाब संक्षिप्त रखे जाएँ, अपवादों सहित

evaluations की कठिनाइयाँ

• sycophancy evaluation writing में सबसे कठिन विषयों में से एक है
  • यह विचार कि model को उचित स्थिति में user से असहमत होना चाहिए
  • स्वीकार्य failure rate तय करना एक product और design decision बन जाता है, और product की design philosophy का हिस्सा होता है
• कई बार evaluation results खराब होने का कारण performance गिरना नहीं बल्कि खराब लिखा गया eval होता है
  • उदाहरण: "बहुत संक्षिप्त होना चाहिए" वाले eval में अगर user कहे "मेरी माँ का देहांत हो गया" तो "यह दुखद है" जैसा उत्तर high score पा सकता है, लेकिन वह वास्तव में वांछित प्रतिक्रिया नहीं है
• evaluations का मुख्य उपयोग regression रोकने के लिए होता है, यह जाँचने के लिए कि गुण पूरे हो रहे हैं या नहीं
  • यह programming में test coverage जैसा है
• पारंपरिक programming के test-driven development (TDD) जैसी चीज़ AI engineering में अभी भी दुर्लभ है
  • यानी पहले eval लिखना और फिर उसे pass कराने वाला code लिखना
• भविष्य में evaluation designer नाम की भूमिका उभर सकती है
  • यह उस design systems role जैसा होगा जो dashboards डिज़ाइन करता है ताकि टीम AI performance को समझ सके

Figma में AI फीचर्स की कल्पना

• "design critique as a service" जैसी एक अवधारणा पर विचार हो रहा है
  • AI से design critique माँगना
  • इससे उस system की personality पर दिलचस्प सवाल उठते हैं
• चुने जा सकने वाले रवैये (जैसे "Dieter Rams" style) देना बनाम default सेट करना
• accessibility या contrast problems (ज़्यादा objective feedback) पर ध्यान देना बनाम अधिक व्यापक दायरा रखना
• यह अभी स्पष्ट नहीं कि इसका कितना हिस्सा वास्तविक product experience में आएगा

evaluation tools किस दिशा में बढ़ने चाहिए

• evaluation creation की iteration speed घटाने वाले tools की उम्मीद
• अभी evaluation पर काम करने वाले लगभग सभी लोगों को बुनियादी तौर पर यह करना पड़ता है
  • mapping, formatting, pipeline, outputs—इन सबको एक जगह देखने वाली interface जोड़ना
• text के लिए tools काफ़ी अच्छे हैं, लेकिन दूसरे formats के लिए कमी है
• Design Arena जैसी evaluation platforms मौजूद हैं
  • blind side-by-side test, जहाँ लोग अपनी पसंद के best output पर vote करते हैं
• ऐसी ही चीज़ सीधे Figma file के भीतर करना चाहेंगे
  • comments जोड़ना, issues इंगित करना शामिल हो
  • test set जल्दी बन सके, एक साथ चल सके, 100 responses मिलें और 30 सेकंड में iteration हो सके
  • अभी सारे pieces मौजूद हैं, लेकिन इसमें बहुत समय लगता है

model creation में डिज़ाइनर की भूमिका

• scratch से training बनाम fine-tuning दोनों तरह के approach का अनुभव
• scratch से training के समय: जहाँ user need सबसे अधिक हो और friction सबसे तीखा हो, उसे organization तक पहुँचाना डिज़ाइनर का सबसे बड़ा योगदान है
  • Replit में Python की आम और सरल code errors के लिए custom model training
  • वास्तविक training से अधिक, problem definition और trained model को product में कैसे लागू किया जाए इस पर काम
• fine-tuning के समय: जब मौजूदा model, product, और evaluations हों और performance बेहतर चाहिए
  • prompt लिखने, evaluations बनाने और user conversations करने वाला व्यक्ति अच्छी तरह समझता है कि अपेक्षाएँ पूरी हो रही हैं या नहीं
  • जब prompt engineering सीमा पर पहुँच जाए, तो fine-tuning अगला कदम बनती है
• डिज़ाइनर की मुख्य translation role: user assumptions को याद रखना
  • model के साथ गहराई से काम करने वाले engineers/designers भूल सकते हैं कि users को ये बारीकियाँ नहीं पता
  • अपने "अंदर के मूर्ख" का उपयोग करके यह बताना ज़रूरी है कि AI model की विशेषताओं से अनजान भोला user क्या कोशिश करेगा और कहाँ अटकेगा

AI product designers के लिए सलाह

• सबसे टिकाऊ और प्रभावशाली काम: model के inputs और outputs को सच में समझने में पहले से काफ़ी समय लगाना
  • prompt क्या है, कौन-सी user information input में जाती है, कौन-से tools call किए जा सकते हैं, कौन-से evaluations हैं
  • इन dials को बदलने पर क्या होता है, इसकी सहज समझ बनाना
• ऐसे output का UI बनाने वाले मत बनिए जिसे आप गहराई से समझते ही नहीं
  • अगर कहा जाए, "model यह दे रहा है, अब interface design करो," तो यह किया जा सकता है, लेकिन user insight के आधार पर सुधार सुझाना मुश्किल होगा
  • और फिर आपका काम बाद के model changes पर बहुत reactive हो जाएगा
• नया फीचर वास्तव में वांछित है या नहीं, इसमें decision-making का हिस्सा बनना चाहिए, सिर्फ receiver नहीं
• यह उन डिज़ाइनरों के लिए कठिन हो सकता है जो code से परिचित नहीं हैं
  • Langsmith जैसी interface हो, या development environment खुद चलाना सीखना पड़े

सबसे बड़ा प्रभाव डालने वाले उदाहरण

• Replit agent: टीम को मनाया कि generated application के काम करने की जाँच user से सीधे कराई जाए
  • user validation के सबसे सरल रास्ते पर फोकस करके बहुत मेहनत बचाई गई
• LaMDA launch (Google का शुरुआती LLM): अलग-अलग तरीकों से model को आज़माने और यह देखने में बहुत समय लगाया कि क्या सबसे अच्छा काम करता है
  • उस समय इसे "prompting" नहीं कहा जाता था, लेकिन model से अलग-अलग भूमिकाएँ निभवाकर विश्वसनीय व्यवहार निकालने की कोशिश की जाती थी
  • Pluto या उसके उपग्रहों से बातचीत करने वाला demo असंख्य प्रयासों के बाद सबसे अच्छा काम करने वाले रूप के रूप में मिला
  • व्यापक experimentation के बिना रणनीतिक चुनाव संभव नहीं था

डिज़ाइनरों के लिए prompting

• "क्या डिज़ाइनरों को prompt करना चाहिए" का स्वभाव "क्या डिज़ाइनरों को code करना चाहिए" से अलग है
• coding के मामले में जवाब काफ़ी हद तक falsifiable होता है: क्या ABC तकनीक से XYZ बनाया जा सकता है? engineer से पूछना लगभग सीधे जानने के बराबर हो सकता है
• AI model behavior स्वभावतः अधिक subjective और nuanced होता है
  • इसलिए उस माध्यम को गहराई से स्वयं समझने का कोई विकल्प नहीं है

क्या यह अब भी डिज़ाइन है

• यह behavior को design करना है; यह कभी पूरी तरह perfect न भी हो, तो भी ठीक है
• यह उस UI design mindset से अलग है जहाँ हर pixel पर पूरा नियंत्रण होता है और perfection को पुरस्कृत किया जाता है
• फिर भी mockups बनाना और design tools का उपयोग जारी रहता है
• Figma में evaluation cases बनाना, outputs की समीक्षा करना, awkward हिस्सों को सुधारना
• यह लगभग therapeutic है, fidget spinner जैसा
  • अगर एक website mockup और 30 मिनट मिल जाएँ, तो typography सुधारते हुए खुशी मिलती है
• जब तक फीचर हटाया न जाए, यह कभी वास्तव में समाप्त न होने वाला काम है; हमेशा सुधार की गुंजाइश रहती है