Updated · 8 min read
Mobile email design: 65% of opens are on a phone — design for that
Picture how your last email actually got read. Held in one hand, on a 5–6 inch screen, in a kitchen at 7am or on a bus or in a queue at the post office. That is the room you are designing for. The mobile-first argument was won five years ago, and yet a walk through any shipped program turns up 600-pixel two-column layouts, 14-point text, and tap targets the size of a peanut. All of it works on desktop. None of it works on the 65% of opens that happen on a phone. Responsive tables were a 2014 conversation. The real question now is which device you pretend the email is designed for while you're designing it.
By Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
Where your email actually gets opened — and why it matters
Mobile email opens crossed 50% in 2016 and have been the majority ever since. Today the rough split looks like this: 60–70% mobile for consumer programs, 40–55% mobile for B2B (where people read on laptops at desks), 5–8% tablet, and 25–40% desktop depending on audience. Your audience isn't special unless you have data saying otherwise — and most teams who think theirs is special haven't actually checked.
So picture the modal user — the most common reader of any given send. Phone in one hand, scrolling with a thumb, reading for 5–15 seconds on a 380–430 pixel wide screen at about half brightness, often while doing something else. That's the environment. Design for it properly or watch the metrics drift quietly downward over the next two quarters.
An email that's "fine" on mobile gets deleted. An email that's genuinely designed for mobile gets read. The difference is whether you picked the constraints before or after the desktop version was signed off.
Six rules that decide whether the phone read works
These are the constraints worth fighting for. Each one fails in a specific, predictable way when you ignore it — so the rule and the failure mode are paired.
Rule 1: Single column below 600px. A multi-column layout — two or more side-by-side blocks of content — collapses into a cramped vertical stack on mobile, with awkward white space and orphaned images. Design single-column from the start and let desktop users see a slightly over-spaced version. Build the other way around and you always lose the mobile read.
Rule 2: 16px minimum body text. 14-point text looks correct on a desktop monitor and is genuinely straining on a phone. There's also a quiet gotcha: iOS Safari (the browser engine behind Mail on iPhone) automatically bumps any text under 16px back up to 16px, to stop forms from zooming when you tap a field. Your 14px isn't saving space; the client is silently undoing your choice. Start at 16px and skip the argument.
Rule 3: 44×44 pixel minimum tap targets. A tap target is the clickable area around a button or link — finger-sized rather than cursor-sized. Apple's Human Interface Guidelines specify 44×44 pixels as the minimum. Google's Material Design (Android's equivalent) agrees. Anything smaller in either dimension produces misclicks, accidental taps on neighbouring links, and lower conversion. Applies to buttons, text links, and social icons equally.
Rule 4: CTA above the fold on a 667px viewport. "Above the fold" — newspaper term, now meaning "visible without scrolling." A 667-pixel viewport is roughly an iPhone in portrait. The primary CTA — the one click you most want — needs to be visible before the user scrolls, which in practice means within the first 400–500 vertical pixels of email content.
Rule 5: Hero images under 600px tall. A hero — the big banner image at the top — that fills the entire screen on mobile means the user scrolls before they see any text. Keep heroes short, or overlay the text directly on them so the message arrives with the image.
Rule 6: One primary CTA per email. Two CTAs is a desktop pattern, where they sit side-by-side and the user picks. On mobile they collapse into stacked full-width buttons, and the user taps whichever is closer to their thumb — not whichever you wanted them to tap. Pick the primary action. Secondary goes as a small text link below.
Subject and preheader — 80 characters of inbox, no more
Before anyone opens anything, two pieces of text decide whether the email gets a tap or a swipe-to-delete: the subject line and the preheader (the preview text that shows under or next to the subject in the inbox list). On mobile inboxes — Gmail app, iOS Mail, Outlook mobile — you typically get about 40 characters of subject and 40 of preheader before truncation. That's 80 characters total to make the case. Less than any desktop client gives you.
The discipline: design for the first 40 characters of each to carry the full message on their own. Desktop users see the longer versions as a bonus; mobile users need the truncated version to work as a complete thought. Write the short one first and let the long one be the expansion, never the other way around.
The subject line anatomy guide and the preheader guide both cover the 40-character mobile constraint in detail.
Why desktop-first design quietly breaks on a phone
The most common failure in shipped email programs is a workflow choice rather than a bug. Designer opens Figma at 1440px, builds something that looks good on the canvas, ships it, and trusts the responsive HTML to do the rest. The result usually breaks in three predictable ways.
,
The opposite failure — designing only for mobile and ignoring desktop entirely — is genuinely rarer and far less damaging. Mobile constraints force simpler, shorter emails, which usually serve desktop users equally well. Over-designing for desktop is the common mistake, not under-designing for it.
Testing on a real phone, not just a screenshot
Litmus and Email on Acid (the two main rendering-preview services — they show you screenshots of your email across dozens of inbox clients) are useful, but they show you the picture, not the experience. Nothing replaces opening the email on your own phone before pressing send. Specific things worth checking on the actual device:
• Can you read the subject and preheader at natural viewing distance — phone in your lap, not held up to your face?
• Is the primary CTA tappable without scrolling, and tappable without zooming first?
• Does body text flow naturally, or do you instinctively pinch to zoom in?
• Do images load at reasonable speed on mobile data, not just on home wifi?
• Is the unsubscribe link reachable without a wrestle? A difficult mobile unsubscribe is a major source of spam complaints — users who can't find the link mark the email as spam instead.
The unsubscribe guide covers the mobile flow specifically.
One reason mobile-first is still an argument in 2026: most design tools (Figma, Sketch) default to desktop canvases of 1440px or wider, so the path of least resistance is desktop-first. Mobile-first is a workflow discipline, not a technology one. It means starting in a 375-pixel frame and accepting that the desktop version is the adaptation, not the source.
On canvas width: design for 360–430px as the primary target. 375px covers iPhone SE and mini. 360px covers smaller Android handsets. Anything narrower is a vanishingly small share of the audience and not worth optimising for.
For images, design at 2× the target display size for retina sharpness (Apple's term for high-density screens, where one design pixel maps to two physical pixels) — a 600px wide hero ships as a 1200px file. Keep total email weight under 150KB for fast loading on mobile data; compress aggressively. WebP where supported, PNG or JPEG fallback otherwise. Dark mode: if you have the engineering budget, Apple Mail honours prefers-color-scheme (the CSS rule that lets a single email serve both light and dark variants) and dedicated dark variants matter. If you don't, use defensive design — off-white backgrounds, near-black text — so the email is at least acceptable in any render mode.
On AMP for Email (Google's interactive-email format that lets you embed live content like polls or live inventory): supported by Gmail and Yahoo, niche uptake in 2026. Worth the engineering cost only if you're sending a lot of dynamic content where real-time data — inventory, pricing, flight status — genuinely changes between send and open. For everyone else, static HTML is still fine.
treats a real-device mobile check as a default step in template QA. The Litmus preview is the screen; the phone check is the experience. Different things, and only the second one tells you what the user actually feels.
Read to the end
Scroll to the bottom of the guide — we'll tick it on your reading path automatically.
This guide is backed by an Orbit skill
Related guides
Browse allEmail dark mode: the four render modes and how to not break any of them
Dark mode in email is four different render behaviours across major clients, each with its own logic. Design without knowing which mode you're hitting and roughly half your audience sees something you never approved. Here's what each client does and the defensive rules that survive all of them.
Email accessibility: the seven rules that make your emails readable by everyone
Roughly fifteen percent of your audience opens your email with a screen reader, on a cracked phone in direct sunlight, or with images blocked at the corporate gateway. Most programs accidentally design around them. Seven rules — most of them cheap, all of them learnable in an afternoon — close the gap.
Subject line anatomy: the four parts every line that performs shares
Most subject-line advice is decoration tips — emoji, length, numbers. The lines that actually get opened share a structural pattern. Four parts in a specific order, the three distortions that ruin it, and the four rules that keep A/B tests honest.
Transactional emails: the highest-engagement messages you ignore
Order confirmations, password resets, receipts, shipping updates. Transactional emails post open rates two to three times higher than marketing sends — and most lifecycle teams have never touched them. Effort is going to the wrong place.
Personalisation that doesn't feel creepy
There's a line between personalisation that earns trust and personalisation that breaks it. It's not where most people think it is — it's about how you signal what you know, not what you know. Here's the line, how programs cross it without noticing, and the patterns that keep you on the right side.
Preheader text: the second subject line most programs ignore
The preheader is the snippet shown next to the subject line in the inbox preview. Treat it like a second subject line and you double your hook. Treat it like an afterthought and it says 'View this email in your browser'. Here's how to write preheaders that actually earn the open.
Found this useful? Share it with your team.
Use this in Claude
Run this methodology inside your Claude sessions.
Orbit turns every guide on this site into an executable Claude skill — 63 lifecycle methodologies, 91 MCP tools, native Braze integration. Free for everyone.