Nội dung & thiết kế · Nâng cao
Thiết kế email ưu tiên di động (mobile-first)
Bạn đã biết cách dựng một email responsive — bố cục co giãn, ảnh có thẻ alt, nút bấm đủ to. Bài này đi xa hơn một bước: tư duy mobile-first. Khác biệt nằm ở thứ tự thiết kế. “Responsive” thường là dựng email cho màn hình lớn rồi ép nó gọn lại trên điện thoại. “Mobile-first” làm ngược lại: thiết kế cho màn hình điện thoại trước, coi đó là trải nghiệm chính, rồi mới mở rộng cho desktop. Với phần lớn danh sách email tại Việt Nam, đây mới là cách phản ánh đúng nơi email thực sự được đọc.
Nếu bạn cần ôn lại nền tảng kỹ thuật (kích thước an toàn, nút bulletproof, dark mode), hãy đọc trước bài cơ bản Thiết kế email responsive đẹp trên mọi thiết bị. Bài hiện tại tập trung vào tư duy, thứ tự ưu tiên và quy trình kiểm chứng để email không chỉ “không vỡ” trên điện thoại mà còn chuyển đổi tốt ở đó.
1. Vì sao “mobile-first” chứ không chỉ “responsive”
Theo kinh nghiệm thực tế, phần lớn lượt mở email tại Việt Nam đến từ điện thoại — người ta lướt Gmail, Mail của iPhone hay Zalo Mail trong lúc di chuyển, xếp hàng, chờ thang máy. Màn hình hẹp, một tay cầm máy, ngón cái vuốt, mạng có khi chập chờn. Đó mới là điều kiện thật mà email của bạn phải sống sót, chứ không phải màn hình 24 inch của bạn khi đang thiết kế.
Sự khác biệt không chỉ là “câu chữ”. Khi bạn thiết kế desktop trước, bạn vô thức nhồi nhiều thứ vào: ba cột sản phẩm, một banner hero rộng, năm liên kết điều hướng trên cùng. Tất cả những thứ đó khi co lại trên điện thoại trở thành một dải dọc dài lê thê, người nhận cuộn mỏi tay mới tới nút mua. Khi bạn thiết kế điện thoại trước, sự chật chội của màn hình hẹp buộc bạn phải hỏi: thứ này có thật sự cần không? Kết quả là email gọn hơn, một thông điệp rõ hơn, một hành động chính rõ hơn — và điều đó tốt cho cả desktop.
Mobile-first là một kỷ luật cắt bớt, không phải một bộ CSS
Đừng nghĩ mobile-first là “thêm media query cho điện thoại”. Nó là một cách ra quyết định: mỗi khối, mỗi dòng, mỗi nút đều phải xứng đáng với khoảng không gian nhỏ bé trên màn hình hẹp. Nếu một khối không giúp người nhận hiểu hoặc hành động, hãy cắt nó — bất kể trên desktop nó “trông cũng được”.
2. Nguyên tắc một cột — và cách giữ kỷ luật khi nội dung phức tạp
Một cột dọc là nguyên tắc bất biến: nội dung xếp từ trên xuống, đọc bằng một ngón cái, không bao giờ phải cuộn ngang. Bạn đã biết điều này. Phần nâng cao là: làm sao giữ một cột khi nội dung muốn nhiều cột — ví dụ một email thương mại điện tử có 6 sản phẩm, hay một bản tin có nhiều mục.
- Ưu tiên xếp chồng (stacking). Khối “ảnh trái + chữ phải” trên desktop nên tự rớt thành “ảnh trên + chữ dưới” trên điện thoại. Trong trình soạn kéo–thả của Mailemdi, các khối nhiều cột đã được lập trình sẵn để tự xếp chồng trên màn hình nhỏ — khi bật xem trước mobile bạn sẽ thấy hai cột tự rơi xuống một, không phải viết CSS tay.
- Hai cột sản phẩm là giới hạn trên. Nếu thật sự cần lưới sản phẩm, tối đa hai cột; ba cột trở lên trên màn hẹp khiến ảnh bé như tem và chữ giá không đọc nổi. Tốt hơn là một cột, mỗi sản phẩm một khối rộng rãi.
- Thứ tự nguồn (source order) quan trọng. Khi cột rớt xuống, chúng xếp theo thứ tự trong mã nguồn. Hãy bảo đảm khi xếp chồng, thứ tự đọc vẫn hợp lý: tiêu đề trước, rồi mô tả, rồi nút — đừng để nút trôi lên trên phần giải thích.
Một mẹo tư duy hữu ích: trước khi mở trình soạn, hãy phác bố cục email trên một mảnh giấy hẹp bằng cỡ điện thoại. Nếu nội dung đã chảy mượt trong khung hẹp đó, nó gần như chắc chắn ổn trên desktop. Ngược lại thì không đúng.
3. Cỡ chữ & vùng chạm — thiết kế cho ngón tay, không cho con trỏ
Trên desktop, người ta nhấp bằng con trỏ chuột chính xác đến từng pixel. Trên điện thoại, họ chạm bằng đầu ngón tay — một vùng tròn rộng. Đây là khác biệt cốt lõi của mobile-first: mọi thứ có thể chạm phải đủ to và đủ cách xa nhau.
| Yếu tố | Mức an toàn cho di động | Vì sao |
|---|---|---|
| Cỡ chữ thân | 16px (tối thiểu 14px) | Dưới 14px, iOS có thể tự phóng to và làm vỡ bố cục; 16px đọc thoải mái khi cầm máy cách mắt. |
| Cỡ tiêu đề trong thân | 22–28px | Đủ nổi mà không tràn quá nhiều dòng trên màn hẹp. |
| Chiều cao vùng chạm (nút, link chính) | Tối thiểu 44px | Theo chuẩn cảm ứng của Apple — nhỏ hơn thì ngón tay hay bấm trượt. |
| Khoảng cách giữa các link/nút | Tối thiểu 8–12px | Tránh “chạm nhầm” vào link bên cạnh, nhất là cụm link chân thư. |
| Lề trong hai bên | 16–24px | Để chữ không dính sát mép màn hình, đỡ mỏi mắt khi đọc. |
| Giãn dòng | 1.4–1.6 | Khoảng thở giữa dòng giúp đọc trên màn nhỏ đỡ chật. |
Một lỗi rất hay gặp trên di động là cụm link chân thư bị dính nhau: “Hủy đăng ký · Cập nhật thông tin · Xem trên web” nằm sát trên một dòng. Trên desktop bấm trúng dễ; trên điện thoại, người muốn bấm “Hủy đăng ký” lại bấm trúng “Cập nhật” — vừa bực mình vừa làm tăng nguy cơ họ bấm nút “Báo cáo spam” cho nhanh. Hãy tách các link chân thư xuống dòng riêng hoặc thêm khoảng cách rõ ràng trên di động.
Bài test ngón cái
Cầm điện thoại một tay như người nhận thật. Bạn có cuộn hết email, đọc được mọi chữ và bấm trúng nút chính chỉ bằng ngón cái mà không phóng to, không cuộn ngang, không bấm nhầm không? Nếu phải zoom hay phải dùng tay kia để bấm chính xác, thiết kế chưa đạt chuẩn di động.
4. Ảnh trên di động — nhẹ, có chữ thay thế, không “email một tấm ảnh”
Trên di động, ảnh vừa quan trọng hơn (bắt mắt khi lướt nhanh) vừa rủi ro hơn (mạng yếu, nhiều app chặn ảnh mặc định). Tư duy mobile-first đặt ra vài ưu tiên rõ:
- Nội dung cốt lõi phải là chữ thật. Đừng thiết kế cả email thành một tấm ảnh cắt từ Canva. Khi app chặn ảnh hoặc mạng yếu, người nhận chỉ thấy một ô trống — và bộ lọc spam “đọc” được rất ít chữ nên dễ nghi ngờ hơn.
- Nén ảnh quyết liệt. Người dùng di động thường ở mạng 4G chập chờn hoặc tiết kiệm dữ liệu. Ảnh nặng vài MB tải chậm khiến email “trắng” lúc đầu, và càng dễ bị Gmail cắt (clip) khi tổng HTML vượt khoảng 102KB. Xuất ảnh đúng bề rộng cần dùng, đừng đính ảnh 4000px.
- Luôn có thẻ
altmô tả. Khi ảnh chưa tải, dòng alt giúp người nhận vẫn hiểu khối đó nói gì. Viết “Giảm 30% giày thể thao đến hết Chủ nhật”, đừng viết “Banner khuyến mãi”. - Đặt
widthcho ảnh. Để app giữ đúng chỗ trước khi ảnh tải xong, tránh bố cục nhảy giật khi ảnh về.
Hãy làm phép thử “tắt ảnh vẫn hiểu”: mở bản nháp trên điện thoại với chế độ chặn ảnh, rồi tự hỏi — người nhận có biết đây là email về cái gì và phải bấm vào đâu không? Nếu không, bạn đang phụ thuộc quá nhiều vào ảnh, một canh bạc rủi ro trên di động. Trước khi gửi, kiểm tra cân nặng tổng thể bằng công cụ Đo dung lượng email để chắc Gmail không cắt mất chân thư và link hủy đăng ký.
5. Tiêu đề & preheader ngắn — nơi mobile-first bắt đầu từ hộp thư
Mobile-first không bắt đầu khi email được mở; nó bắt đầu ngay ở danh sách hộp thư. Trên điện thoại, không gian hiển thị mỗi thư cực hẹp: chỉ vài chục ký tự đầu của tiêu đề, rồi một đoạn preheader (dòng xem trước) ngắn ngủn. Một tiêu đề dài đẹp đẽ trên desktop có thể bị cắt cụt giữa chừng trên điện thoại, làm mất luôn phần “chốt”.
- Dồn ý quan trọng lên đầu. Vì phần đuôi tiêu đề dễ bị cắt, hãy đặt lợi ích/từ khóa quan trọng nhất trong khoảng 30–40 ký tự đầu. “Giảm 30% hôm nay — …” tốt hơn “Nhân dịp đặc biệt chúng tôi xin gửi tới quý khách ưu đãi giảm 30%”.
- Tránh nhồi tên thương hiệu vào đầu tiêu đề. Người nhận đã thấy tên người gửi rồi; đừng lãng phí những ký tự đầu quý giá để lặp lại nó.
- Coi preheader là “dòng thứ hai” của tiêu đề. Nó bổ sung chứ không lặp lại tiêu đề. Nếu để trống, app sẽ tự lôi mấy chữ đầu trong thân email lên — thường là “Nếu không xem được email này…”, rất vô duyên trên màn hẹp.
- Cẩn thận với emoji. Một emoji có thể giúp nổi bật trong danh sách hộp thư dày đặc, nhưng nhồi nhiều dễ trông spam và đôi khi hiển thị khác nhau giữa các máy. Chỉ test mới biết với tệp của bạn.
Hãy chăm chút dòng preheader bằng công cụ Viết preheader, và soát rủi ro spam của tiêu đề bằng công cụ Soát từ khóa spam trước khi gửi. Muốn đào sâu kỹ thuật viết, đọc thêm cách viết tiêu đề email tỷ lệ mở cao và bài về preheader & CTA.
Bộ ba xuất hiện đầu tiên trên di động
Trong danh sách hộp thư trên điện thoại, người nhận quyết định mở hay lướt dựa trên đúng ba thứ: tên người gửi, tiêu đề (đã bị cắt ngắn) và preheader. Hãy thiết kế ba thứ này như một bộ ba phối hợp, không phải ba phần rời rạc — đó là “trang bìa” mobile-first của email.
6. Đưa thông điệp & CTA chính lên trước “nếp gấp”
Trên màn hình điện thoại, vùng nhìn thấy ngay khi mở (above the fold) rất nhỏ — chỉ vài dòng. Nếu vùng đó bị logo to, banner rộng và một đoạn chào hỏi dài chiếm hết, người nhận phải cuộn mới thấy được lý do nên đọc tiếp. Nhiều người sẽ không cuộn.
- Logo nhỏ, gọn. Đừng để logo chiếm nửa màn hình đầu tiên. Một dải thương hiệu mảnh là đủ.
- Thông điệp chính ngay lập tức. Tiêu đề trong thân và một câu lợi ích nên nằm trong khung nhìn đầu tiên, không cần cuộn.
- CTA chính đặt sớm và lặp lại. Đặt nút hành động chính ở phần trên, rồi lặp lại ở cuối nếu email dài — người cuộn tới đáy không nên phải vuốt ngược lên để tìm nút.
- Một hành động chính. Năm nút cạnh tranh nhau trên màn hẹp chỉ gây tê liệt lựa chọn. Một CTA nổi bật, các link phụ để dạng văn bản bên dưới.
Nút CTA phải là nút bulletproof — dựng bằng HTML/CSS với chữ thật, không phải một tấm ảnh — để khi ảnh bị chặn nút vẫn hiện. Các khối nút trong trình soạn của Mailemdi vốn đã là bulletproof; bạn chỉ chọn màu, bo góc, chữ và dán link. Tinh thần là một ô có nền màu, padding rộng để dễ chạm:
<a href="..." style="display:inline-block; background:#f97316; color:#fff; padding:14px 28px; border-radius:8px; text-decoration:none; font-weight:600;">Mua ngay</a>
7. Test thật trên thiết bị — bước không bao giờ được bỏ
Mobile-first chỉ có giá trị nếu bạn kiểm chứng trên điện thoại thật. Trình xem trước trong app rất hữu ích để bắt lỗi sớm, nhưng nó không thay được cảm giác cầm máy thật, ở mạng thật, với app mail thật của người nhận. Quy trình test tối thiểu cho di động:
- Xem trước mobile trong app. Trình soạn của Mailemdi cho xem nhanh bố cục desktop và mobile cạnh nhau, kèm mô phỏng cách Gmail, Outlook, Apple Mail hiển thị. Bắt sớm lỗi rõ ràng: chữ tràn, ảnh lệch, cột không xếp chồng.
- Gửi thử tới chính mình. Ít nhất một địa chỉ Gmail và một địa chỉ Outlook/Yahoo — các app phổ biến nhất với người nhận Việt Nam.
- Mở trên điện thoại thật. Một máy iPhone, một máy Android. Làm bài test ngón cái: cuộn, bấm nút, đọc chữ mà không phóng to.
- Tắt ảnh & bật dark mode. Mở lại với ảnh bị chặn để kiểm tra thẻ alt và nút bulletproof; bật chế độ tối để chắc logo/chữ không biến mất khi app đảo màu.
- Soát link & khả năng vào inbox. Kiểm mọi link đúng đích, không lỗi chính tả, và thư rơi vào Inbox chứ không phải tab Quảng cáo/Spam.
Trước khi bấm gửi, rà toàn bộ liên kết (nút, ảnh, link văn bản) bằng công cụ Soát link trong email — nó bắt link rỗng, sai địa chỉ hay thiếu link hủy đăng ký, tránh cảnh nút đẹp mà bấm vào không ra đâu. Muốn hiểu sâu hơn vì sao thư vào hay ngoài Inbox, đọc hướng dẫn Vào hộp thư đến.
Nền tảng gửi vững thì thiết kế đẹp mới tới được mắt người nhận
Một email mobile-first hoàn hảo vẫn vô nghĩa nếu nó rơi vào spam. Hãy bảo đảm domain đã xác thực SPF, DKIM, DMARC và (với domain mới) đã được làm nóng (warmup) dần dần. Mailemdi hướng dẫn thêm và kiểm tra các bản ghi này ngay trong cài đặt domain, và sẽ chặn gửi nếu domain chưa xác thực để bảo vệ uy tín gửi của bạn. Đọc quy trình đầy đủ trong SPF, DKIM, DMARC toàn tập và cách làm nóng domain/IP.
8. Quy trình dựng email mobile-first, từng bước
Gom tất cả lại thành một quy trình bạn lặp được cho mọi chiến dịch:
- Bắt đầu từ một mục tiêu. Viết một câu: “Email này muốn người nhận bấm Mua ngay.” Mục tiêu rõ thì việc cắt bớt mới dứt khoát.
- Phác bố cục trong khung hẹp. Hình dung màn hình điện thoại: logo nhỏ → thông điệp chính → CTA → (nội dung phụ) → CTA lặp lại → chân thư. Một cột, từ trên xuống.
- Viết tiêu đề & preheader cho màn hẹp. Dồn ý quan trọng vào 30–40 ký tự đầu; preheader bổ sung, không lặp lại.
- Dựng bằng khối đã tối ưu di động. Dùng các khối tự xếp chồng và nút bulletproof của Mailemdi; chữ thật, ảnh nén, mọi ảnh có alt và width.
- Kiểm cân nặng & rủi ro spam. Soát qua Đo dung lượng email và Soát từ khóa spam.
- Test trên thiết bị thật. iPhone + Android, tắt ảnh, bật dark mode, làm bài test ngón cái.
- Cải tiến bằng A/B test. Test tiêu đề, người gửi hay CTA trên một nhóm nhỏ, rồi gửi câu thắng cho phần còn lại — chi tiết trong A/B testing email.
9. Những sai lầm phá hỏng trải nghiệm di động
- Thiết kế desktop rồi mới “nghĩ tới” mobile. Đảo ngược tư duy: điện thoại là trải nghiệm chính.
- Chữ dưới 14px. iOS phóng to, bố cục vỡ, người nhận phải zoom.
- Nút/link quá nhỏ hoặc dính nhau. Ngón tay bấm trượt, nhất là cụm link chân thư.
- Email là một tấm ảnh. App chặn ảnh hoặc mạng yếu là người nhận thấy ô trống.
- Ba cột trở lên trên màn hẹp. Ảnh bé như tem, giá không đọc nổi.
- Above the fold lãng phí. Logo to và đoạn chào dài đẩy thông điệp chính xuống dưới nếp gấp.
- Tiêu đề bị cắt mất phần chốt. Ý quan trọng nằm ở đuôi, mất sạch trên màn hẹp.
- Chỉ test trong app, không mở máy thật. Bỏ lỡ lỗi chỉ xuất hiện trên thiết bị thật.
Đọc thêm
- Thiết kế email responsive đẹp trên mọi thiết bị — nền tảng kỹ thuật: kích thước an toàn, nút bulletproof, dark mode.
- Preheader & CTA — hai yếu tố quyết định trên màn hẹp, từ hộp thư tới nút bấm.
- Thư viện mẫu email — các mẫu đã tối ưu di động sẵn, chỉ việc thay nội dung và đổi màu.
- Tạo & theo dõi chiến dịch — dựng chiến dịch hoàn chỉnh và đọc báo cáo mở/click.
- Hướng dẫn Automation — email tự gửi theo hành vi khách, vẫn cần chuẩn mobile-first.
Dựng email mobile-first mà không cần biết code
Trình soạn kéo–thả của Mailemdi tạo email tự xếp chồng trên màn hẹp, nút bulletproof và mẫu tối ưu di động sẵn — kèm xem trước desktop/mobile, đo dung lượng, soát spam, A/B test và xác thực domain SPF/DKIM/DMARC ngay trong app. Tạo tài khoản và gửi chiến dịch đầu tiên chỉ trong vài phút.
Bắt đầu miễn phí với Mailemdi