Claude Design पर विचार और impressions

 (samhenri.gold)
10 पॉइंट द्वारा GN⁺ 2026-04-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डिज़ाइन को systematize करने पर ज़ोर बढ़ने के साथ Figma ने components, styles, variables, props जैसी अपनी units के इर्द-गिर्द जटिल संरचना खड़ी की, और वास्तविक implementation medium से दूरी पैदा हो गई
  • Figma का proprietary format स्वाभाविक रूप से LLM training data से बाहर रह गया, और agent युग में code-based tools के उभरने के साथ डिज़ाइन का source of truth फिर से code की ओर खिसकने लगा
  • Claude Design HTML/JS को सीधे संभालने वाला ईमानदार medium है, जो Figma की तरह code की lossy approximation से गुज़रे बिना सीधे वास्तविक implementation medium में काम करने का तरीका अपनाता है
  • Claude Code के साथ सिब्लिंग relationship के कारण डिज़ाइन और implementation के बीच feedback loop को एक ही conversation में समेटने की structural strength मौजूद है
  • डिज़ाइन टूल बाज़ार code-based tools और pure exploration tools में बंटता दिख रहा है, और Figma के Sketch के रास्ते पर चल पड़ने की संभावना बन गई है **Sketch moment**

Figma के systematization का paradox

  • product teams का आकार बढ़ने के साथ डिज़ाइन को engineering organization के भीतर अपने अस्तित्व को justify करना पड़ा, और इसी कारण उसे systematization की दिशा में धकेला गया
  • इसके लिए Figma ने components, styles, variables, props जैसी proprietary primitives गढ़ीं, लेकिन कुछ programming से ली गईं और कुछ नहीं, इसलिए उनका किसी एक चीज़ से साफ-सुथरा correspondence नहीं बनता
  • guidelines लगातार बदलती रहीं, migrations जमा होती गईं, और automation करने के लिए कुछ low-quality plugins पर निर्भर रहना पड़ता है
  • जटिलता इतनी बढ़ गई कि इस system को manage करने में विशेषज्ञ डिज़ाइन roles भी अलग से पैदा हो गए

Source of Truth का स्थानांतरण

  • Figma और code के बीच हमेशा यह तनाव रहा कि source of truth आखिर क्या होना चाहिए

  • Sketch को हराने के बाद Figma ने यह रुख अपनाया कि उसका tool ही canonical बनेगा

  • लेकिन इस जीत की छिपी हुई कीमत थी: locked-down, ज़्यादातर undocumented format को programmatically संभालना कठिन था, इसलिए वह स्वाभाविक रूप से LLM training data से बाहर हो गया

  • LLMs ने code पर training पाई है, Figma primitives पर नहीं, इसलिए models Figma की system को सीख ही नहीं पाए

  • जैसे-जैसे code लिखना designers के लिए भी आसान हुआ और agents बेहतर हुए, source of truth स्वाभाविक रूप से फिर code की तरफ लौटता दिख रहा है

  • इसके सामने Figma ने पिछले 10 साल में जो जटिल infrastructure जोड़ा, वह ज़रूरत से ज़्यादा लग सकता है

    "अगर आपको मिट्टी के बर्तन बनाने हैं, तो आप उनके watercolor sketches क्यों बना रहे हैं? सीधे मिट्टी को आकार क्यों न दें?"

Figma के अपने design system की जटिलता

  • वास्तविक काम में code में सीधे किए गए design changes को Figma में back-port करना बेहद कठिन होता है
  • उदाहरण के तौर पर Figma के अपने product के design system files का ज़िक्र है, और सबसे सक्षम design system team के बनाए होने के बावजूद वे अत्यधिक जटिल दिखते हैं
    • 946 color variables हैं, जो "bg/desktopBackgrounded" जैसे nested groups में बने हैं, और एक variable में Light, Dark, FigJam-Light सहित 8 mode-specific values मौजूद हैं
    • modal footer component में 12 variants हैं, और "DS Library Swap", "QA Plugin" जैसे values वाले dropdowns तथा 8 props शामिल हैं
    • slider component की effect style में सिर्फ 0.5px drop shadow के लिए अलग नाम वाली style मौजूद है — क्योंकि CSS variables के साथ correspondence document करने का यही एकमात्र तरीका है
    • combo input component में 16 variants हैं, और layer names "Default, Default, Close Button=False" जैसे रूप में हैं
  • जब colors गलत दिखते हैं, तो debugging के लिए component check करना → variable check करना → alias किए गए दूसरे variable को देखना → mode देखना → instance-level override देखना → library swap लगे nested components को देखना जैसी multi-step tracing करनी पड़ती है

Figma Make vs Claude Design

  • source of truth के code की ओर जाने के साथ Figma एक passive, pre-agentic system लेकर असहज स्थिति में खड़ा है
  • आगे डिज़ाइन tools दो स्पष्ट रूपों में बँट सकते हैं
    • 2016 में Figma ने जिस सवाल का जवाब दिया था — "एक designer के तौर पर मेरी idea को सबसे तेज़ी से बाहर निकालने वाला tool कौन-सा है?" — उस पर प्रतिस्पर्धा फिर से शुरू हो सकती है
  • Figma Make पहले से Figma system के अभ्यस्त लोगों के लिए tool है
    • यह Figma styles, component libraries, proprietary props (Prop Props) को पढ़ता है, और इस नए environment में भी design file को ही canonical मानने वाला लगभग अकेला tool है
    • यह उन लोगों के लिए tool है जो system के भीतर रहना चाहते हैं, या जिनके पास वही विकल्प है
  • Claude Design इसके ठीक उलट दांव है
    • Arts and Crafts movement के "truth to materials" सिद्धांत — यानी किसी वस्तु का अपने substance और निर्माण के तरीके के प्रति ईमानदार होना — के अधिक नज़दीक
    • इसके उलट Figma को बेहद rigid schema के ऊपर चढ़ी एक मुक्त "vibe" layer की तरह बताया गया है — जैसे Type A personality ज़बरदस्ती relaxed दिखने की कोशिश करे, जबकि भीतर frames की nesting और token separation पर चीख रही हो
    • Claude Design खुरदरा ज़रूर है, लेकिन कम-से-कम अपनी असलियत को लेकर ईमानदार है: आख़िर तक HTML और JS

Claude Design की structural strength

  • Claude Design का sibling ऐसा Claude Code है जो code को अच्छी तरह संभालता है — यही इसकी मुख्य structural advantage है
  • अंततः Claude Design से Claude Code में सीधे handoff, या उलटा handoff संभव होने वाली structure बनती है
  • Claude Design के onboarding में पहले से repository (repo) import फीचर दिया गया है
  • डिज़ाइन और implementation के बीच का feedback loop — जो ऐतिहासिक रूप से हमेशा friction का कारण रहा — एक ही conversation में सिमट सकता है

Code से असंबंधित दूसरे tools की संभावना: pure exploration environment

  • इस विभाजन की दूसरी धुरी पर ऐसे tools उभर सकते हैं जिनमें code से कोई अपेक्षा ही न हो
  • rectangles रखना, layer styles जमाना, blend modes और gradients के साथ खुलकर काम करना — यानी ऐसा pure exploration environment जो किसी system या prompt rule से बंधा न हो
  • यह iPad + Pencil support वाले app में जल्दी-जल्दी rectangles sketch करने जैसा हो सकता है, या 37signals किसी दिलचस्प प्रयोग की दिशा में जा सकता है
  • दूसरी दिशा में यह Photoshop की तरह high-fidelity compositing पर पूरा ज़ोर देकर CSS effects की सीमाओं से बाहर कल्पना को मुक्त करने वाला tool बन सकता है
  • यह अजीब लगता है कि Figma ने अपनी उम्र के 90% हिस्से तक layer effects में सिर्फ drop shadow या blur ही दिए

Figma का "Sketch moment"

  • Figma का Sketch moment — यानी जैसे Sketch को Figma ने पीछे छोड़ा था, वैसे ही Figma के पीछे छूटने का क्षण — तेज़ी से नज़दीक आ रहा है

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

1 टिप्पणियां

 
GN⁺ 2026-04-19
Hacker News की राय

  • मैंने आज पहले बनाए गए design system को logo, branding और font तक जोड़कर फिर से परखा, और इतना बार-बार बदलाव करना पड़ा कि झुंझलाहट होने लगी; आखिरकार मुश्किल से संतोषजनक नतीजा मिला
    लेकिन usage देखा तो पता चला कि साप्ताहिक Claude Design limit का 95% पहले ही खत्म हो चुका था
    इससे लगा कि यह किसी production tool से ज़्यादा demo toy के करीब है

    • मैंने कई हफ्तों से जिस design पर काम कर रहा था, उसे काफी detailed prompt और requirements document के आधार पर Claude Design से दोबारा बनवाया। कोई visual reference नहीं दिया, फिर भी result अपने आप में काफी अच्छा था
      हालांकि वह हमारे चाहने वाले style से बिल्कुल मेल नहीं खाता था, लेकिन content grouping और IA से जुड़े कुछ फैसले ऐसे थे जिन्हें मैं अपने काम में ले सकता था
      कुल मिलाकर impression अच्छा था, लेकिन बाद में Twitter पर किसी और की success story देखी तो उसका mockup मुझे मिले mockup से लगभग एक जैसा था, यह देखकर हंसी आ गई
      मुझे लगता है कि ऐसी एकरूपता की समस्या AI से बने text, code और image की तरह हमेशा साथ चलती रहेगी
    • सिर्फ इस अभिव्यक्ति के तरीके से भी लगा कि मूल टिप्पणी लिखने वाला आम user की तुलना में काफी ज्यादा skilled है, और उसकी expectations भी ऊंची हैं
      मेरी साली एक छोटी apparel company चलाती है, और पिछले 6 साल में उसकी skill बहुत बढ़ी है, लेकिन शुरुआत में ideas को actual output में बदलने में उसे सचमुच बहुत मुश्किल हुई थी
      ऐसे लोगों के लिए initial entry barrier कम करने वाला कोई भी tool आज़माने लायक है
    • मेरा usage भी इसी तरह बहुत जल्दी खत्म हो गया। एक design system ठीक से set up किया और दूसरा लगभग पूरा होने तक limit के करीब पहुंच गया
      फिर भी अभी यह research preview stage में है, इसलिए मुझे लगता है आगे बदल जाएगा
      पहले design system से मैंने अपने iPaaS startup के लिए नया footer section बनाया, और चार विकल्पों में चौथा काफी अच्छा था
      उसके बाद Claude Code से integrate करके थोड़ा polish किया, code generate किया और सीधे deploy भी कर दिया। अगर दिलचस्पी हो तो tediware.com के footer section में बाएं तरफ "Origin story" और दाएं तरफ signup panel देख सकते हैं
      implementation बहुत complex नहीं था, लेकिन जो ideas आए और integration flow जितना आसान था, उससे इसकी संभावना बहुत बड़ी लगी
    • कुछ बातों को ध्यान में रखना चाहिए
      Claude Design Opus 4.7 इस्तेमाल करता है, इसलिए यह पुराने models से महंगा है
      इसे रिलीज हुए अभी दो दिन ही हुए हैं, इसलिए यह finished product नहीं है, और Anthropic आमतौर पर बहुत तेज़ी से improve करता है
      और अगर आप Claude को लंबे समय से इस्तेमाल कर रहे हैं, तो वह पहले से ही मेरी पसंद और style जानता है; किसी दूसरे AI design tool पर जाने का मतलब फिर से शुरुआत से शुरू करना होगा
    • मेरे मामले में 10 मिनट में result बहुत अच्छा आया, लेकिन उसके तुरंत बाद पूरा usage खत्म हो गया और अब एक हफ्ता इंतज़ार करना पड़ेगा
      हां, ZIP export करना संभव था, इसलिए मैंने वह file Google के Stitch में डालकर देखी, लेकिन compatibility अच्छी नहीं थी

  • मैं इस दावे से सहमत नहीं हूं कि Claude Design design की सारी complexity हटा देगा
    Claude के साथ vibe coding से बने apps सरल इसलिए लगते हैं क्योंकि असल में उनका product scope ही सरल होता है
    यह कुछ ऐसा है जैसे bicycle और airplane को एक ही पैमाने पर रखकर simplicity समझ लेना
    वही design system component code और Figma दोनों में बनाया जाए, तो conditions और control flow की वजह से code ज्यादा concise हो सकता है
    लेकिन screen पर सीधे draw करने की तुलना में code कम flexible है, और creative freedom निकालना भी ज्यादा मुश्किल है
    आखिरकार complexity अक्सर इंसान खुद पैदा करता है, जैसे 4 products पर 8 modes और light/dark themes चढ़ा देना
    Claude maintenance थोड़ा आसान कर सकता है, लेकिन मुझे नहीं लगता कि वह complexity को बड़े पैमाने पर खत्म कर देगा

    • ज्यादातर लोगों को airplane नहीं, bicycle या car ही चाहिए
      इसलिए मुझे लगता है कि यह trend Figma के लिए काफी बड़ा झटका हो सकता है
    • असली बात आखिरकार जटिल चीज़ों को ज्यादा सरल बनाना है
      जो software यह कर पाएगा, आखिर में वही जीतेगा

  • मैं पूछना चाहता था कि क्या मैंने सही समझा है
    मैं बचपन से development करता आया हूं, लेकिन CSS में आत्मविश्वास नहीं है। इसलिए मैं जानना चाहता था कि क्या वास्तव में बहुत-सी organizations में developers, यहां तक कि frontend developers भी, ऐसे designers के साथ काम करते हैं जो सिर्फ logo या landing page sketch नहीं बल्कि पूरे product design को Figma जैसी चीज़ों में manage करते हैं
    और क्या ऐसे designers का लक्ष्य, खुद developer न होते हुए भी, किसी तरह का style database बनाए रखना होता है ताकि code बदले बिना look-and-feel संभाला जा सके, या आम तौर पर frontend developers भी Figma संभालते हैं लेकिन उसे code से अलग होने की वजह से नापसंद करते हैं

    • हां। खासकर agency दुनिया में पिछले कई सालों से यह आम रहा है कि designer Figma में pixel-level component-based source बनाते हैं, और वही लगातार evolve होने वाला single reference बन जाता है
      client भी उसे सीधे देखता है, या कम से कम उस Figma output को reflect करने वाली branding slides देखकर approve करता है
      उसके बाद frontend, Figma देखकर उसे CSS में फिर से implement करता है, लेकिन Figma का CSS copy feature असल में लगभग बेकार inline CSS जैसा होता है, इसलिए लगभग हमेशा best-effort approximation बनानी पड़ती है
      unit system मेल नहीं खाते, और parent/child relation, CSS variables, class hierarchy जैसी चीज़ें भी reflect नहीं होतीं
      कई frontend developers अगर अपने-अपने components अलग बनाएं तो drift भी आ जाता है
      इसलिए Storybook जैसे Storybook से frontend का एक और reference point बनाया जाता है, और वहां से React या NextJS में डाला जाता है, या CMS component के रूप में फिर से implement किया जाता है
      फिर सवाल उठता है कि असली source of truth क्या है, लेकिन वास्तव में यह telephone game की तरह जुड़े कई reference points की एक chain के ज्यादा करीब है
      जब main project से बाहर अलग से promotional landing pages भी बनते हैं, तो उसी design को किसी और system में फिर से एक बार implement करना पड़ता है
    • ऊपर की व्याख्या लगभग पूरी तरह सही है, और यह structure करीब 20 साल से किसी न किसी रूप में चलता आ रहा है। पहले बस Figma की जगह Photoshop files design truth का source होती थीं
      आखिरकार design से code में जाने वाले handoff gap में designer की intent खराब हो जाती है, या developer को string length, element count में बदलाव, असली scroll behavior, और अलग-अलग screen sizes जैसे practical issues बाद में संभालने पड़ते हैं
      यह छोटा meme video मजेदार भी है और उतना मजेदार नहीं भी, क्योंकि यह उसी reality को बहुत सटीक तरीके से दिखाता है
      आम तौर पर designers code नहीं करते और developers design नहीं करते, और जो दोनों अच्छे से करते हैं वे सचमुच बहुत दुर्लभ हैं
    • हां। बड़ी companies और कुछ छोटी companies में भी Figma, designer से developer तक UI handoff का de facto standard है
      ईमानदारी से कहूं तो यह काफी भयानक तरीका है, लेकिन पुराने alternatives से बेहतर जरूर लगता है
      फिर भी visual design को code में translate करने वाले उबाऊ काम का अधिकांश हिस्सा automate करने और सीधे code से जुड़े tools की तुलना में यह कमज़ोर पड़ता है
      मैंने अभी तक Claude Design इस्तेमाल नहीं किया है, लेकिन Figma के countless GUI options की तुलना में code मुझे कहीं ज्यादा सहज लगता है
    • code बदले बिना सिर्फ appearance adjust करने वाली तस्वीर से ज्यादा, मैंने अक्सर ऐसी mindset देखी है जिसमें Figma को खुद product से भी ज्यादा authoritative source माना जाता है
      शायद मेरी background भी सवाल पूछने वाले जैसी है, इसलिए उस नज़रिये के प्रति मेरे अंदर स्वाभाविक असहजता है
    • बड़ी companies में ऐसी structure की सचमुच ज़रूरत पड़ती है
      समय के साथ सभी engineers को style differences के बिना consistent implementation करानी हो, तो कुछ हद तक centralized standard होना जरूरी है

  • मैं इन दिनों figma-kiwi-protocol के जरिए Figma protocol को reverse engineer कर रहा हूं, इसलिए "Figma ने agent era के लिए जरूरी training data को खुद से बाहर कर दिया" वाली बात मुझसे बहुत resonate हुई
    Figma का binary format ऐसा है जैसे वह सब कुछ नया बनाना चाहता हो, और web, Android, iOS वगैरह सबके design संभालते-संभालते वह universal तो बन गया, लेकिन web के साथ उसका पूरा 1:1 mapping नहीं बनता
    और अगर किसी agent के लिए उपयोगी होना है तो intent साफ होनी चाहिए, लेकिन जिसने भी UX designer द्वारा बनाई गई Figma को implement किया है, वह जानता होगा कि इंसान के लिए भी design intent साफ-साफ समझना कई बार मुश्किल होता है
    जैसे German में text लंबा हो जाए तो button का क्या होगा, CSS में ले जाने पर अगर वह दो lines में टूट जाए तो क्या करें, iPhone के अलावा दूसरे phones पर क्या होगा, CSS में नामुमकिन gradient border का विकल्प क्या होगा, 4K screens पर क्या होगा — ऐसे सवाल लगातार आते रहते हैं
    props या autolayout से कुछ जवाब मिल सकते हैं, लेकिन वास्तविक दुनिया का UX person हमेशा Figma को पूरी तरह mastery के साथ चलाने वाला पौराणिक प्राणी नहीं होता
    इसलिए मैं उम्मीद करता हूं कि जिन tools का अंदरूनी आधार HTML है वे जल्दी catch up करें, और संभव हो तो product manager ने UX person को जो prompt दिया था वह भी साथ में देखने को मिले

  • लेख खुद अच्छा था, और आखिरी कुछ paragraphs सचमुच मजेदार थे
    खासकर यह बात पसंद आई कि किसी और चीज़ का नाटक करने के बजाय, इंसान को अपनी पहचान के प्रति ईमानदार होना चाहिए
    इसी दौरान मेरे मन में आया कि PenPot शायद इस agent era में काफी फायदेमंद स्थिति में हो सकता है
    fig-style canvas approach के विपरीत वह असल markup-based design की दिशा में गया है, इसलिए अगर किसी की उस दिशा में दिलचस्पी है तो संभावना और भी दिखती है

    • मुझे याद है कि Penpot का UI खुद SVG से बना था; सोच रहा था कि क्या बाद में यह बदला गया है

  • जब से InVision बंद हुआ और digital whiteboard दिशा में pivot कर गया, तब से मुझे यह design tool market लगभग खत्म-सा लगा
    मुझे यह उतना ही मुश्किल market लगता है
    और ज्यादा बुनियादी बात यह है कि design system को लंबे समय तक ठीक से maintain करना बहुत कठिन है, खासकर जब वह code और component library में गहराई से उलझा हो, जबकि उस layer को designers लगभग छूते भी नहीं
    मुझे नहीं लगता कि Claude Design, Figma या कोई और tool, reusable और अच्छी दिखने वाली components व layouts के आसपास के Storybook hell को बुनियादी रूप से हल कर पाएगा
    समाधान शायद और नीचे, यानी component level पर बदलना होगा

    • शायद भविष्य का तरीका reusable नहीं बल्कि recomposable हो सकता है
      अभी हम इस सोच में फंसे हैं कि हर नए design के लिए पहले से components बनाकर रखे जाएं
      अगर कोई component पसंद आए, तो उसकी definition markdown में save कर लें, और अगले design में tool से कहें कि वह उस markdown को पढ़कर जरूरत पड़ने पर वही component इस्तेमाल करे
      मुझे लगता है इससे flow कहीं ज्यादा flexible और दिलचस्प होगा
    • मेरे हिसाब से समाधान एक open canvas है, जहां design और code बिल्कुल एक ही जगह साथ मौजूद हों
      वह scriptable भी हो और सीधे draw भी किया जा सके, और design बदलते ही frontend code तुरंत बदल जाए, जबकि code change भी उसी स्तर पर design में reflect हो
      अंतिम रूप शायद ऐसा model होगा जिसमें designer और frontend engineer handoff के बिना सह-लेखक बनें
    • वैसे Claude Code, अगर examples काफी अच्छे हों, तो ऐसे component skeleton बनाने में ठीक-ठाक अच्छा है
      हालांकि यह भी तर्क है कि आगे चलकर edit, extraction और cleanup लगभग मुफ्त जैसे हो जाएंगे, इसलिए इस तरह की structuring खुद कम महत्वपूर्ण रह जाएगी
      मैं अभी पूरी तरह आश्वस्त नहीं हूं, लेकिन यह बात क्यों कही जाती है, समझ सकता हूं

  • मैंने पिछले कुछ सालों में खुद design tools बनाए हैं, और उस नज़रिये से मुझे लगा कि यह लेख design domain और Figma नाम की company, दोनों को काफी बुनियादी स्तर पर गलत समझता है
    Figma शुरू से ही successful product जितना ही successful company बनाने पर केंद्रित रहा है
    शुरुआत में उसके पास ज्यादा ambitious direction भी थी, और Evan Wallace जैसे लोगों की वजह से execution power भी, लेकिन आखिर में उसने WebGL demos से ज्यादा पैसे कमाने वाले concrete products पर ध्यान दिया, और वही आज के business का कारण बना
    3D features जैसी चीज़ों का न होना भी मुझे उसी choice का नतीजा लगता है
    Figma, design tool होने से पहले ऐसी company थी जो enterprise वास्तव में इस्तेमाल करे ऐसा product बनाना चाहती थी, और IPO तक पहुंचते-पहुंचते वह लक्ष्य काफी हद तक हासिल हो चुका था
    आगे market कैसे बदलेगा यह मुझे नहीं पता, लेकिन तकनीकी रूप से चमकदार demos की तुलना में war chest रखने वाले पक्ष की बढ़त कहीं ज्यादा हो सकती है
    और लेख में जिन समस्याओं का ज़िक्र है, उन्हें Figma के लोग भी — और सच कहें तो design tools बनाने वाला लगभग हर व्यक्ति — पहले से अच्छी तरह जानता है
    यह भी स्पष्ट है that UI/UX design, development और PM के intersection पर है, और इसे code जैसे source of truth के करीब होना चाहिए
    समस्या यह है कि जैसे ही आप इसे वास्तव में लागू करने की कोशिश करते हैं, यह design tools से आगे बढ़कर coding, data management और architecture tools तक फैल जाने वाली बहुत बड़ी चुनौती बन जाती है
    AI के बारे में मैं भी निश्चित नहीं हूं, लेकिन हाल के SOTA models इतने general-purpose हैं कि संभव है dedicated data से ज्यादा base model की reasoning power अहम हो
    क्योंकि UI design में बाहर दिखाई देने वाली जानकारी बहुत ज्यादा होती है, जिसे web से scrape भी किया जा सकता है

  • इस लड़ाई में मेरा कोई खास stake नहीं है, और न ही मुझे पता है कि मूल लेख का analysis सही है या नहीं
    फिर भी "proprietary file format की वजह से पीछे रह गया" जैसी बात सुनकर हमेशा थोड़ा-सा schadenfreude महसूस होता है

  • कुछ points अच्छे थे, लेकिन कुल मिलाकर मैं पूरी तरह सहमत नहीं हूं
    मेरे हिसाब से Sketch, Figma से design tooling और multiplayer experience की वजह से हारा
    जैसे physical products को actual manufacturing से पहले design किया जाता है, वैसे ही digital products में भी design phase खुद खत्म नहीं होगा
    बल्कि मुझे लगता है कि Figma को दोनों तरफ एक साथ जाने की कोशिश करने के बजाय, जल्दी तय करना चाहिए कि उसकी पहचान आखिर है क्या

    • Sketch के Figma से हारने की वजह सिर्फ tool features या collaboration नहीं थी, बल्कि यह भी थी कि organization में किसी को भी सिर्फ browser link भेजो और वह खुल जाता था
      इसके मुकाबले Mac app install करके कोई specific file खोलने वाला तरीका समय के साथ पुराना भी पड़ गया और accessibility में भी कमजोर साबित हुआ

  • संबंधित रूप से, हाल की HN thread में Claude Design पर चर्चा हुई थी, और अप्रैल 2026 तक उस पर 732 comments आ चुके थे, जिससे प्रतिक्रिया का पैमाना साफ दिखता है