Brand Story and Editorial Section Systems on Shopify

Definition

The reusable editorial vocabulary of a Shopify storefront, built as theme sections rather than in a page builder: image-with-text bands, split panels, scroll-driven story modules, tabbed timelines, value-proposition strips, marquees and tile grids, each carrying its own typography, art-direction and color settings so a merchandiser can compose a brand page from the theme editor and from data the store already holds.

The Evidence

• Evidence strength: 32 live, Deploi-attributed builds across 3 Shopify storefronts — the largest gated total of any capability in this section.
• Split by storefront: Nudestix 13, LUS Brands 10, Three Ships 9.
• Split by attribution: 28 Deploi-authored, 4 modifications of vendor theme code — disclosed as such on each build page.
• Evidence quality: 6 carry code plus client working records. 26 are documented from the code; no client-side record of the decision survives.
• Confidence: 6 strong, 26 moderate.
• Surfaces: landing and content pages first, then the homepage; a handful on product, collection and blog templates.
• Status: Live, verified 2026-09-07.
• Four of the 32 have published build pages.

Thirty-two is the biggest number on any hub here, and it's the one to read most carefully. Twenty-six of the 32 are documented from code alone, most are small sections on one or two templates, and only four have been written up. The count says these storefronts carry a lot of editorial furniture we built; it does not say each piece is deep. Where the depth is, the four pages below show it.

How It's Actually Built

Every one of the 32 is a Liquid section with a schema; that's the one primitive all of them share. What separates them from Dawn's stock image-with-text is what the schema is asked to hold and where the content comes from. Four patterns account for most of the work.

Settings as the type system. The rich-text rebuild on LUS Brands is the clearest case. A scoped {% style %} block loops section.blocks and, for each heading, text or button block, writes a rule keyed to the block's own id carrying --font-h2--size and its -md twin, weight, line-height, color and margin tokens. A static stylesheet consumes them, and the -md values take over inside its 750px media query, which is what turns one block's two values into a responsive rule without a second set of markup. That's 49 settings across the section and its three block types, and every one leaves Liquid as a custom property. The kids sub-brand's image-with-text section follows the same convention with a --kiwt-* token set, and the homepage journey grid emits per-block alignment and object-position rules the same way. On Nudestix the editorial split banner exposes its subtext type scale and five colors as settings and does the desktop-to-mobile artwork swap in CSS through two custom properties rather than in Liquid.

Ratios and media decided at render time. The brand-story split panel on LUS Brands switches its media half between an image, a hosted video and a YouTube frame from one media_type select, and computes the mobile aspect ratio in Liquid from the real asset's aspect_ratio, with 16:9 forced for YouTube because it can't be anything else, emitting it as --mobile-ratio-percent so the box is right before anything loads. Its sibling columns section uses the same ratio technique and clamps a custom heading measure against settings.page_width so a typed number can't break the grid.

Content that is data, not settings. The step system on LUS Brands reads a how_to_use metaobject list through a product metafield and renders it four ways — card grid, slider, numbered timeline, image-and-text split — from one {% capture %} that prints into the desktop tab and the mobile accordion alike, with a custom.how_to_design value on the product or variant choosing the layout. Nudestix's international page reads page.content rather than duplicating copy into a setting, so the regional team edits it where they already work. Three Ships' holiday blog module takes two specific articles by picker and resolves them through articles[], an editorial choice rather than the latest N.

Composition without a runtime. Nudestix's scroll story pins an image column and cross-fades between stacked images as text panels pass, driven by an IntersectionObserver rather than a scroll listener. Three Ships' tabbed timeline and its "look closer" section render every panel server-side and toggle visibility, so the whole story is in the document and no tab costs a fetch. The kids ingredients strip gives its slider track a pre-initialization rule that mirrors the configuration it will be replaced by, so the band holds its final layout before any script runs.

Underneath the LUS Brands sections sit two documented snippets, button-link.liquid and highlight-text.liquid. Each opens with a {% doc %} block carrying typed @param lines, ships its own {% stylesheet %}, and takes its styling from custom properties the calling section sets. The [[word]] syntax highlight-text.liquid parses gives a merchandiser one accent color inside a plain text setting, and seven other sections render it. That convention is the difference between ten sections and a system.

The Buy-vs-Build Position

The corpus's own verdict, in substance: built or extended from a purchased theme in every case, and the economic argument for owning the sections is placement — a section authored once is placed by a merchandiser across many templates without a developer in the loop.

We'd state that argument on our own work rather than on the note's example, which is a vendor theme's module and isn't counted here. The marquee on Three Ships sits on 13 templates; the value-proposition strip on Nudestix on six; the rich-text system on LUS Brands carries three page types with three type scales from one file. None of the 32 is a page-builder template. Each is a section in version control whose content sits in the theme editor or in Shopify's own data model. A builder buys a free-form canvas with its own runtime in front of the page and the content in the vendor's store. A section library buys a vocabulary the storefront already speaks. Which one a team needs is argued in Shopify theme sections: buy a premium theme or build a section library?

The Builds

Four of the 32 have published build pages: three on LUS Brands, one on Nudestix. Three Ships contributes 9 of the 32 and none of them has a page yet.

LUS Brands — Dawn 15.4.1

• Four selectable How-To step layouts from a single metaobject step list — one how_to_use metaobject list rendered four ways from a single capture, into a desktop tab and a mobile accordion, with the layout chosen per product. High, product page.
• Brand story split panel: one section that renders image, hosted video or YouTube with separate desktop and mobile assets — a media_type select, a mobile ratio computed from the real asset, and the type scale as settings. Medium, About page.
• Rich-text section rebuilt as a per-block typography and highlight system — every block's type, spacing and color emitted as custom properties, plus the [[word]] highlight snippet. Medium, static and support pages. A rewrite on a Dawn base, disclosed on its page.

Nudestix — Dawn 6.0.2

• Editorial split banner with typographic control and merchandiser-authored offer details — layout mode, desktop and mobile artwork, subtext type scale and an offer-details panel as settings, with the image swap done in CSS. Medium, homepage. Documented from the code.

Three Ships — Palo Alto 5.8.0 by Presidio Creative

Nine builds count and none is written up: a tabbed story section, a tabbed timeline, value-proposition rows, a marquee, an information-card disclosure, a sustainability slider, an icon row and a two-article blog picker. They're small, and the vendor theme around them carries the storefront's main editorial vocabulary.

The other 28 are documented in the corpus. Some will get pages. Many are one-template sections that will only ever be described here, and we'd rather say that than promise 28 pages.

What This Rests On

• Liquid section schema and settings — all 32; the schema is the product.
• Theme blocks — the per-block rule a style loop writes, and the tab a timeline renders twice.
• CSS custom properties — --font-h2--size, --mobile-ratio-percent, --kiwt-h-size: the carrier for every merchandiser decision that reaches the stylesheet.
• Metaobjects — the how_to_use step list, the one place in this capability where content is a data model.
• Metafields — custom.how_to_design on a product or variant, choosing which rendering a step list gets.
• Custom elements — <kids-ingredients-strip>, the one section here that owns its lifecycle in an element.
• Swiper — the slider library three of the sections wrap; YouTube — the one external media source the split panel embeds.

How the 32 were drawn. The capability was indexed on editorial furniture broadly, not on brand story narrowly: FAQ accordions, a community programme listing, an international stockist page, value-proposition strips, press and founder sliders. Not every one of them tells a brand's story. We count them because the graph does, and we'd rather say so than let 32 imply 32 story modules. The four published pages are the narrower thing the name promises: modules whose settings are a type system and whose content is the store's own data.

What Varies by Storefront

LUS Brands runs Dawn 15.4.1, and its 10 builds are the most system-like of the three: an About page rebuilt as a pair of sections, a rich-text rewrite, a kids sub-brand with its own tokenized image-with-text section and ingredient strip, and the shared snippets those sections call. The convention is legible from the code, and the client working records in this capability are mostly here, around the About page and the restyle of static pages.

Nudestix runs Dawn 6.0.2 with a Tailwind layer over it, and contributes the most builds, 13, mostly one section per brand page: a scroll story for one product line, a synced text-and-image slider, a founder slider, a press slider, a community listing, an international page. One build extends Dawn's own image-banner and image-with-text sections with new block types beside the originals rather than in their place, so content already saved in template files keeps rendering. It's the fastest way to give a brand page its own furniture and the slowest to consolidate afterward.

Three Ships runs Palo Alto 5.8.0 by Presidio Creative, a paid premium theme that ships its own storytelling sections, and those vendor sections carry most of the storefront's editorial pages. They aren't counted here and aren't claimed. Our nine are additions at the edges: tabbed stories and a timeline that render every panel server-side, a marquee, an icon row, a two-article picker. Small, deliberately, because the theme already had the vocabulary.

Where This Gets Hard

Consistency moves to the merchandiser. Two of the four published pages say it in their own words: a type scale set per instance means two banners on one page can carry two subtext sizes and nothing stops it; the tokens make any scale possible, and the design system lives in the merchandiser's habits rather than the code. A builder's templates enforce. A settings panel offers. For a team without a style guide that's a real cost.

Editor surface grows with expressiveness. A rich-text block runs eleven to fifteen settings. The split panel and its sibling columns section expose the type scale twice, for desktop and for mobile. Every knob is a decision a merchandiser makes on every instance. The step system's answer — content in a metaobject, layout as a single select — is the better shape wherever content repeats across a range, and the more expensive one to build.

One section per page is fast, and then it isn't. Most of the 32 live on one or two templates. A brand page that gets its own section ships quickly and never has to fit a shared schema; a couple of years on, the theme carries a dozen sections with overlapping settings and nobody is sure which one the About page uses. The LUS Brands convention — shared snippets, tokens, a documented [[word]] syntax — exists because a vocabulary without a convention becomes a pile.

Per-instance styles scale with the page. Emitting tokens per block keeps one stylesheet for every instance, and the rich-text page states the bill: each block adds a dozen-odd declarations to the inline style block, so a long page ships a long style block. It's a reason to use a rich-text section for prose and not for a whole landing page.

Where we'd say don't build. If campaign tempo is low and a premium theme already ships the storytelling sections you need, use them — that's the Three Ships case, and our nine builds there sit deliberately at the edges. If what marketing wants is a free-form canvas with drag-and-drop layout, a section library isn't that; a page builder is the honest answer, with its runtime and its exit cost understood up front. And if content repeats across products — steps, ingredients, results — model it as metaobjects before building the section, or you'll build the section four times.

Related Capabilities

• Campaign landing pages without a page builder — the pages these sections get composed into.
• Art-directed hero and banner system — the banner half of the same vocabulary, where desktop and mobile artwork differ.
• Design system and reusable component library — the snippets and tokens the editorial sections call.
• Video and shoppable media modules — where the split panel's video half is argued.
• Editorial blog and content hub — long-form content on Shopify's blog rather than in sections.

Answers to Help You Make Smart Decisions

Do I need a page builder to give marketing control of brand pages on Shopify?

Not for the pages in this corpus. A theme section with a schema gives a merchandiser text, images, colors, type and block order in the theme editor, and metaobjects hold the content that repeats. What a builder adds is a free-form canvas and a visual editor, with its own runtime in front of the page and the content in the vendor's store rather than yours. If the canvas is the requirement, buy it knowingly.

How do you give a merchandiser typography control without breaking the design?

By exposing type as tokens rather than as markup. Each block's size, weight, line-height and color leave Liquid as CSS custom properties keyed to the block id, and one static stylesheet reads them, so the section stays a single file across any number of instances. What that doesn't do is enforce consistency: the theme offers every scale, and a style guide has to do the rest.

Should repeated content like how-to steps live in section settings or in metaobjects?

In metaobjects, when it repeats across products. A step list held as a metaobject is data with no presentation, so one section can render it four ways from a single select, and the same list can print into a desktop tab and a mobile accordion. Section settings are right for content that belongs to one page; they're the wrong place for content that belongs to a product range.

Ready for Brand Pages Your Team Can Rewrite Without a Ticket?

Your story changes every season. The section that tells it shouldn't need a developer each time. Contact us today and we'll read your theme and tell you which pages want sections, which want metaobjects, and which honestly want a builder.