Strategy
Part of A field guide to email design that survives every inbox
7 answers on email design case studies, in order
Email design case studies examine GOV.UK Notify, a Home Office pattern, Peacock, and Panera through evidence, mechanisms, limits, and transfer questions.
What to take away
- Public-service design guidance and vendor customer stories carry different authority, context, and evidence limits.
- A credible case record separates source facts, interpretation, local inference, limitation, and the bounded test.
Email design case studies should disclose what kind of evidence they provide. The government examples below are public system patterns, while the brand examples are vendor-published customer stories. They are not equivalent audits, and reported brand outcomes do not isolate visual design from data, offers, automation, product, or other channels.
Seven answers, in order:
- GOV.UK Notifyconstrain formatting to headings, subheadings, lists, numbered steps, horizontal separation, and limited inset text; avoid decorative formatting.
- Home Officedesign around reason, outcome, next step, support, semantic headings, left alignment, lists, meaningful links, alt text, and plain-text alternatives.
- Peacockmake personalization visual with the viewer's own data, then one link to watch next, with a fallback for accounts with no history.
- Panera Breadgovern modular content, audience rules, offer states, and fallbacks as a system.
- Mailchimpkeep subject and preheader distinct; typical preheader range is 40 to 100 characters, and avoid duplicate wording.
- Litmustest dark mode, image blocking, and client rendering; typical email width is 600 pixels, and typical minimum body text is 16 pixels.
- Salesforce Marketing Clouduse AMP for Email only where the client supports it, and always provide an HTML fallback.
GOV.UK Notify: constrain formatting to protect reading
GOV.UK Notify's formatting guidance documents the formatting available in its templates and the service's supported conventions. The constraint belongs to that product and public-service context, but it illustrates how a smaller design vocabulary can protect consistency, content order, and operational review.
Notify supports headings, subheadings, lists, numbered steps, horizontal separation, and limited inset text, while restricting decorative formatting that can make content harder to read. The lesson is that productive constraints can improve consistency and reduce fragile choices. Teams should still test their own content and acknowledge Notify's published accessibility limitations.
Annotated description: the template toolbar offers headings, subheadings, bullets, numbered steps, a horizontal rule, and inset text. Decorative controls are absent, so the outline carries the design.
Source: GOV.UK Notify formatting guidance page on the Notify service site. Record the date the page states, or your access date.
Home Office: design around outcome and next step
The Home Office Design System's email pattern describes planning email around why it is sent, the outcome, user needs, subject, content, action, and testing in that service context. That pattern is published guidance for one service, so it documents intent rather than measured results.
The Home Office pattern emphasizes immediate reason, completed actions, next steps, support, semantic headings, left alignment, lists, meaningful links, alt text, plain-text alternatives, and assistive-technology testing. The lesson is to turn service email into a task system rather than a branded poster.
Annotated description: a left-aligned email with one reason line, a list of completed actions, one next step, and a support contact at the end.
Source: Home Office Design System email pattern page. Record the date the page states, or your access date.
Peacock: make personalization visual and recognizable
A Braze customer story covers Peacock's year-in-review email, which showed personalized viewing behavior and connected it to future content. The design lesson is to build hierarchy around customer recognition, not decoration.
Data accuracy, privacy expectation, missing-history fallbacks, image blocking, and text alternatives need independent validation. Peacock's year-in-review message is one of the email design examples that shows how recognition drives hierarchy.
Annotated description: a year-in-review block built on the viewer's own data, then one link to what to watch next, with a marked fallback for accounts with no history.
Source: Braze customer story on Peacock's year-in-review email. Record the date the page states, or your access date.
Panera Bread: use modular variation during change
Braze reports that Panera used many tailored content combinations across email and other channels during a major menu transformation. The lesson is to govern modular content, audience rules, offer states, and fallbacks as a system. Published retention and conversion outcomes cover a broader cross-channel program, so design causality should remain modest.
Annotated description: the reported change moves from one menu message to tailored module combinations, with audience rules and offer states set per variant.
Source: Braze customer story on Panera's menu transformation. Record the date the page states, or your access date.
How to document a credible design case
- Message and audiencetask, audience, client and device context.
- Structure and markupsemantic outline and visual hierarchy.
- Content and assetslive text, images, alt text, links, and the action asked for.
- Variationpersonalization, localization, template, plain-text version, and destinations.
- Testingclient coverage, link checks, and assistive-technology tests.
- Outcomes and limitsexposure, task outcomes, guardrails, incidents, cost, and limitations.
Include screenshots only as illustrations, not proof.
The transferable pattern is resilience: constrain the system enough to keep reading and action clear, then use data and modules only where they add verified value. Validate every adaptation with the organization's own recipients, message types, content, clients, and failure states.
Case-study transfer record
| Layer | Record | Do not merge |
|---|---|---|
| Source | Publisher and page date | Independent validation |
| Context | Audience, task, system | Local conditions |
| Mechanism | Constraint or structure | Reported outcome |
| Transfer | Bounded local test | Forecast |
Worked example, filled in:
| Layer | Record | Do not merge |
|---|---|---|
| Source | Home Office email pattern, page date recorded | Guidance, not an audit of your mail |
| Context | Service email about an application; outcome is a completed step | Your audience and rules differ |
| Mechanism | Reason line, completed actions, one next step, support contact | Intent, not a measured result |
| Transfer | Renewal reminder test; measure completion and support contacts | No forecast before the test runs |
Audit the published evidence
The FTC advertising substantiation policy requires a reasonable basis before objective advertising claims are disseminated. That rule means the advertiser must hold the evidence before the claim runs, and the evidence must match what the claim states or implies.
The FTC guidance for marketers using reviews warns about fake feedback, selective requests, conditioned incentives, hidden relationships, and paid rankings. Apply those U.S. integrity checks when email design case studies content names providers. Teams reviewing vendor claims can compare them against the email automation case studies record before citing any result.
Common questions
Are all four examples independent studies?
No. GOV.UK Notify and Home Office are public-service guidance; Peacock and Panera are vendor-published customer stories. Each has different evidence limits.
What can a team safely transfer?
Transfer a documented design mechanism only after verifying local audience, task, authority, content, data, brand, accessibility, technology, operations, and risk.
How should results be documented?
Record the publisher, date, population, intervention, comparison, metric definition, denominator, maturity, limitations, conflicts, and what remains inference.
