Design patterns · not a catalog
Shopify section design patterns
Before you invent another one-off section.liquid, choose a reusable pattern. This guide centers on {% schema %} presets—the contract that makes a pattern discoverable in Add section—and the trade-offs that decide whether merchants can keep using it for years.
Design patterns guide · Updated 2026-08-03
Design intent: patterns, not downloads
A “template” in marketing copy usually means a zip of HTML. In Online Store 2.0, a reusable section pattern means a file merchants can add from the editor, configure without a deploy, and recognize by a human preset name.
The primary Shopify object on this page is the presets array inside {% schema %}. Without presets, a pattern is a private developer file. With the wrong preset shape, merchants pick the wrong starter and fight the schema for the rest of the campaign.
Design pattern
Pattern A — Flat settings band
Design intent. One instance, one story: a campaign hero, announcement strip, or feature callout where content does not repeat as rows.
When to use
- Headlines, CTAs, and media are singular for this band
- Merchants change copy and art weekly but never “add another row”
- You want the simplest editor UI and the fewest block edge cases
When not to use
- FAQ lists, logo strips, slides, or cards that must grow without code
- Content that different stakeholders reorder independently
Implementation trade-offs. Flat patterns are easy to teach and hard to stretch. When marketing asks for a third feature card, teams either hardcode it (breaking the pattern) or migrate to blocks mid-season (breaking saved settings).
Merchant editing. Merchants open the section and edit labeled settings. The preset name should match what they call the band—“Homepage campaign hero,” not hero_flat_v2.
Scalability. Scales across many storefronts as a shared module if defaults stay brand-neutral. Does not scale inside one section when row count grows.
Maintenance. Keep setting ids stable. Renaming heading to title after merchants save copy creates empty fields and support tickets.
Preset-centered schema sketch
{% schema %}
{
"name": "Campaign hero",
"settings": [
{ "type": "text", "id": "heading", "label": "Heading", "default": "Season launch" },
{ "type": "url", "id": "cta_link", "label": "CTA link" }
],
"presets": [
{ "name": "Campaign hero" }
]
}
{% endschema %}Production mistakes
- Shipping with zero presets so the pattern never appears in Add section
- Using Flat when the brief already lists three equal cards
- Preset labels that only developers understand
Design pattern
Pattern B — Block-repeatable module
Design intent. Rows merchants add, remove, and reorder: FAQs, slides, logo lists, feature grids.
When to use
- Content volume changes after launch
- Order matters and non-developers own that order
- You can define one block type (or a small set) with clear labels
When not to use
- A single hero with one image and one CTA
- Highly asymmetric rows that need totally different settings each time
Implementation trade-offs. Blocks unlock merchant growth and introduce max_blocks, empty states, and block-type discipline. Presets should seed two example blocks so the editor is not an empty shell on first add.
Merchant editing. Merchants use Add block inside the section. The section preset still decides whether the pattern shows up at all; block presets inside the section preset decide the first useful state.
Scalability. Best pattern for agency libraries reused across clients—if block type names stay stable and help_text explains merchant intent.
Maintenance. Never rename block types after merchants configure rows. Treat type strings as database columns.
Preset-centered schema sketch
{% schema %}
{
"name": "FAQ list",
"blocks": [
{
"type": "question",
"name": "Question",
"settings": [
{ "type": "text", "id": "question", "label": "Question" },
{ "type": "richtext", "id": "answer", "label": "Answer" }
]
}
],
"presets": [
{
"name": "FAQ list",
"blocks": [
{ "type": "question" },
{ "type": "question" }
]
}
]
}
{% endschema %}Production mistakes
- Preset with zero seeded blocks—merchants see a blank FAQ and think it is broken
- No max_blocks on heavy media rows (sliders) until the page collapses
- Cloning FAQ block types onto PDP disclosures without a separate pattern decision
Design pattern
Pattern C — One section, multiple presets
Design intent. Same Liquid and schema; different starting configurations for different merchant jobs (compact vs full-bleed, two-column vs stacked).
When to use
- Layout variants share settings ids and CSS
- You want one file to maintain, several Add section choices
- Brand teams pick by outcome (“Editorial feature” vs “Compact feature”)
When not to use
- Variants that need incompatible settings or different block types
- When two presets would confuse merchants into thinking they are different apps
Implementation trade-offs. Multiple presets reduce file sprawl but increase naming discipline. Bad names create duplicate sections on the homepage because merchants add both “Feature” presets.
Merchant editing. The merchant task starts here: choose the correct reusable pattern (preset) before asking for a custom section. Clear preset names are the UI for that choice.
Scalability. Excellent for design systems: one section.liquid, three presets, many templates. Fragile if presets diverge until the Liquid is full of special cases.
Maintenance. Document which preset is the default for new stores. Retire presets by leaving them listed only if existing stores still depend on the name.
Preset-centered schema sketch
{% schema %}
{
"name": "Feature band",
"settings": [
{ "type": "select", "id": "layout", "label": "Layout",
"options": [
{ "value": "split", "label": "Split" },
{ "value": "stack", "label": "Stack" }
],
"default": "split"
},
{ "type": "text", "id": "heading", "label": "Heading" }
],
"presets": [
{ "name": "Feature band — split", "settings": { "layout": "split" } },
{ "name": "Feature band — stack", "settings": { "layout": "stack" } }
]
}
{% endschema %}Production mistakes
- Two presets that look identical after add—merchants cannot tell them apart
- Encoding layout only in CSS classes outside settings so presets cannot switch mode
- Creating a second section file instead of a second preset for a trivial variant
Design pattern
Pattern D — Compose sections; do not mega-section
Design intent. Reusable patterns stay small. Homepages compose several preset-backed sections instead of one “kitchen sink” file with thirty settings.
When to use
- Landing pages with distinct bands owned by different teams
- You already have flat and block patterns that can sit adjacent
- JSON templates can order sections without new Liquid
When not to use
- Tightly coupled layouts that share one background treatment and one animation timeline
- Checkout or app-embed UI that is not a section pattern at all
Implementation trade-offs. Composition keeps presets honest and files reviewable. It requires discipline in JSON templates (Dawn guide) and acceptance that spacing between sections is a theme concern.
Merchant editing. Merchants add each band via its preset, then reorder on the template. Choosing patterns up front prevents “one custom mega section” tickets later.
Scalability. This is how agencies ship many stores: a small library of preset patterns, composed per brand—not a catalog of one-off HTML zips.
Maintenance. Resist merging two patterns into one file because a single page “looked connected.” Connection belongs in design tokens and spacing, not schema bloat.
Preset-centered schema sketch
// templates/index.json (concept)
{
"sections": {
"hero": { "type": "campaign-hero", "settings": {} },
"faq": { "type": "faq-list", "settings": {} }
},
"order": ["hero", "faq"]
}Production mistakes
- Building homepage_v7.liquid with every band hardcoded and one vague preset
- Skipping presets on child patterns because “we only add them via JSON”
- Teaching merchants to duplicate mega-sections instead of composing small ones
Design pattern
Pattern E — When not to force a reusable pattern
Design intent. Some work is genuinely one-off: metafield-driven PDP logic, app blocks, or experimental layouts that will change before the next sprint.
When to use
- Requirements are unstable and merchants will not own the editor yet
- Shopify objects involved are product/collection logic—not a marketing band
- Legal or brand review blocks schema exposure for now
When not to use
- “Temporary” hardcoded heroes that stay for eighteen months
- Skipping presets on a section you already know merchants must add themselves
Implementation trade-offs. Skipping the reusable pattern saves a day and costs a rewrite. The merchant task—choosing a pattern before building custom—exists to catch that trade-off in planning, not in production fire drills.
Merchant editing. If merchants cannot add or configure the band, do not advertise it as a reusable section pattern. Keep it internal until presets and labels are ready.
Scalability. One-offs do not scale across clients. Promote them to Pattern A–D only when the brief repeats twice with the same settings shape.
Maintenance. Track one-offs in the repo with a comment: why no preset yet, and the date to revisit.
Preset-centered schema sketch
// Intentionally no merchant preset yet
{% schema %}
{
"name": "Internal PDP experiment",
"settings": [],
"enabled_on": { "templates": ["product"] }
}
{% endschema %}Production mistakes
- Calling a hardcoded slice a “template” in the theme zip for clients
- Adding a preset to an unfinished experiment so it pollutes Add section
- Forcing FAQ or hero patterns onto problems that need metafields or apps
How to choose before you build
- Name the merchant job. What will someone change without a developer—copy, rows, layout variant, or nothing yet?
- Pick Pattern A, B, or C. Flat, blocks, or multi-preset. If none fit cleanly, compose (D) or delay reuse (E).
- Design the preset first. Write the preset name and seeded defaults before polishing CSS. If the preset is unclear, the pattern is unclear.
- Only then write Liquid. Implement settings and blocks to match the preset contract. Do not invent schema after the markup hardens.
Related production guides
Shopify learning examples
Before/after lessons on section.id scoping and safe bindings.
Open guide →Ship sections on Dawn
Register chosen patterns on the correct JSON templates.
Open guide →Maintainable FAQ sections
Deep dive when Pattern B is a store-wide Q&A module.
Open guide →Featured production guides
Curriculum hub for rewritten implementation guides.
Open guide →Editorial review
Reviewed by the HTML to Liquid Converter team
Content is reviewed by the HTML to Liquid Converter Shopify development team before publication. Technical accuracy is validated against current Shopify Online Store 2.0 conventions and active client theme work.
Questions or corrections? Contact us.
Supporting utility
Practice after you choose a pattern
Once you can name Pattern A–E and sketch the preset merchants will see, the converter can help draft markup. It does not choose the pattern for you.