Figma Responsive Design: Mobile और Desktop लेआउट कैसे तय होते हैं

कोई Figma frame जो 1440px वाले desktop और 375px वाले phone, दोनों पर सही दिखे, इसका मतलब यह नहीं कि बीच के responsive behavior का फैसला भी हो चुका है — Figma आपको सिर्फ़ दो fixed snapshots दिखाता है, जबकि किसी असली visitor की स्क्रीन जितने भी साइज़ की हो सकती है, उन सबके बीच का हिस्सा भरने के लिए browser को explicit rules चाहिए होते हैं। "ये दोनों frames सही दिख रहे हैं" से लेकर एक ऐसा लेआउट बनाने तक जो असल में टिका रहे, इसके लिए Auto Layout और Constraints को सिर्फ़ visual सेटिंग्स की तरह नहीं बल्कि responsive संकेत की तरह पढ़ना पड़ता है, और यह जानना पड़ता है कि Figma का काम कहाँ ख़त्म होता है और CSS को कहाँ से संभालना शुरू करना है। यहाँ एक practical mental model है, बनाने से पहले क्या चेक करना चाहिए, और MarkupGen का automatic responsive आउटपुट इसमें कहाँ फ़िट बैठता है।

Figma frame एक visual spec है, responsive CSS नहीं

Figma किसी frame को हमेशा एक fixed width पर render करता है। फ़ाइल में कुछ भी उस तरह screen sizes के आर-पार "play" नहीं होता जैसे browser में होता है — Figma में जो responsive design जैसा दिखता है, वह असल में rules का एक सेट है (Auto Layout की direction, gap और sizing modes; किसी layer के Constraints) जो इरादा बताते हैं, किसी resize event की working simulation नहीं। CSS वह जगह है जहाँ यह इरादा असल में सच बनता है: flex-direction, gap, percentages, clamp(), और @media rules ही असल में viewport width के हिसाब से respond करते हैं। Figma फ़ाइल को इरादे के लिए source of truth मानें, न कि किसी ऐसी चीज़ के तौर पर जिसमें पहले से ही तैयार responsive code मौजूद हो।

Mobile और desktop frames एक ही डिज़ाइन बताते हैं, दो अलग नहीं

एक ही फ़ाइल में desktop frame और mobile frame का ऐसा मिलना आम है जो हफ़्तों के फ़ासले पर डिज़ाइन किए गए हों और चुपचाप एक-दूसरे से अलग होते चले गए हों — अलग heading levels, अलग component variants, ऐसा content जो एक पर मौजूद है और बिना किसी साफ़ वजह के दूसरे पर नहीं। इसकी बजाय दोनों frames को एक ही content model के दो views की तरह ट्रीट करें: वही headings, वही components (एक बार बनाए हुए अलग duplicates की बजाय, state के लिए variants इस्तेमाल करते हुए), और वही जानकारी उसी क्रम में — जब तक क्रम बदलने की कोई सोची-समझी वजह न हो। जब दोनों frames यह underlying structure साझा करते हैं, तो CSS में जो follow-through करना पड़ता है वह ज़्यादातर सिर्फ़ layout का होता है — किसी row को column में stack करना, किसी grid के column count को एडजस्ट करना, secondary UI को collapse करना — न कि दो disconnected templates को अलग-अलग मेंटेन करना।

Auto Layout और Constraints: responsive behavior में असल में क्या ट्रांसफर होता है

Auto Layout की direction, gap, padding और sizing modes (hug, fill, fixed) काफ़ी हद तक Flexbox से मैच करती हैं — पूरी property-by-property मैपिंग के लिए Figma Auto Layout to CSS देखें। खासतौर पर responsive behavior के लिए, sizing mode ही सबसे अहम संकेत है: कोई "fill" element आपको बता रहा होता है कि उसे अपने container के साथ बढ़ना या सिकुड़ना चाहिए (flex: 1, width: 100%), जबकि "fixed" बताता है कि उसे ऐसा नहीं करना चाहिए।

Constraints एक अलग सवाल का जवाब देते हैं — जब किसी element का parent resize होता है तो वह element कैसे व्यवहार करता है, जो उन सभी चीज़ों के लिए सबसे ज़्यादा मायने रखता है जो Auto Layout के दायरे से बाहर हैं:

• Left / Right — किसी एक edge पर pin किया हुआ, यह एक fixed offset के करीब है जो parent के resize होने पर भी अपनी जगह बना रहता है।
• Left and Right — parent के साथ फैलता है, यह fixed side margins वाले width: 100% के करीब है।
• Center — parent के resize होने पर भी centered रहता है, margin: 0 auto या किसी centered flex/grid placement जैसा।
• Scale — parent के साथ proportionally resize होता है; CSS में इसका कोई सीधा एक equivalent नहीं है, और आमतौर पर इसे relative units से approximate किया जाता है।
• Top / Bottom (और इनके combinations) — यही logic vertical axis पर लागू होता है।

बहुत सी असली फ़ाइलों में दोनों साथ इस्तेमाल होते हैं: किसी container के children आपस में कैसे arrange होंगे, इसके लिए Auto Layout, और वह container खुद अपने से बड़ी किसी चीज़ के अंदर कैसे व्यवहार करेगा, इसके लिए Constraints।

Breakpoints: Figma frames से असली CSS तक

Figma में breakpoints का कोई native feature नहीं है — ऐसी कोई सेटिंग नहीं है जो कहे "768px से नीचे लेआउट बदल दो।" कोई फ़ाइल असल में आपको या तो हर screen size के लिए अलग-अलग frames देती है, या एक ऐसा single Auto Layout frame जो बिना किसी structural बदलाव के fluid तरीक़े से resize होता है। आप इनमें से किसे देख रहे हैं, यही तय करता है कि CSS को explicit @media rules चाहिए या नहीं, और सबसे ज़्यादा काम यही होता है कि ऐसे breakpoint values चुने जाएँ जो उस जगह से मैच करें जहाँ लेआउट का shape सच में बदलता है — न कि मनमानी device widths से। Figma Breakpoints to CSS Media Queries दोनों patterns को विस्तार से कवर करता है और यह भी कि हाथ से किया गया translation आमतौर पर कहाँ गड़बड़ाता है।

Figma के फैसलों को responsive CSS में बदलना

एक बार Figma-साइड के संकेत साफ़ हो जाएँ, तो CSS-साइड पर tools का एक छोटा-सा सेट लगातार इस्तेमाल होता है:

• Flexbox — ज़्यादातर Auto Layout frames के लिए, जैसे rows, columns, nav bars, card lists।
• Grid — असल में two-dimensional layouts के लिए, जैसे कोई dashboard या gallery जिसे Auto Layout nested rows और columns से नक़ल कर रहा हो।
• Media queries — जहाँ लेआउट का shape बदलता है — कोई sidebar जो bottom nav बन जाता है, कोई grid जो single column बन जाता है।
• Fluid sizing (percentages, minmax(), clamp()) — उन widths के बीच के हर हिस्से के लिए जो डिज़ाइनर ने असल में specify की हैं, बजाय इसके कि gaps भरने के लिए और breakpoints जोड़े जाएँ।
• max-width — ताकि text और content बड़ी स्क्रीन्स पर असहज रूप से ज़्यादा न फैलें, भले ही खुद Figma frame में यह न दिखाया गया हो।
• Wrapping और stacking (flex-wrap, किसी row का column बनना) — ऐसे content के लिए जिसे सिकुड़ने की बजाय reflow होना चाहिए।
• Visibility में बदलाव — किसी ऐसी चीज़ के लिए जो असल में सिर्फ़ mobile या सिर्फ़ desktop के लिए हो — इसे सावधानी से करना ज़रूरी है, क्योंकि display: none से किसी element को छिपाने पर वह accessibility tree से भी हट जाता है। अगर छिपे हुए content को किसी और तरीक़े से पहुँच में रखना ज़रूरी हो, जैसे किसी mobile menu में, तो Figma to Accessible HTML देखें।

Figma को responsive लेआउट में ट्रांसलेट करते वक्त आम गलतियाँ

• Mobile को सिकुड़ा हुआ desktop मानना, न कि अपनी hierarchy और priorities वाला एक अलग लेआउट।
• हर जगह pixel dimensions hardcode करना जहाँ Figma frame कोई specific number दिखाता है, बजाय इसके कि यह तय करने के लिए fill/fixed sizing और Constraints इस्तेमाल किए जाएँ कि असल में क्या fixed रहना चाहिए।
• Text wrapping को नज़रअंदाज़ करना — कोई heading या button label जो source language में एक लाइन में फ़िट हो जाता है, किसी लंबे translation में दो या तीन लाइनों में wrap हो सकता है, और जो लेआउट single-line text मान कर बनाया गया हो वह टूट जाता है।
• Design को pixel-for-pixel मैच करने के लिए absolute positioning पर निर्भर रहना, जो exact frame width पर तो सही दिखता है लेकिन बीच की हर width पर टूट जाता है।
• सिर्फ़ वही widths चेक करना जिन पर Figma frames बनाए गए थे — जैसे 375px और 1440px — और बीच का सब कुछ छोड़ देना, जहाँ असल में ज़्यादातर टूट-फूट होती है।

Developer handoff चेकलिस्ट

किसी Figma फ़ाइल से responsive behavior implement करने से पहले, अंदाज़ा लगाने की बजाय डिज़ाइन में सीधे कुछ चीज़ें चेक कर लेना बेहतर है:

• कौन-कौन से frames मौजूद हैं, और क्या mobile और desktop, restructure किए हुए एक ही content के लिए हैं, या असल में अलग-अलग experiences के लिए।
• हर frame की Auto Layout सेटिंग्स — direction, gap, padding, और उन elements पर sizing mode जिन्हें resize होना है।
• Auto Layout के बाहर मौजूद किसी भी चीज़ पर Constraints, ख़ासकर किसी edge पर pinned या centered elements पर।
• हर frame width पर spacing और typography — क्या ये scale होते हैं, या fixed रहते हैं?
• Component variants — क्या किसी component का अलग mobile variant है, या यह उम्मीद है कि वही component खुद adapt कर ले?
• Mobile और desktop frames के बीच असल में क्या अलग है, और क्या हर अंतर जानबूझकर किया गया है या बस अलग-अलग समय पर एडिट की गई फ़ाइलों के बीच की drift है।

MarkupGen responsive बेसलाइन को कैसे ऑटोमेट करता है

हर export किसी generic breakpoint list से नहीं, बल्कि frame की अपनी Auto Layout सेटिंग्स और resizing constraints से शुरू होता है — direction, gap और padding बिल्कुल वैसे ही carry over होते हैं, और fill/hug sizing fluid CSS में ट्रांसलेट होती है, इसलिए ज़्यादातर लेआउट्स के लिए नतीजा बिना हाथ से लिखी media queries के, screen sizes के आर-पार scale करता है।

जिन डिज़ाइन में mobile को असल में एक अलग structure चाहिए होता है — horizontal की बजाय stacked nav, reorder किया हुआ hero, छिपी हुई sidebar — उनके लिए in-app editor मौजूदा HTML/CSS से current page के लिए एक अलग, ख़ास तौर पर बनाया गया Mobile या Desktop लेआउट, अपनी खुद की media query के साथ generate कर सकता है; लागू करने से पहले आप उसे रिव्यू करते हैं, और उसके बाद विज़िटर की स्क्रीन साइज़ ही तय करती है कि कौन-सा रेंडर होगा। दोनों ही सूरत में आउटपुट nested <div>s की बजाय semantic HTML को तरजीह देता है, चाहे Vanilla CSS हो, Tailwind, Bootstrap, Bulma, Materialize या Pico — और हर export पर एक automatic AI quality score भी मिलता है। इनमें से कोई भी चीज़ ऊपर वाली checklist की जगह नहीं लेती — यह डिज़ाइन के असली संकेतों से बना एक शुरुआती बिंदु है, जिसे शिप करने से पहले उसी तरह रिव्यू करना चाहिए जैसे किसी और responsive implementation को करते हैं।

अगर आप देखना चाहते हैं कि आपकी अपनी Figma फ़ाइल दोनों स्क्रीन साइज़ पर कैसे respond करती है, तो Figma to HTML converter आज़माएँ — या अगर आपका stack वही है तो सीधे React में कन्वर्ट करें — मुफ़्त में, किसी क्रेडिट कार्ड की ज़रूरत नहीं।

अक्सर पूछे जाने वाले सवाल

किसी Figma डिज़ाइन को mobile और desktop लेआउट कैसे हैंडल करने चाहिए? इन्हें दो अलग-अलग, असंबंधित फ़ाइलों की बजाय एक ही डिज़ाइन के दो widths पर एक्सप्रेस होने के रूप में ट्रीट करें — वही content, headings और components। Auto Layout और Constraints यह बताते हैं कि यह साझा structure कैसे adapt होना चाहिए; असली structural अंतर, जैसे collapsed nav या reordered hero, फिर CSS media queries से implement किए जाते हैं।

क्या Figma के Auto Layout और Constraints किसी डिज़ाइन को अपने-आप responsive बना देते हैं? नहीं। ये सिर्फ़ इरादा बताते हैं — कि किसी element का container बदलने पर उसे कैसे size या behave करना चाहिए — लेकिन उस इरादे को अब भी असली CSS में Flexbox, Grid, fluid sizing या media queries में ट्रांसलेट करना पड़ता है। न तो Figma और न ही कोई conversion tool हर responsive फैसला अपने-आप जनरेट कर देता है।

Figma डिज़ाइन से CSS breakpoints कैसे चुनें? Figma में breakpoints का कोई native feature नहीं है, इसलिए breakpoints उस जगह पर आधारित करें जहाँ लेआउट का shape असल में बदलता है, न कि मनमानी device widths पर। अगर कोई डिज़ाइन हर screen size के लिए अलग frame इस्तेमाल करता है, तो आमतौर पर हर frame का लेआउट एक @media block बन जाता है; अगर यह Auto Layout की fluid resizing पर निर्भर करता है, तो अक्सर उसे किसी breakpoint की ज़रूरत ही नहीं पड़ती।

Figma में Auto Layout और Constraints में क्या फ़र्क़ है? Auto Layout यह कंट्रोल करता है कि किसी frame के children कैसे arrange होते हैं — direction, gap, padding, sizing — जो display: flex के सबसे करीब है। Constraints यह कंट्रोल करते हैं कि किसी element का parent resize होने पर वह कैसे व्यवहार करता है, जैसे किसी edge पर pinned होना, centered होना, या scaled होना, जो उन elements के लिए सबसे ज़्यादा मायने रखता है जो Auto Layout के बाहर हैं, या यह तय करने के लिए कि कोई Auto Layout frame खुद से बड़ी किसी चीज़ के अंदर कैसे बैठता है।

क्या mobile और desktop के लिए अलग-अलग Figma फ़ाइलें होनी चाहिए? ज़रूरी नहीं, और shared components के साथ इन्हें एक ही फ़ाइल में रखने से आमतौर पर drift पकड़ना आसान हो जाता है। फ़ाइल structure से ज़्यादा यह मायने रखता है कि दोनों frames एक ही content model को दर्शाते हैं या नहीं — वही components और hierarchy — जहाँ इनके बीच बदलने वाली चीज़ content नहीं बल्कि layout हो।

किसी Figma डिज़ाइन को responsively implement करने से पहले मुझे क्या चेक करना चाहिए? कौन-से frames मौजूद हैं, हर एक की Auto Layout और Constraint सेटिंग्स, इनके बीच spacing और typography कैसे बदलते हैं (या नहीं बदलते), क्या components के अलग mobile variants हैं, और mobile व desktop frames के बीच कौन-से अंतर जानबूझकर किए गए हैं बजाय accidental drift के।