प्रोडक्ट डिज़ाइन बदल रहा है

• AI टूल्स सीधे design system का इस्तेमाल करके UI जनरेट कर रहे हैं, जिससे डिज़ाइनर की भूमिका साधारण visual design से हटकर रणनीति और समन्वय-केंद्रित हो रही है
• अब मुख्य सवाल “किसका काम कौन छीन रहा है” नहीं, बल्कि प्रोसेस कैसे बदल रहा है है
• कोड, PRD, सारांश जैसे अदृश्य काम को ऑटोमेट करना आसान है, लेकिन UI और flow जैसे दिखने वाले काम, जिन्हें यूज़र सीधे देखते और छूते हैं, उनमें क्वालिटी का अंतर बड़ा होता है, इसलिए डिज़ाइन ऑटोमेशन की रफ्तार अभी इंजीनियरिंग जितनी नहीं है
• Figma mockup को कोड में अनुवाद करने की प्रक्रिया सबसे बड़ा bottleneck रही है, लेकिन अगर डिज़ाइनर सीधे code environment में डिज़ाइन करें, तो यह handoff वाली बर्बादी पूरी तरह हट सकती है
• AI युग में डिज़ाइनर की असली वैल्यू pixel-level काम नहीं, बल्कि orchestration capability है: क्या बनाना है यह तय करना, AI output का आलोचनात्मक मूल्यांकन करना, और काम को निर्देशित करना
• जो कंपनियाँ छोटे empowered teams और machine-readable design systems में निवेश करेंगी, वे बड़े feature factory संगठनों पर भारी पड़ेंगी

---

प्रोडक्ट डिज़ाइन में बदलाव की पृष्ठभूमि

• 1999 में Dreamweaver से अपनी पहली वेबसाइट बनाने के बाद, लेखक Photoshop, Sketch, Figma आदि में डिज़ाइन बनाकर उसे डेवलपर तक पहुँचाने वाले तरीके से काम करते रहे हैं
• हाल ही में Claude Code को अपनी design system से जोड़कर उन्होंने सिर्फ तीन prompts में वास्तव में काम करने वाला UI जनरेट किया, और पारंपरिक visual design चरण को पार कर गए
• इस अनुभव से यह स्पष्ट हुआ कि डिज़ाइनर की वैल्यू execution ability से ‘taste और strategic judgment’ की ओर शिफ्ट हो रही है
• AI जब design system के आधार पर ‘prompt → generation → deployment’ फ्लो लागू कर रहा है, तब प्रोडक्ट डिज़ाइन में बुनियादी बदलाव चल रहा है

गलत बहस: हेडकाउंट नहीं, प्रोसेस का बदलाव

• AI और product roles पर मौजूदा चर्चा अभी भी “क्या डिज़ाइनर नौकरियाँ खो देंगे”, “क्या इंजीनियर replace हो जाएँगे” जैसी हेडकाउंट-केंद्रित क्षेत्रीय खींचतान तक सीमित है
• असली सवाल प्रोसेस का है: AI इन भूमिकाओं को खत्म नहीं कर रहा, बल्कि कौन क्या करेगा, कितनी तेजी से करेगा, और bottleneck कहाँ शिफ्ट होगा, यही मुद्दा है
• coding, PRD writing, data analysis जैसे अदृश्य काम (invisible work) को ऑटोमेट करना आसान है, क्योंकि UI के पीछे क्वालिटी का अंतर छिपा रह सकता है
  • कोड messy हो लेकिन app चल जाए, तो किसी को फर्क नहीं पड़ता; PRD AI से बना हो, लेकिन problem definition सही हो, तो भी कोई दिक्कत नहीं
• इसके उलट user interface, flow और experience जैसे दिखने वाले काम (visible work) में क्वालिटी का फर्क तुरंत दिखता है और यूज़र उसे तुरंत महसूस करता है
• जब build करना तेज़ और सस्ता हो जाता है, तब सवाल “इसे कैसे बनाएँ” नहीं, बल्कि “क्या बनाना सच में योग्य है” सबसे कठिन समस्या बन जाता है
• AI-assisted design की स्पीड इंजीनियरिंग की तुलना में पीछे रहना लगभग तय है, और यही असमरूपता पूरे product development process और team structure को फिर से आकार देगी

दिखने वाला काम: डिज़ाइन दीवार के पीछे नहीं, खुद दीवार है

• इंजीनियरिंग की तुलना plumbing से की जा सकती है — वह दीवार के पीछे छिपी होती है, और अगर नल से पानी आ रहा है तो अंदर की संरचना मायने नहीं रखती
  • Boris Cherny एक साथ 4~5 coding agents चलाकर 400% से अधिक speed gain हासिल कर चुके हैं, और Silicon Valley के इंजीनियर अब खुद कोड लिखने के बजाय agents की टीम को orchestrate करने की ओर बढ़ रहे हैं
• software design खुद दीवार भी है, नल भी, और हैंडल भी; इसलिए भले AI ने बनाया हो, यूज़र उसकी शक्ल और feel पर संवेदनशील प्रतिक्रिया देते हैं
• AI training data में मौजूद standards और patterns को फॉलो कर सकता है, लेकिन दर्जनों user interviews, survey results, usage analysis, competitive audit जैसी विशाल user research-आधारित decision making को संभालना मुश्किल है, क्योंकि उसका context बहुत बड़ा होता है
• यहाँ ingestion problem नाम का bottleneck मौजूद है — AI चाहे बहुत सारा कोड या meeting summaries बना दे, लेकिन इंसानों को उसे पढ़ना, आत्मसात करना और आलोचनात्मक रूप से परखना ही होगा, तभी बौद्धिक बातचीत और निर्णय संभव हैं
  • code review अब वास्तविक bottleneck बन रहा है, और यह human speed की सीमा है, जिसे कोई model पार नहीं कर सकता
• AI content generation और summarization में बहुत अच्छा है, लेकिन सचमुच कुछ नया रचने या taste रखने की क्षमता अभी साबित नहीं हुई है

Figma नहीं, कोड में डिज़ाइन करना

• product development का सबसे बड़ा bottleneck Figma mockup को production code में अनुवाद करने वाला designer-developer handoff है
  • सॉफ़्टवेयर की तस्वीर बनाना, pixels ठीक करना, इंजीनियर को सौंपना, फिर QA का mockup के मुकाबले code जाँचना, और typography या spacing mismatch पर PR reject करना — यह सब बहुत बड़ी अक्षमता पैदा करता है
• AI इस bottleneck को हटा सकता है, लेकिन तभी जब डिज़ाइनर सीधे code environment में डिज़ाइन करें
• कुछ डिज़ाइनर सचमुच Figma subscription रद्द करके AI tools पर जा रहे हैं; मुख्य तर्क यह है कि mockup खुद product नहीं, बल्कि एक समानांतर output है, जिसे अनुवाद, समीक्षा और समायोजन की ज़रूरत पड़ती है
  • Figma में धकेला गया हर pixel इंजीनियर के लिए एक अलग माध्यम में निभाई जाने वाली प्रतिबद्धता है, और design tool जितना production code से दूर होगा, handoff में उतनी ही ज़्यादा बर्बादी होगी
• Claude Code में design system repo दिखाकर सिर्फ तीन prompts में काम करने वाला UI जनरेट करने वाले प्रयोग ने इसे साबित किया
  • बड़े पैमाने पर विश्वसनीयता के लिए मजबूत documentation, explicit rules, और agent orchestration चाहिए, लेकिन बुनियाद पहले से मौजूद है
• Monday.com engineering team का उदाहरण: Figma link को Cursor में paste करने की पहली कोशिश में बना code design system components का उपयोग नहीं कर रहा था, colors hardcode थे, और typography system defaults को override कर रही थी
  • समाधान के रूप में उन्होंने design system MCP (Model Context Protocol) बनाया — components, tokens, accessibility rules और usage patterns को machine-readable बनाया, और 11-node के agentic workflow से model के लिए structured context तैयार किया
  • यह ऐसा तरीका है जिसमें agent सीधे code नहीं लिखता, बल्कि पहले यह समझ बनाता है कि code कैसा होना चाहिए, और फिर उसे डेवलपर के coding agent को सौंपता है — “orchestration, not magic”
• Anthropic के डिज़ाइनर Claude Code और console products में सीधे pull requests submit कर रहे हैं और production में deploy भी कर रहे हैं — फरवरी 2026 तक यह पहले से वास्तविकता है

इंसानों के लिए क्या बचेगा: orchestration और judgment

• अगर AI code generation, PRD writing, research summarization और interface prototyping सब कर सकता है, तो इंसानों के हिस्से में orchestration ही बचेगा
  • models काफी सक्षम हैं; bottleneck कीबोर्ड के सामने बैठा इंसान है — क्या माँगना है, काम को कैसे बाँटना है, और model के output को कब reject करना है, यही असली क्षमता है
• Kyle Zantos, जो अपने काम के समय का 70% terminal में बिताने वाले डिज़ाइनर हैं, ज़ोर देते हैं कि 4 महीने पहले की recommendation भी पुरानी हो सकती है, इसलिए खास tool settings से ज़्यादा philosophy और approach सीखना महत्वपूर्ण है
• SAP के Chief Design Officer Arin Bhowmick के अनुसार, visually polished interfaces कई बार unreliable output, opaque decision-making, और edge cases में कमजोर behavior जैसी गहरी समस्याओं को छिपा सकते हैं
  • design leaders को सतही polish नहीं, बल्कि trust, clarity, और reliability को first-class design outcomes की तरह लेना होगा
• Vlad Derdeicea के अनुसार, design lead का लगभग 80% समय communication, alignment और justification में जाता है, जबकि hands-on design में सिर्फ 20%
  • हर design decision पर एक “justification tax” होता है — यानी उन विकल्पों को समझाने, दस्तावेज़ करने और बचाव करने में लगने वाला समय, जिन्हें दूसरे domains में छोटी बातचीत से निपटा दिया जाता
  • AI को mockup work नहीं, बल्कि इसी 80% हिस्से को target करना चाहिए: meeting notes को synthesize करना, stakeholder communication draft करना, research summary बनाना, और opinion की जगह data से बहस सुलझाने वाले quick prototypes तैयार करना
• Jan Tegze की framing: मौजूदा काम बेहतर करने की कोशिश मत करो, बल्कि domain में वे constraints खोजो जो human limits के कारण मौजूद हैं, और agents से उन्हें हटाओ — लक्ष्य वर्तमान काम को तेज़ करना नहीं, बल्कि पहले जो असंभव था उसे संभव बनाना है
  • “agents से compete मत करो, बल्कि ऐसी नई capability बनाओ जिसमें तुम और agents दोनों की ज़रूरत हो”
• 5 साल से कम अनुभव वाले junior designers ज्यादा जोखिम में हैं — क्योंकि उनमें AI output का मूल्यांकन करने की judgment और model की गलतियाँ पकड़ने का अनुभव कम होता है, और skill floor ऊपर उठ रहा है

छोटे टीमें, बड़ा leverage

• ज़्यादातर software कंपनियाँ आज की स्थिति के लिए सही ढंग से structured नहीं हैं — चाहे dedicated design support हो या नहीं, हर squad में PM रखने वाली PM-heavy feature factory अब भी आम है
  • PM की संख्या ZIRP दौर में इसलिए तेज़ी से बढ़ी क्योंकि यह revenue के क़रीब भूमिका मानी जाती है और संगठनात्मक जटिलता के साथ इसका headcount बढ़ता है
  • Marty Cagan इसे “product management theater” कहते हैं — roadmap बनाना और standup चलाना भर करने वाले, ज़्यादा वेतन पाने वाले project managers जैसे अप्रभावी PMs की भरमार
• Andrew Ng ने Davos में भविष्यवाणी की कि अगर AI engineering productivity को विस्फोटक रूप से बढ़ाता है, तो PM बनाम engineer ratio 1:8 से 1:1 की दिशा में पलट सकता है
  • जब AI agents ज़्यादातर production code लिखेंगे, तब बड़ा engineering base सिकुड़ेगा और specification और judgment दुर्लभ संसाधन बन जाएँगे
• Airbnb ने product management और product marketing को मिलाकर एक “full-stack” role बना दिया है
  • Brian Chesky: “अगर आप product के बारे में बात करना नहीं जानते, तो आप product बना भी नहीं सकते” — यानी storytelling और external communication को PM role का first-class हिस्सा बनाना
  • डिज़ाइनर्स को engineers के साथ product lead करने वाले “architects” तक उठाया गया है, न कि ticket लेकर काम करने वाली अधीनस्थ service role तक
  • पहले जो coordination work PM headcount बढ़ाता था, वह अब dedicated program managers को दिया गया है
• यह Apple के functional organization model जैसा है: experts, experts को lead करते हैं; CEO integration point होता है; और business unit चलाने वाले “mini CEO” PM नहीं होते
• AI युग की आदर्श टीम 2~3 engineers, 1 PM, 1 designer वाली छोटी empowered team है
  • design system core infrastructure बन जाता है, क्योंकि code में design system और documentation के बिना AI UI और implementation पर गलत निर्णय लेगा
  • जो कंपनियाँ machine-readable design systems और छोटे empowered teams में निवेश करेंगी, वे 15-सदस्यीय squads और 3-step approvals बनाए रखने वाली कंपनियों से आगे निकल जाएँगी

चक्रवृद्धि प्रभाव: orchestrator और pixel pusher के बीच बढ़ती खाई

• Claude Code से design system में काम करने वाली स्क्रीन जनरेट करने वाले प्रयोग के बाद, लेखक बेहतर documentation, सख्त component rules, और स्पष्ट composition guidelines के साथ लगातार सुधार कर रहे हैं
  • हर दौर के साथ नतीजे तेज़, production-ready के और क़रीब, और model improvement, skill refinement, तथा direction capability — सब कुछ चक्रवृद्धि रूप से जमा हो रहा है
• “AI को orchestrate करने वाले डिज़ाइनर” और “Figma में pixels धकेलने वाले डिज़ाइनर” के बीच की दूरी अगले 12 महीनों में बहुत बड़ी हो सकती है
  • ऐसा इसलिए नहीं कि pixel pusher अयोग्य हैं, बल्कि इसलिए कि orchestrator मूल रूप से अलग speed और scope पर काम करता है — जब दूसरे handoff meeting के लिए mockup भेज रहे होते हैं, तब वह काम करने वाला UI deploy कर रहा होता है
• लेखक अपनी टीम को यह तरीका सिखा रहे हैं, क्योंकि नौकरी खत्म नहीं हो रही, बल्कि यह ऐसी नौकरी में बदल रही है जहाँ taste, judgment, और काम को निर्देशित करने की क्षमता चित्र बनाने की क्षमता से ज़्यादा महत्वपूर्ण है