Design system development

This section is for design system authors: designers, email developers, and anyone building the system that marketers use in the Campaign Editor.

In Better Email, a strong design system does more than look good. It gives marketers the right amount of flexibility, keeps the brand consistent, and makes common workflows fast.

What you will find here

• Design System Editor for the current authoring workflow.
• Design systems as code for keeping the design system in your own repository and syncing it with the Better CLI.
• Render context for the context variable available in Liquid during render.
• Rendering pipeline for what runs when, and which variables exist on each Liquid surface.
• Modules for reusable content building blocks.
• Settings for the groups and inputs that shape the editing experience.
• Repeatable settings for lists like products, articles, links, or FAQs.
• Feeds in settings for feed-backed content.
• Input types for field-level behavior and constraints.
• Betty AI for configuring how Betty uses your design system.

Recommended reading order

If you are new to Better Email design system building, this order works well:

1. Creating your first design system
2. Design System Editor
3. Modules
4. Settings
5. Validations
6. Design system architecture guide

Preview-aware rendering with context.isPreview

Design systems can access context.isPreview during render. This is useful when you want the preview experience to behave differently from the final exported output.

A common example is ESP-specific code that is required in export, but makes the in-product preview hard to read or visually noisy.

For example, you might want:

• clean placeholder or fallback content in preview
• raw ESP code such as AMPscript in the final exported email

That pattern can be handled directly in Liquid:

{% if context.isPreview %}
  <p>Preview text for the editor</p>
{% else %}
  %%[
    /* AMPscript or other ESP-specific export code */
  ]%%
{% endif %}

Use this when the export logic is technically necessary, but not useful to show in preview.

As a rule of thumb:

• use context.isPreview to improve clarity in preview
• keep the preview branch visually representative of the final email where possible
• use the export branch for ESP-specific logic that should only appear in the delivered output

Older design systems use meta.isPreview, which still works — new design systems should use context.isPreview. See the render context for everything else available under context.

The goal

The best Better Email design systems are easy to maintain and easy to use. If a marketer can build a polished campaign without touching HTML, the design system is doing its job.