Bab 6: Desain dan Teknis

Desain email di tahun 2026 adalah disiplin yang aneh. Anda merancang untuk medium yang ditampilkan berbeda di puluhan klien email, pada layar mulai dari smartwatch hingga monitor ultrawide, dalam mode terang dan gelap, dengan batasan teknologi yang akan membuat developer web menangis. Namun, email yang berkinerja terbaik seringkali yang paling sederhana.

Bab ini membahas fondasi teknis yang membuat email Anda tampil dengan benar, memuat dengan cepat, dan mengonversi dengan andal.

Desain Mobile-First

Lebih dari 60% email kini dibuka di perangkat mobile. Angka ini terus meningkat selama bertahun-tahun, dan tidak akan turun lagi. Yang lebih kritis, 64% pengguna mobile akan menghapus email yang tidak ditampilkan dengan baik di ponsel mereka. Bukan "tidak terlihat sempurna." Tapi "tidak berfungsi."

Mobile-first berarti merancang untuk layar terkecil terlebih dahulu, kemudian memperbesar.

Layout satu kolom adalah pendekatan yang paling aman dan paling efektif. Desain multi-kolom yang terlihat bagus di desktop runtuh secara tidak terduga di mobile, seringkali menumpuk dalam urutan yang salah atau menciptakan mimpi buruk gulir horizontal. Satu kolom dengan teks, gambar, dan tombol berukuran tepat berfungsi di mana saja.

Pertahankan lebar email antara 600 dan 640 piksel. Ini adalah standar yang berfungsi di berbagai klien email terluas. Lebih lebar dari 640px dan Anda berisiko gulir horizontal pada layar yang lebih kecil dan di klien email yang menambahkan panel samping.

Tombol ramah sentuh harus berukuran minimal 44x44 piksel. Ini adalah Human Interface Guideline Apple untuk target ketuk minimum, dan saya sebenarnya menyarankan untuk sedikit lebih besar, 46x46 piksel, untuk mengakomodasi ketukan yang kurang presisi. Tidak ada yang lebih cepat mematikan keterlibatan email mobile daripada tombol yang terlalu kecil untuk diketuk dengan akurat.

Ukuran font harus minimal 13px di iPhone. Apa pun yang lebih kecil dari 13px di iOS memicu zoom otomatis, yang merusak layout Anda. Gunakan 14-16px untuk teks isi dan 20-22px untuk judul. Lebih besar hampir selalu lebih baik di mobile.

Baris subjek harus tetap di bawah 30 karakter untuk visibilitas mobile. Sebagian besar klien email mobile memotong baris subjek antara 30 dan 40 karakter tergantung pada perangkat dan apakah teks pratinjau ditampilkan. Tempatkan kata-kata penting di depan.

Gunakan media query untuk gambar yang dioptimalkan untuk mobile. Sajikan file gambar yang lebih kecil ke perangkat mobile, baik untuk kecepatan muat maupun penggunaan data. Gambar yang dimuat dalam 1 detik di Wi-Fi mungkin membutuhkan 5 detik pada koneksi mobile yang buruk, dan pembaca Anda tidak akan menunggu.

Ukuran file gambar lebih penting dari yang kebanyakan pemasar sadari. Pertahankan gambar individual di bawah 200KB dan total berat email di bawah 800KB. Kompres semua gambar sebelum mengunggah. Gunakan TinyPNG atau Squoosh untuk kompresi tanpa kerugian. Banyak ESP mengubah ukuran gambar secara langsung, tetapi tidak selalu mengompresnya secara cukup agresif.

Gunakan font web-safe sebagai tumpukan utama Anda. Font kustom dalam email memiliki dukungan yang tidak konsisten. Arial, Helvetica, Georgia, dan Verdana dirender secara andal di mana saja. Anda dapat menentukan font web kustom sebagai pilihan pertama dan kembali ke font web-safe untuk klien yang tidak mendukungnya, tetapi ketahuilah bahwa mayoritas pembaca Anda akan melihat fallback. Rancang dengan mempertimbangkan fallback, bukan font kustom.

Pratinjau email Anda di perangkat nyata, bukan hanya di browser Anda. Pratinjau browser desktop menyesatkan. Email yang terlihat sempurna di pratinjau Chrome Anda mungkin memiliki teks yang tumpang tindih di iPhone SE atau gambar yang terpotong di aplikasi Gmail di Android. Gunakan Litmus, Email on Acid, atau minimal kirimkan tes kepada diri sendiri dan periksa di ponsel Anda sebelum mengirim.

Layar Retina dan DPI tinggi memerlukan gambar 2x. Jika kolom email Anda lebar 600px dan Anda menggunakan gambar selebar 600px, gambar akan terlihat buram pada layar Retina (yang merupakan sebagian besar ponsel dan laptop modern). Ekspor gambar pada 2x ukuran tampilan (1200px untuk kolom 600px) dan atur lebar di HTML ke ukuran tampilan. File akan lebih besar, sehingga kompresi menjadi semakin penting.

Kompatibilitas Klien Email

Inilah kebenaran yang tidak nyaman tentang pengembangan email: Anda masih membangun dengan tabel. Di tahun 2026. Sementara web telah beralih ke CSS Grid dan Flexbox, email tetap terikat pada tabel HTML untuk layout.

Mengapa? Karena Microsoft Outlook menggunakan mesin rendering Word (ya, pengolah kata) untuk menampilkan email HTML. Dan Outlook memiliki pangsa pasar yang cukup, terutama di B2B, sehingga Anda tidak bisa mengabaikannya. Tabel dirender secara konsisten di mesin Word. CSS modern tidak.

Gunakan CSS inline. Sebagian besar klien email menghapus stylesheet eksternal dan banyak yang menghapus style dari <head>. Satu-satunya cara yang dapat diandalkan untuk memastikan style Anda diterapkan adalah dengan menyisipkannya langsung pada setiap elemen. Setiap alat build email yang serius menangani ini secara otomatis selama ekspor.

Desain responsif menggunakan media query berfungsi di sebagian besar klien email modern: Apple Mail, iOS Mail, aplikasi Gmail, Outlook mobile, Yahoo. Klien web desktop Gmail secara teknis mendukung media query, tetapi karena email ditampilkan di jendela pratinjau yang lebih kecil daripada viewport penuh, query sering tidak aktif. Ini sama untuk sebagian besar klien webmail, meskipun beberapa menggunakan iframe untuk menampilkan email, di mana media query akan berfungsi. Membangun mobile-first membantu di sini, karena media query tersebut akan diaktifkan. Untuk kompatibilitas yang lebih luas, desain hybrid adalah jaring pengaman Anda.

Desain hybrid (juga disebut desain spongy) adalah fallback Anda. Ini menggunakan layout fluida, lebar berbasis persentase, dan komentar bersyarat untuk membuat email yang beradaptasi dengan ukuran layar tanpa bergantung pada media query. Ini bisa dilakukan dengan atau tanpa tabel. Mark Robbins umumnya merekomendasikan menggunakan div dengan ghost table, yang menghindari banyak masalah berantai yang disebabkan tabel. Email terlihat bagus di lebar mana pun karena struktur dasarnya fleksibel secara default.

Mark Robbins (sekarang Developer Advocate untuk Email Experience di Customer.io) telah menjadi pelopor teknik CSS-only untuk email yang mendorong batas yang memungkinkan tanpa JavaScript (yang diblokir di semua klien email). Karyanya pada komponen interaktif CSS-only, peningkatan aksesibilitas, dan progressive enhancement telah memajukan bidang ini secara signifikan. Jika Anda membangun email pada tingkat teknis, pelajari karyanya.

Perbedaan rendering klien email umum yang perlu diuji:

Outlook desktop (2019/2021/365) menggunakan mesin rendering Word, yang berarti: tidak ada dukungan untuk gambar latar belakang CSS, kontrol padding terbatas, dan spasi tabel yang tidak terduga. VML (Vector Markup Language) secara tradisional direkomendasikan untuk gambar latar belakang di Outlook, tetapi Mark Robbins menyoroti bahwa VML menyebabkan masalah aksesibilitas yang serius dan merekomendasikan untuk menghindarinya. Pertimbangkan menggunakan warna latar belakang solid sebagai fallback untuk Outlook.

Gmail web menghapus semua style dari <head> jika melebihi ambang ukuran tertentu (sekitar 16KB, meningkat dari batas sebelumnya ~8.192 karakter). Jika CSS Anda kompleks, beberapa style akan diam-diam dihapus. Dan meskipun Gmail secara teknis mendukung media query, ukuran jendela pratinjau berarti jarang diaktifkan di klien web, itulah mengapa desain hybrid penting.

Apple Mail adalah klien email yang paling sesuai dengan standar dan mendukung hampir segalanya, termasuk media query, animasi CSS, dan @supports. Ini adalah klien yang ideal untuk dikembangkan, tetapi jangan biarkan itu membuat Anda berpikir bahwa klien lain akan berperilaku sama.

Yahoo Mail dan AOL telah meningkat secara signifikan dalam beberapa tahun terakhir tetapi masih memiliki keanehan seputar dukungan media query dan penanganan margin. selalu uji.

Alat Desain Email

Ekosistem alat untuk desain email telah berkembang secara signifikan. Inilah yang akan saya rekomendasikan di tahun 2026, dibagi berdasarkan kasus penggunaan.

Mari saya jelaskan lebih lanjut dengan konteks lebih.

Builder no-code untuk tim pemasaran:

Beefree (sebelumnya BEE) adalah rekomendasi teratas saya untuk tim yang perlu membangun email dengan cepat tanpa coding. Antarmuka drag-and-drop benar-benar bagus, dan fitur modul tersimpan memungkinkan Anda membangun perpustakaan komponen yang dapat digunakan kembali. Stripo adalah pilihan terbaik jika Anda membutuhkan dukungan AMP for Email atau ingin mengakses perpustakaan template yang besar (1.400+ template). Chamaileon dibangun untuk tim enterprise yang membutuhkan tata kelola merek dan alur kerja persetujuan yang tertanam dalam proses pembuatan email.

Platform pengujian:

Litmus tetap menjadi standar emas, menawarkan pratinjau di lebih dari 90 kombinasi klien email dan perangkat. Tidak murah, tetapi jika Anda mengirim ke audiens yang beragam (dan kemungkinan besar Anda melakukannya), melihat bagaimana email Anda dirender di Outlook 2019 di Windows vs Apple Mail di macOS vs Gmail di Android adalah hal yang penting. Email on Acid menawarkan pratinjau rendering serupa ditambah pengujian spam dengan harga yang lebih rendah. Untuk tim dengan anggaran terbatas, ini adalah alternatif yang kuat.

Framework kode untuk developer:

MJML adalah bahasa markup yang dikompilasi ke email HTML responsif. Anda menulis markup yang bersih dan semantik, dan MJML menangani output berbasis tabel yang rumit. Ini adalah framework developer paling populer untuk email. Maizzle membawa Tailwind CSS ke pengembangan email, dengan pipeline build yang menangani inlining, pembuangan CSS yang tidak digunakan, dan menghasilkan HTML siap produksi. React Email memungkinkan Anda membangun template email menggunakan komponen React dalam ekosistem npm. Jika tim Anda sudah berpikir dalam komponen, ini adalah pilihan yang alami. Parcel (bukan web bundler, IDE email) menyediakan pratinjau real-time dan petunjuk dukungan CSS saat Anda coding.

Alur kerja design-to-code:

Alur kerja Figma to Email semakin umum. Tim desain membuat template email di Figma menggunakan pustaka komponen, kemudian mengekspor ke HTML baik melalui plugin maupun dengan menyerahkan desain ke developer yang mengimplementasikannya di MJML atau Maizzle.

Desain Email Bertenaga AI

Lanskap alat desain berubah secara signifikan pada awal 2026, dan desain bertenaga AI bukan lagi teori. Inilah yang benar-benar dapat digunakan hari ini.

Figma MCP + Claude Code ("Code to Canvas") adalah perkembangan paling signifikan. Diumumkan pada Februari 2026, integrasi MCP Figma menciptakan koneksi dua arah antara file desain dan alat pengkodean AI. Claude memeriksa desain Figma secara semantis — memahami sistem desain, hierarki komponen, token spasi, dan niat, bukan hanya piksel. Untuk email, deskripsikan yang Anda inginkan ("buat bagian hero email yang sesuai dengan kit merek kami dengan gambar lebar penuh, judul, sub-judul, dan tombol CTA") dan dapatkan desain yang menghormati sistem desain Figma Anda yang ada. Dikombinasikan dengan MJML atau React Email, alur kerja ini beralih dari brief desain ke template email siap produksi dalam hitungan menit, bukan jam.

Paper.design adalah kanvas desain yang didukung MCP dengan 24 alat yang native untuk HTML dan CSS. Tidak seperti Figma yang menghasilkan vektor yang perlu dikonversi, Paper bekerja di medium yang sebenarnya digunakan email. Dua arah dengan Claude Code dan Cursor — agen AI dapat memeriksa artboard, memodifikasi layout, menulis HTML, dan memperbarui style. Token desain disinkronkan dari Figma, data API nyata mengisi UI, dan output dikonversi ke React atau Tailwind. Tingkatan gratis (100 panggilan MCP per minggu) dan Pro ($20 per bulan, 1M panggilan per minggu). Bagi desainer email yang ingin desain berbantuan AI tanpa meninggalkan lingkungan native HTML, Paper menghilangkan seluruh langkah konversi dari alur kerja.

Cursor untuk pengembangan email layak disebut karena telah menjadi lingkungan pengkodean AI de facto, dan template email adalah kode. Desainer yang menggunakan MJML atau React Email dapat beriterasi 10x lebih cepat di Cursor daripada di editor tradisional. Deskripsikan perubahan yang Anda inginkan dalam bahasa alami, Cursor menulis kodenya, Anda melihat pratinjau hasilnya. Bagi tim yang telah memindahkan pengembangan email ke kode (yang, menurut bagian framework di atas, adalah arah yang dituju), Cursor memperpendek loop umpan balik antara "saya ingin ini" dan "ini dia."

Alur kerja design-from-Claude Nitrosend memungkinkan Anda merancang template email sepenuhnya melalui bahasa alami, baik melalui server MCP di Claude maupun melalui chat AI bawaan Nitrosend. "Buat etalase produk dua kolom dengan logo kami di header, tiga kartu produk dengan gambar dan harga, dan tombol CTA hijau" menghasilkan template yang dirender yang dapat Anda iterasi secara percakapan. Bagi pendiri solo dan tim kecil tanpa sumber daya desain, ini menghilangkan hambatan desain sepenuhnya. Saat ini dalam beta tertutup.

Alat desain AI lain yang perlu diperhatikan:

Mailmodo menawarkan pembuatan email AI dari ujung ke ujung — deskripsikan email yang Anda inginkan, dan ini menghasilkan email interaktif lengkap dengan dukungan AMP. EmailCanvasAI menghasilkan template email dari prompt teks. Generator Template AI Mailjet membuat desain titik awal dari deskripsi singkat. Ini adalah alat tahap awal, tetapi mereka menandakan arah: desain email beralih dari "bangun secara visual" ke "deskripsikan secara percakapan."

Rekomendasi praktis: Jika tim Anda sudah menggunakan Figma, jelajahi alur kerja Figma MCP + Claude Code untuk sistem desain Anda. Jika Anda developer-first, Cursor dengan MJML atau React Email adalah jalur tercepat menuju pengembangan email berbantuan AI. Jika Anda tim kecil tanpa sumber daya desain atau pengembangan yang berdedikasi, pendekatan desain AI Nitrosend atau Mailmodo menghilangkan hambatan sepenuhnya. Dan jika Anda menginginkan kontrol maksimal atas desain native HTML dengan bantuan AI, Paper.design layak dievaluasi.

Template No-Code vs Template Berkode

Ini bukan keputusan satu atau yang lain. Ini tentang mencocokkan pendekatan dengan kasus penggunaan.

Alat no-code 3 hingga 5 kali lebih cepat untuk kampanye satu kali. Ketika Anda perlu membangun satu email promosi, builder drag-and-drop membawa Anda ke sana dalam 30 menit, bukan 3 jam. Gunakan Beefree, Stripo, atau builder bawaan ESP Anda.

Template berkode lebih baik untuk alur berulang, kontrol versi, dan sistem desain. Ketika Anda membangun seri selamat datang yang akan dikirim ke ribuan pelanggan selama berbulan-bulan atau bertahun-tahun, berinvestasi dalam template yang dikodekan dengan benar akan memberikan hasil yang setimpal. Template berkode dapat disimpan dalam kontrol versi (Git), ditinjau dalam pull request, dan diperbarui secara sistematis di seluruh alur.

Sebagian besar program email yang matang menggunakan keduanya. Template berkode untuk alur otomatis (selamat datang, keranjang yang ditinggalkan, pasca pembelian) dan alat no-code untuk kampanye satu kali (peluncuran produk, promosi musiman, pengumuman). Pendekatan hybrid ini memberi Anda konsistensi di tempat yang penting dan kecepatan di tempat yang Anda butuhkan.

Sistem Desain Template Email

Jika Anda mengirim lebih dari segelintir jenis email, Anda memerlukan sistem desain. Bukan template. Sebuah sistem.

Token merek mendefinisikan konstanta: warna primer dan sekunder Anda, tumpukan font, unit spasi standar (8px, 16px, 24px, 32px), radius batas untuk tombol, dan konstanta visual lainnya. Dokumentasikan ini sekali dan referensikan di mana saja.

Pustaka komponen berisi blok pembangun: header (logo, navigasi), bagian hero (gambar, judul, CTA), blok teks (judul, isi, tautan), kartu produk (gambar, judul, harga, tombol), tombol CTA (primer, sekunder, tautan teks), dan footer (tautan sosial, teks hukum, berhenti berlangganan). Setiap komponen memiliki perilaku responsif yang ditentukan, perlakuan mode gelap, dan persyaratan aksesibilitas.

Template layout menggabungkan komponen ke dalam jenis email standar: email promosi, newsletter, notifikasi transaksional, email selamat datang, keranjang yang ditinggalkan. Ini adalah titik awal Anda, bukan kendala Anda.

Panduan penggunaan memberi tahu tim Anda kapan menggunakan apa, berapa banyak teks yang harus disertakan, komponen mana yang wajib (footer, berhenti berlangganan) versus opsional, dan aturan merek apa pun seputar gambar, nada, atau penempatan CTA.

Membangun sistem desain membutuhkan waktu di awal. Untuk merek e-commerce yang khas, perkirakan 40 hingga 60 jam kerja pengembangan awal. Tetapi investasi tersebut terbayar dengan cepat. Setelah sistem terpasang, membangun email baru turun dari 3 hingga 4 jam menjadi 30 hingga 60 menit. Dan setiap email yang Anda kirim secara otomatis sesuai merek dan aksesibel.

Jika Anda adalah tim yang lebih kecil tanpa sumber daya untuk sistem desain lengkap, mulailah dengan satu template master yang dibangun dengan baik yang mencakup jenis email yang paling umum (biasanya email promosi). Bangun dengan benar sekali, dengan dukungan mode gelap, fitur aksesibilitas, dan optimasi mobile. Kemudian adaptasikan untuk setiap pengiriman. Itu bukan sistem desain, tetapi menyelesaikan 80% masalahnya.

Aksesibilitas

Paul Airy telah menjadi suara terdepan dalam aksesibilitas email selama bertahun-tahun, dan pesan utamanya layak diulang: email yang aksesibel bukan hanya hal yang benar untuk dilakukan, mereka berkinerja lebih baik untuk semua orang.

Diperkirakan 15 hingga 20% orang memiliki suatu bentuk disabilitas. Itu termasuk gangguan penglihatan, disabilitas motorik, perbedaan kognitif, dan disabilitas situasional (seperti membaca email dengan satu tangan sambil menggendong bayi). Merancang untuk aksesibilitas berarti merancang untuk semua dari mereka, dan dalam prosesnya, Anda membuat email menjadi lebih baik untuk 80% lainnya juga.

Persyaratan WCAG 2.1 untuk email:

Kontras warna harus memenuhi rasio 4,5:1 untuk teks normal dan 3:1 untuk teks besar. Gunakan alat pemeriksa kontras. Apa yang terlihat bagus di monitor kelas atas Anda mungkin tidak terbaca di layar yang lebih murah di bawah sinar matahari yang terang.

Semua gambar harus memiliki teks alt yang deskriptif. Bukan "image1.jpg" atau "spanduk." Jelaskan apa yang ditunjukkan gambar dan apa yang perlu diketahui pembaca. Jika gambar murni dekoratif, gunakan atribut alt kosong (alt="") sehingga pembaca layar melewatinya.

Pertahankan urutan membaca yang logis. Pembaca layar mengikuti urutan sumber HTML, bukan layout visual. Pastikan konten Anda masuk akal ketika dibaca secara linier, dari atas ke bawah.

Sertakan atribut bahasa (lang="en") dan atribut arah (dir="ltr") pada elemen HTML Anda sehingga pembaca layar menggunakan model pengucapan yang benar dan arah teks.

Tautan harus memiliki tujuan yang jelas dari teksnya saja. "Klik di sini" tidak bermakna di luar konteks. "Unduh Laporan Benchmark Email 2026" memberi tahu pembaca dengan tepat ke mana tautan mengarah.

Jangan mengandalkan warna saja untuk menyampaikan informasi. Jika harga ditampilkan dengan warna merah untuk menunjukkan penjualan, sertakan juga teks yang mengatakan "Harga jual" atau gunakan coretan pada harga asli.

Gunakan teks yang dapat diskalakan. Jangan pernah menetapkan ukuran font dalam piksel yang tidak dapat diganti oleh preferensi pengguna.

Pastikan navigabilitas keyboard. Semua elemen interaktif harus dapat dijangkau dan dioperasikan melalui keyboard.

Pada tabel layout, tambahkan role="presentation" untuk memberi tahu pembaca layar bahwa tabel digunakan untuk layout, bukan data. Tanpa atribut ini, pembaca layar akan mencoba mengurai layout Anda sebagai tabel data, menciptakan pengalaman yang membingungkan.

Target sentuh minimal 44x44px bukan hanya praktik terbaik mobile. Ini adalah persyaratan aksesibilitas. Pengguna dengan disabilitas motorik membutuhkan ukuran target yang memadai.

Aksesibilitas bukan daftar periksa yang Anda selesaikan sekali. Ini adalah praktik yang Anda pertahankan di setiap email. Tambahkan tinjauan aksesibilitas ke proses QA email Anda. Sebelum setiap pengiriman, periksa: apakah setiap gambar memiliki teks alt? Apakah urutan membaca logis? Apakah semua tombol dan tautan memiliki ukuran dan kontras yang cukup? Dapatkah Anda memahami email jika Anda menyipitkan mata dan hanya dapat membaca judul dan teks tautan? Jika jawabannya tidak untuk salah satu dari ini, perbaiki sebelum mengirim.

Pengujian pembaca layar adalah standar terbaik. Jika Anda benar-benar ingin memahami seberapa aksesibel email Anda, ujilah dengan pembaca layar nyata. VoiceOver di Mac dan iOS, NVDA di Windows, dan TalkBack di Android semuanya gratis. Mendengarkan email Anda dibacakan keras oleh pembaca layar akan mengungkap masalah yang tidak akan pernah terlihat melalui inspeksi visual. Bertujuanlah untuk melakukan ini setidaknya sekali per kuartal pada template yang paling sering digunakan.

Mode Gelap

Setidaknya 33% penerima email melihat email dalam mode gelap, dan persentase itu terus bertumbuh. Mode gelap dapat merusak desain email yang tidak dibangun untuk mengatasinya.

Klien email menangani mode gelap secara berbeda. Beberapa membalikkan warna. Beberapa menukar latar belakang. Beberapa melakukan keduanya. Hasilnya bisa berupa teks hitam pada latar belakang hitam (tidak terlihat), tautan biru gelap pada latar belakang abu-abu gelap (hampir tidak terlihat), atau logo dengan latar belakang putih yang sekarang memiliki kotak putih yang mencolok di sekelilingnya.

Uji email Anda dalam mode gelap di Apple Mail, Gmail, dan Outlook. Ketiganya menangani mode gelap secara berbeda, dan bersama-sama mereka mencakup mayoritas pengguna mode gelap.

Gunakan PNG transparan untuk logo. Logo dengan latar belakang putih pada email putih terlihat bagus. Logo yang sama dalam mode gelap mendapatkan kotak putih di sekelilingnya. Latar belakang transparan menyelesaikan ini.

Hindari latar belakang putih murni. Gunakan off-white (#F5F5F5 atau serupa) untuk latar belakang isi email Anda. Dalam mode gelap, putih murni (#FFFFFF) dapat menciptakan kilatan yang menyilaukan. Off-white beradaptasi dengan lebih anggun dan lebih mudah di mata dalam kedua mode.

Gunakan media query CSS @media (prefers-color-scheme: dark) di mana didukung untuk memberikan style mode gelap yang eksplisit. Ini memberi Anda kendali atas bagaimana email Anda muncul dalam mode gelap daripada membiarkan klien email menebak. Dukungan bagus di Apple Mail dan Outlook. Gmail mengabaikannya dan menerapkan transformasi mode gelapnya sendiri.

Tips desain mode gelap praktis:

Gunakan batas atau bayangan halus di sekitar gambar dengan latar belakang putih atau terang agar tidak mengambang dalam mode gelap. Tambahkan batas 1px tipis dalam warna merek Anda di sekitar logo sebagai tindakan keamanan.

Untuk warna teks, hindari teks hitam murni (#000000) dalam mode terang. Gunakan abu-abu gelap (#333333 atau #222222) sebagai gantinya. Dalam mode gelap, klien email sering membalikkan hitam murni menjadi putih murni, yang dapat terlihat keras. Teks yang sedikit berbeda dari hitam murni akan terbalik menjadi sedikit berbeda dari putih murni, yang lebih mudah dibaca.

Uji tombol CTA Anda dalam kedua mode. Tombol yang sangat terlihat pada latar belakang putih mungkin menghilang pada latar belakang gelap. Pertimbangkan menambahkan batas pada tombol Anda agar tetap terlihat terlepas dari warna latar belakang.

Jika Anda menggunakan warna latar belakang di bagian konten (seperti kotak tips yang disorot atau spanduk berwarna), warna tersebut mungkin diubah atau dihapus dalam mode gelap. Selalu pastikan konten Anda dapat dibaca bahkan jika warna latar belakang kembali ke latar belakang gelap default klien email.

Email Interaktif

Elemen interaktif dalam email dapat meningkatkan keterlibatan secara signifikan. Tingkat klik setelah buka meningkat rata-rata 31,7% ketika elemen interaktif disertakan.

Tetapi interaktivitas dalam email datang dengan peringatan kritis: dukungan sangat bervariasi di berbagai klien email. Selalu bangun dengan mempertimbangkan progressive enhancement, sebuah konsep yang telah diperjuangkan Jason Rodriguez. Elemen interaktif Anda adalah bonus untuk klien yang mendukungnya. Fallback untuk klien yang tidak mendukung harus tetap menjadi email yang berfungsi penuh dan terlihat bagus.

Efek hover CSS memiliki dukungan yang luas dan memberikan peningkatan 5 hingga 10% dalam keterlibatan. Hal-hal sederhana seperti perubahan warna tombol saat hover, overlay gambar, atau animasi garis bawah. Ini adalah tambahan berisiko rendah, hadiah tinggi.

Akordeon bertenaga CSS memiliki dukungan sedang dan dapat memberikan peningkatan 10 hingga 15%. Mereka bekerja dengan baik untuk email yang padat konten seperti newsletter atau perbandingan produk, memungkinkan pembaca memperluas hanya bagian yang mereka pedulikan. Mereka tidak berfungsi di Gmail web atau Outlook, jadi fallback Anda harus menampilkan semua konten yang diperluas.

GIF animasi memiliki dukungan universal dan memberikan 5 hingga 8% lebih banyak keterlibatan. Setiap klien email mendukung GIF (dengan pengecualian beberapa versi desktop Outlook, yang hanya menampilkan frame pertama). Mereka adalah elemen interaktif paling aman yang dapat Anda gunakan. Demonstrasi produk, animasi halus, dan minat visual semuanya berfungsi dengan baik.

AMP for Email menawarkan interaktivitas paling kuat dengan peningkatan keterlibatan 20 hingga 30%, memungkinkan carousel, formulir, menu akordeon, dan bahkan konten langsung dalam email. Tetapi dukungan terbatas pada Gmail dan Yahoo, memerlukan pendaftaran pengirim Google, dan adopsi tetap rendah. Jika audiens Anda terutama di Gmail dan Anda memiliki sumber daya developer, AMP bisa sangat efektif. Untuk sebagian besar pengirim, belum sepadan investasinya.

Timer hitung mundur adalah elemen interaktif umum untuk email penjualan dan penawaran terbatas waktu. Mereka dihasilkan di sisi server sebagai GIF animasi yang menampilkan hitung mundur langsung. Layanan seperti Sendtric dan Mailmodo menawarkan generator timer hitung mundur gratis dan berbayar. Mereka berfungsi di hampir setiap klien email. Peringatan penting: gunakan hanya timer hitung mundur nyata untuk tenggat waktu nyata. Timer yang menghitung mundur ke penjualan yang diam-diam diperpanjang melatih pelanggan untuk mengabaikan urgensi Anda.

Survei dan polling yang tertanam dapat meningkatkan keterlibatan secara signifikan karena mengubah email dari siaran menjadi percakapan. Alat seperti Typeform dan SurveyMonkey menghasilkan polling satu pertanyaan yang dapat ditanamkan yang berfungsi di sebagian besar klien email. Untuk klien yang tidak mendukung versi tertanam, fallback-nya adalah tautan ke survei. bahkan polling satu pertanyaan dalam newsletter dapat meningkatkan tingkat klik sebesar 15 hingga 20%.

Aturan emas email interaktif: selalu bangun fallback terlebih dahulu. Rancang email Anda seolah tidak ada elemen interaktif yang akan berfungsi. Kemudian lapisi interaktivitas di atas untuk klien yang mendukungnya. Dengan cara ini, setiap pelanggan mendapatkan email yang berfungsi, dan mereka yang memiliki klien email modern mendapatkan sesuatu yang ekstra.