रिस्पॉन्सिव ईमेल डिज़ाइन: 2026 के लिए एक व्यावहारिक गाइड

Groupmail की रिस्पॉन्सिव ईमेल गाइड के अनुसार, 2025 में 70% से अधिक ईमेल मोबाइल उपकरणों पर खोले गए थे। इस एक बदलाव ने ईमेल डिज़ाइन के काम को पूरी तरह बदल दिया है। अब आप केवल डेस्कटॉप लेआउट को बेहतर नहीं बना रहे हैं और यह उम्मीद नहीं कर रहे हैं कि वह फोन पर भी सही दिखेगा। अब आप सबसे संकरी स्क्रीन, सबसे कम लचीले ईमेल क्लाइंट और अंगूठे के सबसे तेज़ स्क्रॉल के लिए निर्माण कर रहे हैं।

यही कारण है कि रिस्पॉन्सिव ईमेल डिज़ाइन व्यावहारिक रूप से इतना महत्वपूर्ण है। यह कोई विज़ुअल ट्रेंड नहीं है। यह उस ईमेल और उस ईमेल के बीच का अंतर है जिसे पढ़ा जाता है और जिसे पाठक के हेडलाइन तक पहुँचने से पहले ही डिलीट कर दिया जाता है।

मैंने पाया है कि कई टीमें रिस्पॉन्सिव ईमेल के विचार के साथ संघर्ष नहीं करती हैं। वे इसके कार्यान्वयन (implementation) के साथ संघर्ष करती हैं। वे जानते हैं कि उन्हें मोबाइल-फ्रेंडली लेआउट की आवश्यकता है, लेकिन वे अभी भी Outlook की अजीबोगरीब समस्याओं, CSS सपोर्ट की कमियों, डार्क मोड के आश्चर्यों और इस तथ्य से जूझ रहे हैं कि वे शायद किसी भारी-भरकम ESP के बजाय Gmail से ईमेल भेजना चाहते हैं। यह गाइड इसी कमी को पूरा करती है।

2026 में रिस्पॉन्सिव ईमेल डिज़ाइन अनिवार्य क्यों है

डेस्कटॉप-फर्स्ट ईमेल अब अधिक जोखिम वाला निर्माण है। फोन पर, पाठक सेकंडों में तय करते हैं कि आपका संदेश पढ़ने में आसान है, टैप करने में आसान है और उनके समय के लायक है या नहीं।

जैसा कि पहले उल्लेख किया गया है, मोबाइल अब अधिकांश ईमेल ओपन के लिए जिम्मेदार है। यह उस मानक को बदल देता है जिसे एक उपयोगी अभियान माना जाता है। एक ईमेल जो बड़ी स्क्रीन पर स्वीकार्य दिखता है, वह उस इनबॉक्स में विफल हो सकता है जो सबसे पहले मायने रखता है, खासकर यदि यह Gmail के माध्यम से आता है और इसे किसी बड़े ESP के सुरक्षा घेरे के बिना सही दिखना है।

इसकी कीमत जल्दी ही पता चल जाती है। Groupmail की रिपोर्ट है कि जो ईमेल मोबाइल-फ्रेंडली नहीं होते हैं, उन्हें अक्सर डिलीट कर दिया जाता है, और मोबाइल-रिस्पॉन्सिव टेम्प्लेट मोबाइल क्लिक को बढ़ा सकते हैं। यह वही है जो ईमेल डेवलपर्स प्रोडक्शन में देखते हैं। यदि पहली स्क्रीन तंग या टूटी हुई महसूस होती है, तो पाठक संदेश के ठीक होने का इंतजार नहीं करता है।

फोन पर विफलता कैसी दिखती है

डेस्कटॉप पर, पाठक कभी-कभी खराब लेआउट के साथ काम चला सकते हैं। वे व्यापक कैनवास पर स्कैन कर सकते हैं, अजीब स्पेसिंग से उबर सकते हैं और अधिक सटीकता के साथ क्लिक कर सकते हैं।

फोन कम क्षमाशील होते हैं।

• छोटा बॉडी टेक्स्ट ज़ूम करने के लिए मजबूर करता है और पढ़ने की गति को धीमा कर देता है।
• मल्टी-कॉलम सेक्शन बुरी तरह से स्टैक हो जाते हैं या पढ़ने के लिए बहुत संकरे रहते हैं।
• छोटे बटन गलत टैप का कारण बनते हैं और कन्वर्जन रेट को कम करते हैं।
• बड़ी हीरो इमेज मुख्य संदेश को स्क्रीन पर बहुत नीचे धकेल देती हैं।

मैं बिल्ड रिव्यू के दौरान एक साधारण जांच का उपयोग करता हूं। यदि मुख्य CTA एक त्वरित अंगूठे के स्क्रॉल के भीतर स्पष्ट नहीं है, तो ईमेल पर काम करने की आवश्यकता है। यह मानक उन टीमों के लिए और भी महत्वपूर्ण है जो Gmail मेल मर्ज टूल के माध्यम से पॉलिश किया हुआ HTML भेजती हैं, जहाँ एक साफ संरचना को प्लेटफॉर्म ऑटोमेशन की तुलना में अधिक मेहनत करनी पड़ती है।

रिस्पॉन्सिव डिज़ाइन केवल दिखावट नहीं, प्रदर्शन की रक्षा करता है

एक रिस्पॉन्सिव बिल्ड सौंदर्यशास्त्र से कहीं अधिक सुधार करता है। यह पदानुक्रम (hierarchy) की रक्षा करता है, लाइन की लंबाई को पढ़ने योग्य रखता है, और बटनों को टच इनपुट के लिए पर्याप्त जगह देता है। यह इस संभावना को भी कम करता है कि लेआउट Outlook जैसे जिद्दी क्लाइंट्स में बिखर जाए, जहाँ हर अतिरिक्त सजावट परीक्षण के बोझ को बढ़ाती है।

2026 में यह ट्रेड-ऑफ मायने रखता है। फैंसी लेआउट ब्राउज़र प्रीव्यू में प्रभावशाली दिख सकते हैं और फिर भी वास्तविक इनबॉक्स में परिहार्य समस्याएं पैदा कर सकते हैं। एक सरल रिस्पॉन्सिव संरचना आमतौर पर जीतती है क्योंकि इसे कोड करना आसान है, टेस्ट करना आसान है, और जब आप इसे बड़े पैमाने पर या सीधे Gmail से भेजते हैं तो यह अधिक भरोसेमंद होती है।

ईमेल अभी भी एक चैनल के रूप में मजबूत रिटर्न देता है। Tabular द्वारा उद्धृत 2025 की एक रिपोर्ट कहती है कि ईमेल मार्केटिंग हर $1 खर्च करने पर लगभग $36 का रिटर्न देती है। इस तरह के लाभ के साथ, रिस्पॉन्सिव निष्पादन केवल एक पॉलिशिंग चरण नहीं है। यह डिलीवरी प्रक्रिया का हिस्सा है।

व्यावहारिक आधार स्पष्ट है:

1. पहले संकरी स्क्रीन के लिए निर्माण करें।
2. टच इनपुट मानकर चलें।
3. प्राथमिक कार्रवाई को जल्दी दिखाई देने योग्य रखें।
4. असमान CSS सपोर्ट की अपेक्षा करें।
5. ऐसे पैटर्न चुनें जिन्हें आप मज़बूती से टेस्ट और भेज सकें, जिसमें Gmail-आधारित वर्कफ़्लो भी शामिल हैं।

अपना रिस्पॉन्सिव लेआउट दृष्टिकोण चुनना

HTML को छूने से पहले, लेआउट दर्शन चुनें। वह निर्णय कोड जटिलता से लेकर परीक्षण समय तक, बाद में आने वाली हर चीज़ को आकार देता है।

कई टीमें इस हिस्से को बहुत जटिल बना देती हैं। वे एक चतुर मल्टी-कॉलम प्रोमो लेआउट के लिए हाथ बढ़ाती हैं जबकि एक साधारण सिंगल-कॉलम संरचना ने बेहतर प्रदर्शन किया होता और कम बार टूटी होती। यह विशेष रूप से तब सच है जब उनके दर्शकों में Outlook-प्रधान कॉर्पोरेट इनबॉक्स शामिल हों।

तीन लेआउट रणनीतियाँ जो मायने रखती हैं

आप आमतौर पर ईमेल विकास में तीन दृष्टिकोणों पर चर्चा सुनेंगे।

दृष्टिकोण	यह कैसे व्यवहार करता है	यह कहाँ अच्छा काम करता है	यह कहाँ मुश्किल हो जाता है
फ्लूइड	तत्व उपलब्ध चौड़ाई के साथ स्केल होते हैं	सरल न्यूज़लेटर, अलर्ट, टेक्स्ट-भारी ईमेल	मजबूत चौड़ाई नियंत्रण के बिना बहुत ढीला महसूस हो सकता है
एडेप्टिव	ब्रेकपॉइंट्स पर अलग लेआउट का उपयोग करता है	अधिक नियंत्रित डेस्कटॉप/मोबाइल वेरिएंट वाले अभियान	मीडिया क्वेरी सपोर्ट पर अधिक निर्भर करता है
हाइब्रिड या स्पंजी	चयनात्मक रिस्पॉन्सिव व्यवहार के साथ फ्लूइड संरचना को मिलाता है	जिन टीमों को व्यापक क्लाइंट लचीलेपन की आवश्यकता है	अधिक सेटअप कार्य और टेस्ट करने के लिए अधिक एज केस

फ्लूइड सबसे आसान मानसिक मॉडल है। सामग्री स्वाभाविक रूप से फैलती और सिकुड़ती है। सीधे ईमेल के लिए, यह अक्सर पर्याप्त होता है।

एडेप्टिव आपको अधिक नियंत्रण देता है। आप परिभाषित करते हैं कि ईमेल को विशिष्ट चौड़ाई पर कैसे व्यवहार करना चाहिए। यह तब उपयोगी होता है जब डेस्कटॉप और मोबाइल को स्पष्ट रूप से अलग उपचार की आवश्यकता होती है।

हाइब्रिड बीच में बैठता है। यह अक्सर प्रोडक्शन ईमेल के लिए सबसे व्यावहारिक मार्ग है क्योंकि यह मीडिया-क्वेरी-भारी डिज़ाइन की तुलना में कमजोर क्लाइंट सपोर्ट को बेहतर तरीके से सहन करता है।

लालित्य के बजाय दर्शकों के आधार पर चुनें

सबसे मजबूत लेआउट वह है जिसे आपके दर्शकों के इनबॉक्स लगातार रेंडर कर सकें।

OneSignal की रिस्पॉन्सिव ईमेल डिज़ाइन पर मार्गदर्शन एक महत्वपूर्ण बिंदु उठाता है: कई क्लाइंट, विशेष रूप से Outlook के संस्करण, जटिल लेआउट के लिए कमजोर सपोर्ट रखते हैं। कुछ मामलों में, एक सरल सिंगल-कॉलम डिज़ाइन अधिक महत्वाकांक्षी रिस्पॉन्सिव बिल्ड की तुलना में बेहतर और अधिक सुसंगत अनुभव बनाता है।

यह बिल्कुल सही है। यदि दर्शक डेस्कटॉप Outlook उपयोगकर्ताओं द्वारा हावी हैं, तो मैं हर बार एक स्थिर सिंगल-कॉलम ईमेल को एक नाजुक दो-कॉलम लेआउट पर चुनूंगा।

टूटी हुई परिष्कार साधारण विश्वसनीयता से हार जाती है।

एक व्यावहारिक निर्णय ढांचा

लेआउट दृष्टिकोण चुनते समय इसका उपयोग करें:

• पहले सिंगल-कॉलम चुनें यदि ईमेल मुख्य रूप से कॉपी, एक हीरो इमेज और एक मुख्य CTA है।
• फ्लूइड या हाइब्रिड का उपयोग करें यदि आप मीडिया क्वेरी पर सब कुछ दांव पर लगाए बिना रिस्पॉन्सिव व्यवहार चाहते हैं।
• एडेप्टिव का सावधानीपूर्वक उपयोग करें जब आप डिज़ाइन संसाधनों को नियंत्रित करते हैं और प्रमुख क्लाइंट्स पर पूरी तरह से टेस्ट कर सकते हैं।
• सजावटी जटिलता से बचें जब आपकी सूची में बहुत सारे Outlook या मिश्रित उद्यम वातावरण शामिल हों।

जो आमतौर पर सबसे अच्छा काम करता है

कई लोगों के लिए, जीतने वाला फॉर्मूला अभी भी सबसे अच्छे तरीके से उबाऊ है:

• एक सिंगल-कॉलम बॉडी
• एक स्पष्ट विज़ुअल पदानुक्रम
• एक प्राथमिक CTA
• न्यूनतम लेआउट ट्रिक्स

वह संरचना न केवल अधिक क्लाइंट्स में जीवित रहती है। यह ईमेल लिखना भी आसान बनाती है, क्योंकि सामग्री को फैंसी व्यवस्था पर निर्भर किए बिना अपने दम पर खड़ा होना पड़ता है।

अपनी मुख्य HTML संरचना का निर्माण

डेस्कटॉप अभी भी ईमेल में बहुत भारी काम करता है, विशेष रूप से B2B सेंड के लिए, और यह बदलता है कि HTML कैसे बनाया जाना चाहिए। सबसे सुरक्षित शुरुआती बिंदु एक केंद्रित टेबल कंटेनर है जो बड़ी स्क्रीन पर पढ़ने योग्य रहता है और मोबाइल पर स्पष्ट रूप से कोलैप्स हो जाता है। व्यवहार में, इसका मतलब आमतौर पर 600 से 640px के आसपास सीमित एक सिंगल-कॉलम ईमेल है।

वह चौड़ाई वर्षों से बनी हुई है क्योंकि यह आपको टाइप, बटन और छवियों के लिए पर्याप्त जगह देती है, बिना तंग डेस्कटॉप प्रीव्यू पैन में क्षैतिज स्क्रॉल को मजबूर किए। यह एक ऐसे वर्कफ़्लो के साथ भी अच्छी तरह से मैप करता है जहाँ आप एक बार निर्माण करते हैं, प्रमुख क्लाइंट्स पर टेस्ट करते हैं, फिर पूर्ण ESP के बजाय Gmail जैसे सरल टूल स्टैक के साथ मेल मर्ज का उपयोग करके भेजते हैं।

सही कंटेनर के साथ शुरुआत करें

बैकग्राउंड रंग और सेंट्रिंग के लिए फुल-विड्थ बाहरी रैपर का उपयोग करें। फिर अपने वास्तविक ईमेल को एक सीमित आंतरिक टेबल के अंदर रखें।

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="x-ua-compatible" content="ie=edge">
  <title>Email</title>
</head>
<body style="margin:0; padding:0; background-color:#f4f4f4;">
  <table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0" style="border-collapse:collapse; width:100%; background-color:#f4f4f4;">
    <tr>
      <td align="center" style="padding:24px 12px;">
        <table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0" style="border-collapse:collapse; max-width:640px; background-color:#ffffff;">
          <tr>
            <td style="padding:32px 24px; font-family:Arial, sans-serif; font-size:16px; line-height:1.5; color:#222222;">
              Your content goes here.
            </td>
          </tr>
        </table>
      </td>
    </tr>
  </table>
</body>
</html>

यह आधार संरचना चार सामान्य समस्याओं को जल्दी हल करती है:

• अनुमानित लेआउट रेंडरिंग उन क्लाइंट्स में जो अभी भी टेबल लॉजिक पर निर्भर हैं
• सुरक्षित सेंट्रिंग बिना नाजुक CSS पोजिशनिंग के
• डेस्कटॉप पर पढ़ने योग्य लाइन की लंबाई
• Gmail-फ्रेंडली सेंडिंग वर्कफ़्लो के लिए एक साफ शेल, जहाँ चतुर फ्रंट-एंड तकनीकों की तुलना में सरल, टिकाऊ मार्कअप अधिक मायने रखता है

लेआउट के सरल रहने के दौरान Outlook सपोर्ट जोड़ें

Windows पर Outlook उस CSS को अनदेखा या पुनर्व्याख्या कर सकता है जो कहीं और ठीक काम करता है। मैं इसे उजागर करने के लिए परीक्षण का इंतजार नहीं करता। मैं कंटेनर के स्थान पर आते ही Outlook रैपर जोड़ देता हूं, क्योंकि बाद में इसे रेट्रोफिट करना धीमा और आमतौर पर अधिक गड़बड़ होता है।

एक घोस्ट टेबल Outlook को एक निश्चित चौड़ाई वाली संरचना देती है जबकि अन्य क्लाइंट मानक कंटेनर का उपयोग करते हैं।

<!--[if mso]>
<table role="presentation" width="640" align="center" cellspacing="0" cellpadding="0" border="0">
  <tr>
    <td>
<![endif]-->

<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0" style="border-collapse:collapse; max-width:640px;">
  <tr>
    <td style="padding:24px;">
      Main content block
    </td>
  </tr>
</table>

<!--[if mso]>
    </td>
  </tr>
</table>
<![endif]-->

यह सादा HTML है। यही बात है।

यदि आपके दर्शकों में कंपनी डोमेन, खरीद टीमें, या आंतरिक न्यूज़लेटर शामिल हैं, तो Outlook सपोर्ट पहले ड्राफ्ट में होना चाहिए। यह अनुमोदन के बाद बचाव का काम नहीं होना चाहिए।

सेक्शन को स्वतंत्र ब्लॉक के रूप में बनाएं

प्रत्येक प्रमुख सेक्शन को अपनी पंक्ति या नेस्टेड टेबल के रूप में मानें। यह संपादन को सुरक्षित और परीक्षण को तेज़ बनाता है।

एक व्यावहारिक ब्लॉक क्रम इस तरह दिखता है:

1. हीरो क्षेत्र
2. इंट्रो कॉपी
3. CTA ब्लॉक
4. माध्यमिक सामग्री
5. फुटर

यह संरचना तब काम आती है जब आपको Gmail के साथ मेल मर्ज का उपयोग करके भेजने से पहले विभिन्न प्राप्तकर्ताओं के लिए सामग्री को स्वैप करने की आवश्यकता होती है। आप पूरे संदेश को अस्थिर किए बिना एक हीरो को बदल सकते हैं, एक माध्यमिक ब्लॉक को हटा सकते हैं, या फुटर को छोटा कर सकते हैं।

यदि आप एक तेज़ शुरुआती बिंदु चाहते हैं, तो Gmail ईमेल लेआउट के लिए एक टेबल जनरेटर कंकाल का उत्पादन कर सकता है। मैं भेजने से पहले अभी भी स्पेसिंग, चौड़ाई और इनलाइन शैलियों को हाथ से साफ करता हूं।

संस्करण एक को उबाऊ रखें

पहले पास को संरचना साबित करनी चाहिए, डिज़ाइन सिस्टम को दिखाना नहीं चाहिए।

कंटेनर, स्पेसिंग, कॉपी ब्लॉक और बटन टेबल को पहले काम करने दें। जांचें कि छवियां स्केल होती हैं, लिंक टैप करने योग्य हैं, और छवियां बंद होने पर भी बॉडी पढ़ने योग्य रहती है। एक बार जब वह नींव Gmail, Apple Mail और Outlook में जीवित रह जाती है, तो मल्टी-कॉलम प्रोडक्ट रो या सेक्शन-विशिष्ट बैकग्राउंड जैसे अधिक महत्वाकांक्षी टुकड़े जोड़ना समझ में आता है।

सादा मार्कअप इनबॉक्स में बेहतर यात्रा करता है। यह तब और भी मायने रखता है जब अंतिम सेंड एक बड़े ESP के बजाय सुलभ टूल के माध्यम से होता है, क्योंकि आपके HTML को अपने दम पर अधिक विश्वसनीयता उठानी पड़ती है।

असंगत ईमेल क्लाइंट्स के लिए CSS में महारत हासिल करना

ईमेल CSS एक सरल कारण से टूटता है। इनबॉक्स ऐप्स एक ही रेंडरिंग इंजन से काम नहीं कर रहे हैं, और Windows पर Outlook अभी भी ब्राउज़र की तुलना में Word दस्तावेज़ की तरह अधिक व्यवहार करता है।

यह बदलता है कि रिस्पॉन्सिव ईमेल कैसे बनाया जाता है। काम सबसे साफ आधुनिक CSS लिखना नहीं है। काम ऐसा HTML भेजना है जो Gmail द्वारा हेड के हिस्सों को हटाने, Apple Mail द्वारा जो हो सकता है उसे बढ़ाने, और Outlook द्वारा जिसे उसने कभी सपोर्ट नहीं किया उसे अनदेखा करने के बाद भी सही दिखे।

उस CSS के साथ शुरुआत करें जो कमजोर क्लाइंट्स में जीवित रहता है

सबसे सुरक्षित स्टाइलिंग विकल्प पुराने, दोहराव वाले और प्रोडक्शन में सिद्ध हैं। पठनीयता या लेआउट से जुड़ी किसी भी चीज़ के लिए इनलाइन शैलियों का उपयोग करें। चौड़ाई को स्पष्ट रखें। जहाँ वे अभी भी मदद करते हैं, वहां बैकअप के रूप में HTML विशेषताओं का उपयोग करें। टेबल सेल या इमेज पर एक width विशेषता अक्सर डिज़ाइन को बचा लेती है जब कोई क्लाइंट CSS के बारे में चयनात्मक हो जाता है।

एक भरोसेमंद उदाहरण इस तरह दिखता है:

<td width="100%" style="width:100%; padding:24px; font-family:Arial, sans-serif;">

वह दोहराव जानबूझकर है। ब्राउज़र के काम में, यह अनावश्यक लगता है। ईमेल में, यह आश्चर्य को कम करता है।

मैं इसके साथ वैसा ही व्यवहार करता हूं जैसा मैं लोगो या ईमेल हस्ताक्षर आइकन जो Gmail में तेज और संरेखित रहने की आवश्यकता है के साथ करता हूं। मार्कअप को अपनी खुद की फॉलबैक योजना ले जानी चाहिए।

इनलाइन CSS और एम्बेडेड CSS अलग-अलग काम करते हैं

उन टुकड़ों के लिए इनलाइन CSS का उपयोग करें जो विफल नहीं हो सकते। इसका आमतौर पर मतलब है:

• फ़ॉन्ट परिवार
• फ़ॉन्ट आकार
• लाइन की ऊंचाई
• पैडिंग
• टेक्स्ट का रंग
• बैकग्राउंड का रंग
• संरेखण
• छवि प्रदर्शन नियम
• चौड़ाई व्यवहार

उन संवर्द्धन के लिए एक <style> ब्लॉक का उपयोग करें जो पूरे संदेश को जोखिम में डाले बिना मजबूत क्लाइंट्स को बेहतर बनाते हैं। मीडिया क्वेरी वहीं संबंधित हैं। यूटिलिटी क्लास वहीं संबंधित हैं। यदि उन नियमों को अनदेखा करने पर भी ईमेल अच्छी तरह से पढ़ा जाता है, तो डार्क मोड समायोजन वहीं संबंधित हैं।

एक सरल नियम यहाँ मदद करता है। यदि किसी घोषणा को हटाने से ईमेल अपठनीय हो जाएगा या लेआउट टूट जाएगा, तो उसे इनलाइन करें।

एक व्यावहारिक सपोर्ट टेबल

यह वह वर्किंग मॉडल है जिसका उपयोग मैं रिस्पॉन्सिव ईमेल बनाते समय करता हूं जो सुलभ टूल के माध्यम से भेजे जाएंगे, जिसमें Gmail के साथ मेल मर्ज भी शामिल है।

CSS प्रॉपर्टी	Gmail	Apple Mail	Outlook (Windows)
इनलाइन color, font-size, padding	अच्छा	अच्छा	अच्छा
छवियों पर max-width	अच्छा	अच्छा	आमतौर पर ठीक, लेकिन वास्तविक सामग्री के साथ टेस्ट करें
मीडिया क्वेरी	ऐप और अकाउंट संदर्भ के आधार पर मिश्रित सपोर्ट	अच्छा	असंगत
बैकग्राउंड छवियां	सीमित और असंगत	अच्छा	समस्याग्रस्त
फ्लेक्सबॉक्स और ग्रिड	प्रोडक्शन ईमेल के लिए अविश्वसनीय	अधिकांश से बेहतर	प्रोडक्शन ईमेल के लिए खराब विकल्प

यह लैब मैट्रिक्स नहीं है। यह एक प्रोडक्शन फिल्टर है। यदि कोई लेआउट फ्लेक्सबॉक्स, ग्रिड, या लेयर्ड पोजिशनिंग पर निर्भर करता है, तो यह Gmail सेंड वर्कफ़्लो के लिए पहले से ही बहुत नाजुक है।

उबाऊ CSS यहाँ जीतता है।

पहले फॉलबैक के लिए निर्माण करें

रिस्पॉन्सिव ईमेल तब बेहतर काम करता है जब डिफ़ॉल्ट स्थिति बिना किसी मीडिया क्वेरी के पढ़ने योग्य हो। फिर मीडिया क्वेरी उन क्लाइंट्स के लिए स्पेसिंग, संरेखण, या डेस्कटॉप प्रस्तुति में सुधार करती है जो इसका सपोर्ट करते हैं।

यह और भी मायने रखता है यदि आप स्वयं HTML बना रहे हैं और एक बड़े ESP टेम्प्लेट सिस्टम के बजाय Gmail के माध्यम से भेज रहे हैं। आपको सेंडिंग प्लेटफॉर्म से बहुत अधिक सुरक्षा नहीं मिलती है। कोड को अपने दम पर सहनशील होना चाहिए।

एक व्यावहारिक पैटर्न इस तरह दिखता है:

<style>
  .container { width:100% !important; max-width:640px !important; }
  .stack { display:block !important; width:100% !important; }
  @media only screen and (min-width: 640px) {
    .two-col {
      display:table-cell !important;
      width:50% !important;
    }
  }
</style>

यदि मीडिया क्वेरी को अनदेखा किया जाता है, तो सामग्री स्टैक की हुई और पढ़ने योग्य रहती है। ईमेल के लिए यह सही विफलता मोड है।

CSS विकल्प जो परिहार्य समस्याएं पैदा करते हैं

कुछ तकनीकें उन डिज़ाइनों में दिखाई देती रहती हैं जिन्हें Outlook में टेस्ट करने से पहले Figma में स्पष्ट रूप से अनुमोदित किया गया था।

जब तक आपके पास कोई विशिष्ट कारण न हो और हर एज केस को टेस्ट करने का समय न हो, तब तक इनसे बचें:

• संरचनात्मक लेआउट के लिए पूर्ण या सापेक्ष पोजिशनिंग
• केवल-होवर इंटरैक्शन
• शॉर्टहैंड घोषणाएं जब स्पष्ट गुण सुरक्षित हों
• उन सामग्री के लिए CSS बैकग्राउंड छवियां जिन्हें देखा जाना चाहिए
• कॉलम लेआउट के लिए निर्भरता के रूप में फ्लेक्सबॉक्स या ग्रिड

Outlook आमतौर पर वह क्लाइंट है जो इन निर्णयों को सबसे पहले उजागर करता है, लेकिन यह एकमात्र नहीं है। Gmail ऐप्स और फॉरवर्ड किए गए संदेश भी उन्हें उजागर कर सकते हैं।

ट्रेड-ऑफ सरल है। आधुनिक CSS ब्राउज़र प्रोजेक्ट में कोड को कम करता है। ईमेल में, रूढ़िवादी CSS रेंडरिंग विफलताओं को कम करता है। रिस्पॉन्सिव अभियानों के लिए जिन्हें पेशेवर दिखने की आवश्यकता है और फिर भी Gmail के साथ मेल मर्ज से भेजना व्यावहारिक है, रूढ़िवादी आमतौर पर तेज़ी से शिप होता है और कम टूटता है।

उन्नत तकनीकों और सर्वोत्तम प्रथाओं को लागू करना

रिस्पॉन्सिव संरचना लेआउट को पढ़ने योग्य रखती है। अगला काम संदेश के आपके एडिटर को छोड़ने और Gmail, Apple Mail, Outlook और फॉरवर्ड किए गए थ्रेड्स में उतरने के बाद क्लिक करने की क्षमता, स्पष्टता और डिलीवरी की रक्षा करना है।

यह उस टेम्प्लेट के बीच का अंतर है जो प्रीव्यू पैन में ठीक दिखता है और वह जिसे आप टूटे हुए बटनों या अपठनीय टेक्स्ट के बारे में उत्तर प्राप्त किए बिना Gmail के साथ मेल मर्ज से मज़बूती से भेज सकते हैं।

छवियों को लचीला बनाएं, नाजुक नहीं

छवियों को स्पष्ट रूप से सिकुड़ना चाहिए, डेस्कटॉप पर इच्छित चौड़ाई पर रेंडर होना चाहिए, और यदि उन्हें ब्लॉक किया गया है तो भी कुछ संवाद करना चाहिए। व्यवहार में, इसका मतलब HTML width विशेषता सेट करना, इसे इनलाइन width:100% के साथ जोड़ना, और height:auto रखना है ताकि छवि बिना विरूपण के स्केल हो सके।

एक भरोसेमंद छवि पैटर्न इस तरह दिखता है:

<img src="hero.jpg" alt="Product preview" width="640" style="display:block; width:100%; max-width:640px; height:auto; border:0;">

मैं महत्वपूर्ण कॉपी को भी जब भी संभव हो हीरो ग्राफिक्स से बाहर रखता हूं। Gmail और Apple Mail आमतौर पर यहाँ अच्छा व्यवहार करते हैं। यदि छवि हेडलाइन, CTA, या मूल्य निर्धारण ले जाती है तो Outlook जल्दी ही एक समस्या बन जाता है।

टाइपोग्राफी और बटन जो टचस्क्रीन पर टिके रहते हैं

मोबाइल पाठक पहले स्कैन करते हैं। घनी कॉपी, कमजोर पदानुक्रम, और छोटे लिंक को अनदेखा कर दिया जाता है।

एक सुरक्षित आधार सरल है:

• 16px या उससे बड़े पर बॉडी कॉपी
• पैराग्राफ टेक्स्ट से स्पष्ट आकार कूद के साथ हेडिंग
• दृश्यमान स्पेसिंग के साथ छोटे पैराग्राफ
• माध्यमिक लिंक से पहले एक प्राथमिक CTA

टच टारगेट के लिए, Apple के ह्यूमन इंटरफेस दिशानिर्देश टैप करने योग्य नियंत्रणों के लिए 44 गुणा 44 पिक्सेल का व्यावहारिक न्यूनतम उपयोग करते हैं। यह ईमेल बटनों के लिए भी एक अच्छा आधार है, खासकर यदि संदेश सीधे Gmail से भेजा जा रहा है जहाँ आपको उन्नत ऐप-जैसी इंटरैक्शन पैटर्न नहीं मिलते हैं।

एक बुलेटप्रूफ बटन अभी भी सबसे अच्छा काम करता है:

<table role="presentation" cellspacing="0" cellpadding="0" border="0">
  <tr>
    <td bgcolor="#2DA05D" style="border-radius:4px; text-align:center;">
      <a href="https://example.com"
         style="display:inline-block; padding:14px 24px; font-family:Arial, sans-serif; font-size:16px; line-height:20px; color:#ffffff; text-decoration:none;">
         View details
      </a>
    </td>
  </tr>
</table>

टेबल रैपर मायने रखता है। यह Outlook को एक संरचना देता है जिसका वह सम्मान करता है, जबकि एंकर अभी भी बेहतर क्लाइंट्स में एक आधुनिक बटन की तरह दिखता है और महसूस होता है।

छोटे विज़ुअल विवरण भी यहाँ मदद करते हैं। ईमेल हस्ताक्षर ब्लॉक के लिए साफ आइकन बिना अव्यवस्था जोड़े या उपयोगकर्ताओं को संपर्क लिंक खोजने के लिए मजबूर किए बिना फुटर क्रियाओं को व्यवस्थित कर सकते हैं।

डार्क मोड को अपने स्वयं के पास की आवश्यकता है

डार्क मोड उन ईमेल को तोड़ देता है जो एक घंटे पहले समाप्त दिख रहे थे। लोगो गायब हो जाते हैं। PNGs के अंदर गहरा टेक्स्ट मटमैला हो जाता है। बटन कंट्रास्ट पढ़ने के आरामदायक स्तर से नीचे गिर जाता है।

SitePoint का रिस्पॉन्सिव ईमेल लेख नोट करता है कि डार्क मोड व्यवहार क्लाइंट्स में भिन्न होता है, जो परीक्षण में दिखाई देने वाली चीज़ों से मेल खाता है। कोई एक समाधान नहीं है, इसलिए व्यावहारिक दृष्टिकोण रक्षात्मक डिज़ाइन है:

• लाइव HTML टेक्स्ट को टेक्स्ट के रूप में रखें
• हल्के और गहरे दोनों बैकग्राउंड पर लोगो को टेस्ट करें
• पारदर्शी संपत्तियों से बचें जो गहरे अक्षरों पर निर्भर करती हैं
• दोनों मोड में CTA कंट्रास्ट की जांच करें
• छवियों पर टेक्स्ट को उच्च-जोखिम के रूप में मानें

यदि कोई तत्व केवल एक रंग योजना में काम करता है, तो वह समाप्त नहीं हुआ है।

कुछ भी ट्रिम करें जो जगह नहीं कमाता है

रिस्पॉन्सिव ईमेल तब बेहतर होता है जब अनावश्यक भागों को जल्दी हटा दिया जाता है। सजावटी डिवाइडर, अतिरिक्त नेविगेशन, और शीर्ष के पास स्टैक की गई सामाजिक पंक्तियाँ पाठक को मुख्य कार्रवाई पूरी करने में मदद किए बिना वजन जोड़ती हैं।

यह और भी मायने रखता है यदि आपका वर्कफ़्लो Gmail मेल मर्ज में समाप्त होता है। आप अक्सर पूर्ण ESP की सुरक्षा रेल के बिना व्यावहारिक आउटरीच, अपडेट, ऑनबोर्डिंग नोट्स, या छोटे अभियान भेज रहे होते हैं। एक तंग ईमेल को टेस्ट करना आसान है, स्कैन करना आसान है, और जब उत्तर, फॉरवर्ड, या क्लाइंट-साइड रीराइट चित्र में आते हैं तो स्वरूपण समस्याओं को ट्रिगर करने की संभावना कम होती है।

यही सिद्धांत डिलीवरी पर लागू होता है। हल्के, केंद्रित संदेशों को भेजने से पहले बनाए रखना और समीक्षा करना आसान होता है। यदि Gmail प्लेसमेंट पहले से ही एक चिंता का विषय है, तो एक बड़ा मेल मर्ज बैच भेजने से पहले Gmail में ईमेल को स्पैम में जाने से कैसे रोकें पर इस चेकलिस्ट की समीक्षा करें।

Gmail से टेस्ट करने और भेजने के लिए आपका वर्कफ़्लो

इनबॉक्स प्रदाता ईमेल HTML को फिर से लिखना जारी रखते हैं, और Gmail शीर्ष पर अपनी खुद की विचित्रताएं जोड़ता है। एक रिस्पॉन्सिव ईमेल केवल कोड एडिटर से लाइव इनबॉक्स तक उस पथ से बचने के बाद तैयार होता है।

पूर्ण ESP के बजाय Gmail मेल मर्ज के माध्यम से भेजने वाली टीमों के लिए, वर्कफ़्लो मार्कअप जितना ही मायने रखता है। लक्ष्य सरल है: एक विश्वसनीय HTML टेम्प्लेट बनाएं, विफलता बिंदुओं को पहले टेस्ट करें, फिर एक ऐसा संस्करण भेजें जिसे Gmail अंतिम चरण के दौरान खराब न करे।

उन हिस्सों को टेस्ट करें जो सबसे ज्यादा मायने रखते हैं

उन तत्वों के साथ शुरुआत करें जो अभियानों को तोड़ते हैं, न कि कॉस्मेटिक विवरणों के साथ। यदि हीरो इमेज बुरी तरह से क्रॉप होती है, बटन पैडिंग खो देता है, या मोबाइल पर बॉडी कॉपी सिकुड़ जाती है, तो ईमेल विफल हो जाता है, भले ही बाकी सब ठीक दिखे।

इस प्री-सेंड चेकलिस्ट का उपयोग करें:

• हीरो इमेज: क्या यह बिना विरूपण के स्केल होती है, और यदि छवियां ब्लॉक हैं तो क्या संदेश अभी भी काम करता है?
• प्राथमिक CTA: क्या यह शीर्ष के पास दिखाई देता है, टैप करने में आसान है, और डार्क मोड में पढ़ने योग्य है?
• बॉडी कॉपी: क्या यह बिना पिंच या ज़ूम किए फोन पर पढ़ने योग्य रहती है?
• लेआउट स्थिरता: क्या टेबल Outlook, Gmail और Apple Mail में अपनी चौड़ाई और स्पेसिंग रखती हैं?
• वैयक्तिकरण फ़ील्ड: क्या मर्ज टैग लंबे नामों, खाली फ़ील्ड और फॉलबैक टेक्स्ट के साथ स्पष्ट रूप से रेंडर होते हैं?
• लिंक समीक्षा: क्या प्रत्येक ट्रैक किया गया लिंक सही गंतव्य पर जाता है?

वह क्रम समय बचाता है। मैं स्पेसिंग या मामूली टाइपोग्राफी से पहले CTA और लेआउट समस्याओं को ठीक करता हूं क्योंकि वे वे समस्याएं हैं जो क्लिक की लागत लेती हैं।

वास्तविक क्लाइंट स्थितियों में मान्य करें

ब्राउज़र प्रीव्यू एक मोटा चेक है, अंतिम चेक नहीं। वास्तविक उपकरणों पर वास्तविक खातों के लिए टेस्ट संदेश भेजें।

कम से कम, संदेश की समीक्षा करें:

• Android पर Gmail
• iPhone पर Apple Mail
• Windows पर Outlook
• Gmail वेबमेल
• Apple Mail डेस्कटॉप

Outlook अभी भी विशेष ध्यान देने योग्य है। एक लेआउट जो Gmail में ठीक दिखता है, वह अतिरिक्त स्पेसिंग उठा सकता है, आधुनिक CSS को अनदेखा कर सकता है, या Word-आधारित रेंडरिंग शामिल होने पर बटनों को असंगत रूप से रेंडर कर सकता है। यदि ईमेल मिश्रित दर्शकों के पास जा रहा है, तो मैं Outlook और Gmail को आधार जोड़ी के रूप में मानता हूं और सुनिश्चित करता हूं कि कुछ भी व्यापक भेजने से पहले दोनों स्थिर हैं।

यदि आप ड्राफ्ट के अंदर टेबल संरचना का निवारण कर रहे हैं, तो Gmail संदेश में टेबल कैसे डालें की समीक्षा करें। यह आपको यह पहचानने में मदद करता है कि कब पेस्ट की गई सामग्री या Gmail संपादन ने आपके द्वारा बनाई गई संरचना को बदल दिया है।

यदि CTA एक प्रमुख क्लाइंट में टूट जाता है, तो इसे लॉन्च ब्लॉकर के रूप में मानें।

HTML को नुकसान पहुँचाए बिना Gmail से भेजना

Gmail सुविधाजनक है, लेकिन यह एक विकास वातावरण नहीं है। सामान्य विफलता बिंदु अंतिम मील है: एक टेस्ट किए गए ईमेल को Gmail में पेस्ट करना, मर्ज फ़ील्ड जोड़ना, फिर यह खोजना कि स्पेसिंग, फ़ॉन्ट, या टेबल संरेखण बदल गया है।

एक नियंत्रित सेंड प्रक्रिया का उपयोग करें:

1. Gmail के बाहर HTML बनाएं और अंतिम रूप दें।
2. अपने स्वयं के सीड लिस्ट पर टेस्ट संदेश भेजें और उन्हें लक्षित क्लाइंट्स पर समीक्षा करें।
3. केवल स्वीकृत संस्करण आयात या पेस्ट करें।
4. वैयक्तिकरण सावधानीपूर्वक जोड़ें और प्रत्येक मर्ज फ़ील्ड का प्रीव्यू करें।
5. पहले एक छोटे आंतरिक सेगमेंट को भेजें।
6. रेंडरिंग, लिंक और उत्तरों की जांच करें।
7. पूर्ण मेल मर्ज बैच केवल तभी भेजें जब वह संस्करण पास हो जाए।

यह वह व्यावहारिक अंतर है जिसे कई गाइड छोड़ देती हैं। वे रिस्पॉन्सिव सिद्धांत की व्याख्या करती हैं या मानती हैं कि आप इन-बिल्ट रेंडरिंग टूल के साथ एक बड़े ESP के अंदर काम कर रहे हैं। Gmail मेल मर्ज अभी भी आउटरीच, ऑनबोर्डिंग, हायरिंग ईमेल और छोटे अभियानों के लिए अच्छा काम कर सकता है, लेकिन केवल तभी जब HTML Gmail में प्रवेश करने से पहले स्थिर हो।

प्लेसमेंट भी मायने रखता है। यदि संदेश स्पैम में उतरता है तो एक साफ लेआउट बहुत मदद नहीं करेगा, इसलिए एक बड़ा मेल मर्ज बैच स्केल करने से पहले Gmail में ईमेल को स्पैम में जाने से कैसे रोकें की समीक्षा करें।

यहाँ एक वॉकथ्रू है जो अंतिम सेंडिंग फ्लो को क्रिया में दिखाने में मदद करता है:

इसका लाभ स्थिरता है। एक टेस्ट किया गया मास्टर टेम्प्लेट, एक दोहराने योग्य Gmail सेंड प्रक्रिया, और लॉन्च के बाद कम आश्चर्य।

यदि आप पूर्ण ESP वर्कफ़्लो में जाए बिना सीधे Gmail से वैयक्तिकृत, ट्रैक करने योग्य रिस्पॉन्सिव ईमेल भेजना चाहते हैं, तो Mail Merge for Gmail आपको Google Sheets डेटा, कस्टम टेम्प्लेट, प्रीव्यू और उन टूल के अंदर सेंड ट्रैकिंग के साथ ऐसा करने का एक व्यावहारिक तरीका देता है जिनका आपकी टीम पहले से उपयोग करती है।