Academy

Zigzag Sections — Format, Rules and Examples

Use zigzag sections to explain parallel features with alternating image and text, improve scanning, preserve extraction, and avoid needlessly long pages.

16 min read

Zigzag sections present a sequence of parallel features as repeated image-and-text pairs, alternating the visual from one side to the other on wide screens. Use the pattern to create clear visual checkpoints through a considered product story, not to stretch a short list into a long landing page.

See the whole content inventory

Bring every URL, owner, status, and performance signal into one view before deciding what to keep, improve, merge, or remove.

Prioritize the work that matters

Group opportunities by business value and effort so the production team can act on a reasoned queue rather than a pile of disconnected ideas.

Measure the result after publishing

Connect each change to an annotation and a stable reporting window so later movement can be investigated instead of guessed at.

The rendered example shows the rhythm, but its gray regions are explanatory UI in this specification. Production instances must contain real, informative visuals.

Why this element matters

A long page creates a navigation problem. Readers need landmarks that tell them when one idea ends and the next begins. A zigzag supplies those landmarks through repetition: image, heading, explanation; then the same structure with a different wide-screen alignment. Repeated anatomy makes each section easier to understand, while alternation keeps adjacent items from merging into one column.

The psychological benefit is strongest when the items are genuinely parallel. A reader sees the first pair, learns the pattern, and can scan subsequent headings and visuals before choosing where to slow down. The visual gives recognition; the heading names the capability; the body explains its consequence. Alternation adds just enough spatial change to reset attention without changing the information model.

That benefit has a limit. Every pair consumes substantial vertical space, particularly on a phone where the columns stack. If the explanation is only a sentence and the visual adds no evidence, the pattern makes the reader travel farther without learning more. Decorative alternation can also feel like a sales template rather than a reasoned sequence. The element earns its footprint only when each visual helps the reader understand a distinct feature, state, outcome, or workflow.

Machine extractability means software can isolate a content unit without losing the context that makes it accurate. A well-authored zigzag is a collection of explicit items, each with a heading, self-contained explanation, visual description, and optional link. Retrieval systems can extract one item as a coherent feature statement because its meaning does not depend on being “the one on the left.” Source order, not CSS placement, establishes the sequence.

Apply the element writing rules before the rules on this page: draft the complete explanation first and apply the typed element in a separate structural pass. Where this page sets narrower item counts, media requirements, body mapping, or nesting limits, these element-specific rules take precedence.

When to use it

Use a zigzag when all of these conditions are true:

  1. The page has three to six parallel features, capabilities, outcomes, or non-sequential workflow views.
  2. Every item has a real visual that explains or demonstrates its subject.
  3. Each item needs more explanation than a card allows but less than a full independent chapter.
  4. Readers benefit from scanning the sequence before reading every detail.
  5. The order is helpful but not procedural; an item remains understandable if extracted alone.

Strong uses include a product tour with one interface view per capability, a solution page pairing each operational problem with its corresponding workflow, or an ultimate guide showing several parallel models. The visual can be a screenshot, diagram, chart, or photograph when that medium carries information. Use an annotated screenshot inside an item when a raw interface capture would force readers to hunt for the relevant control.

Near misses are common. Do not use a zigzag for numbered instructions: changing sides weakens the directional signal that steps need. Do not use it for a comparison, because alternating products prevents criterion-by-criterion evaluation. Do not use it for twelve benefits that each need one sentence; cards, bullets, or a summary table use space better. Do not use it for an argument where each section depends on the previous conclusion; continuous prose and headings preserve that logic more clearly.

The most revealing test is to remove the images. If the remaining headings form a coherent set of peers and each missing visual leaves a meaningful evidence gap, zigzag is probably appropriate. If the copy becomes a generic benefit list and nothing important is lost, the images were decoration and the element is a misuse.

Logo

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Where to place it

Place the zigzag after the page has defined the shared problem and named the group of capabilities. Readers should know why the sequence matters before they encounter the first large visual. On a product or solution page, this is normally after the hero, direct answer, or short overview and before proof, detailed specifications, pricing, or the final call to action.

Introduce the whole sequence with an H2 and one short framing paragraph. Do not add a separate H2 before every item; each item title is a child heading within the shared section. Keep all items contiguous so the alternating rhythm communicates one collection. If a long qualification must interrupt the sequence, finish the zigzag and start a new section after it.

A zigzag must not sit immediately beside another large visual sequence, image gallery, product slider, timeline, or repeated card grid. Back-to-back display patterns create visual fatigue and obscure which collection is primary. It must not split a claim from its evidence, a warning from the instruction it qualifies, or a price from its purchasing conditions. It must not appear inside an ordered list, table cell, accordion panel, or another zigzag.

Use one zigzag per page by default. A second is acceptable only when the two collections answer clearly different questions, use separate section headings, and have prose or evidence between them. Never alternate the alignment of unrelated page sections merely to imitate the pattern; the collection boundary is part of the element’s meaning.

Anatomy

  1. Collection heading: Names the shared question or category covered by every item.
  2. Collection introduction: Explains why the items belong together and what the reader should notice.
  3. Item container: Keeps one visual and one text region programmatically and visually associated.
  4. Item heading: Names one specific feature, outcome, or view in concrete language.
  5. Item body: Explains what the item does, why it matters, and any boundary needed to interpret it correctly.
  6. Informative visual: Demonstrates the same subject as the text and has useful alternative text or an accessible caption.
  7. Optional item link: Offers one relevant deep dive or action after the explanation.
  8. Presentation alternation: Changes the visual side on wide screens without changing DOM order or meaning.

Spacing, color, corner radius, image crop, and breakpoint belong to the renderer. Authors provide semantic order, complete copy, and accessible media information.

Design examples

The following are the supported variants. They share one content contract; only the starting alignment, visual treatment, or viewport behavior changes.

Media-first: The default wide-screen variant starts with the first visual on the left. Use it when the first visual provides immediate recognition and the surrounding page does not already place a dominant image on that side.

Text-first: Starts with text on the left, then alternates. Use it when the opening explanation must establish meaning before the first visual or when it creates better balance with the preceding section.

Contained-media: Places screenshots or diagrams within a consistent frame. Use it for product interfaces, charts, and diagrams whose edges and labels matter. All items use the same frame logic even when source images have different dimensions.

Edge-media: Allows photographs or non-interface illustrations to fill their regions. Cropping may change responsively, but it must not remove the subject or any information described by the copy.

Mobile-stacked: Removes left-right alternation and uses one consistent reading order for every item. This is required responsive behavior, not an optional editorial variant.

There is no text-only, autoplay, or carousel variant. Removing meaningful media removes the reason to use zigzag; motion and hidden slides introduce different interaction contracts.

Parameters

NameTypeRequiredMin/maxDefaultSource
titlePlain stringYes3–12 words; 100 characters maximumNoneFirst heading in the parent body
introLimited MarkdownYes20–60 words; one paragraphNoneParent body after its first heading and before the first item
itemsOrdered collectionYes3–6 itemsNoneNested item bodies
item.titlePlain stringYes3–9 words; 70 characters maximumNoneFirst heading in each item body
item.contentLimited MarkdownYes40–120 words; one or two paragraphsNoneItem body after its first heading
item.mediaApproved asset identifier or confirmed root-relative pathYesExactly one image, screenshot, chart, or diagramNoneItem media attribute
item.altPlain stringYes unless an adjacent caption fully describes the visual1–2 sentences; 180 characters recommendedNoneItem alt attribute
item.linkURL and anchorNo0–1 per itemNoneFinal inline link in the item body
startEnumNomedia or textmediaParent attribute
mediaFitEnumNocontain or covercontainParent attribute

The parent body maps its first heading to title, its following paragraph to intro, and each nested item to one repeated pair. An item’s first heading maps to item.title; its remaining body maps to item.content. Media references and alternative text stay on the item because they describe that item alone. Authors cannot set left or right per item: the renderer derives wide-screen alignment from source position and start.

Syntax and code examples

All adapters must preserve one parent title, one introduction, ordered items, and a stable source order. The examples abbreviate the collection to three items, the minimum valid count.

Portable Markdown directive

:::zigzag{start=media mediaFit=contain}
## Turn content decisions into a repeatable system

Move from a complete inventory to prioritized production and measured results.

::item{media="inventory-view" alt="Content inventory grouped by status and owner."}
### See the whole inventory

Bring every URL, owner, status, and performance signal into one view before deciding what to change.
::

::item{media="priority-view" alt="Priority queue ordered by business value and effort."}
### Prioritize valuable work

Order opportunities by business value and effort so the team can act on a reasoned queue.
::

::item{media="impact-view" alt="Reporting view with publication annotations beside performance changes."}
### Measure published impact

Connect each change to an annotation and a stable reporting window so later movement can be investigated.
::
:::

These identifiers document the portable contract; a production adapter resolves each one to an approved asset. Authors must confirm the resolved asset exists before publishing.

Hugo shortcode

{{< zigzag title="Turn content decisions into a repeatable system" intro="Move from a complete inventory to prioritized production and measured results." start="media" mediaFit="contain" >}}
  {{< zigzag-item title="See the whole inventory" media="inventory-view" alt="Content inventory grouped by status and owner." >}}
  Bring every URL, owner, status, and performance signal into one view before deciding what to change.
  {{< /zigzag-item >}}
  {{< zigzag-item title="Prioritize valuable work" media="priority-view" alt="Priority queue ordered by business value and effort." >}}
  Order opportunities by business value and effort so the team can act on a reasoned queue.
  {{< /zigzag-item >}}
  {{< zigzag-item title="Measure published impact" media="impact-view" alt="Reporting view with publication annotations beside performance changes." >}}
  Connect each change to an annotation and a stable reporting window so later movement can be investigated.
  {{< /zigzag-item >}}
{{< /zigzag >}}

The Hugo adapter uses named parameters only. It derives alternating classes from item position and must not rewrite source order to achieve the visual pattern.

WordPress block

<!-- wp:amicited/zigzag {"title":"Turn content decisions into a repeatable system","intro":"Move from a complete inventory to prioritized production and measured results.","start":"media","mediaFit":"contain"} -->
  <!-- wp:amicited/zigzag-item {"title":"See the whole inventory","media":"inventory-view","alt":"Content inventory grouped by status and owner."} -->
  <p>Bring every URL, owner, status, and performance signal into one view before deciding what to change.</p>
  <!-- /wp:amicited/zigzag-item -->
  <!-- wp:amicited/zigzag-item {"title":"Prioritize valuable work","media":"priority-view","alt":"Priority queue ordered by business value and effort."} -->
  <p>Order opportunities by business value and effort so the team can act on a reasoned queue.</p>
  <!-- /wp:amicited/zigzag-item -->
  <!-- wp:amicited/zigzag-item {"title":"Measure published impact","media":"impact-view","alt":"Reporting view with publication annotations beside performance changes."} -->
  <p>Connect each change to an annotation and a stable reporting window so later movement can be investigated.</p>
  <!-- /wp:amicited/zigzag-item -->
<!-- /wp:amicited/zigzag -->

WordPress should restrict inner blocks to zigzag items and expose list reordering without offering manual left/right controls. The editor preview and front end must use the same item order.

Examples

Good example

Heading: Understand every stage of a content refresh

  1. Find declining pages — A trend chart shows the same URL across comparable periods. The copy explains how to distinguish sustained decline from ordinary weekly movement.
  2. Diagnose the cause — A query-and-page view shows which topics lost visibility. The copy separates intent drift, stronger competitors, outdated facts, and technical faults.
  3. Record the intervention — An annotation view shows the publication date and exact change. The copy explains why a recorded intervention makes later measurement credible.
  4. Review the outcome — A reporting view shows the agreed observation window. The copy states what success, no change, and further decline each trigger next.

This works because the four items describe parallel views within one refresh system, every visual supplies evidence the prose cannot efficiently reproduce, and the headings alone give readers a useful scan. The order supports a story without turning the element into instructions.

Bad example

Heading: Why our platform is better

  1. Easy — A decorative photograph of a smiling person accompanies “Our platform is easy to use.”
  2. Powerful — A decorative abstract shape accompanies “Get powerful results faster.”
  3. Flexible — A stock photograph accompanies “Flexible features fit every business.”
  4. Contact us — A large form asks for seven fields.
  5. Trusted — A logo strip appears without explaining who the logos represent.
  6. More features — Eight unrelated bullet points fill a tall final row.

This fails because the claims are generic, the images carry no information, and the items do different jobs. The embedded form interrupts the collection, while the last item hides a list inside a format intended for one focused explanation. The page becomes long without becoming clearer. Replace the first three claims with evidence-backed prose or compact benefit cards, place the form after the explanatory section, identify the trust evidence, and give the remaining features an appropriate list or table.

Schema markup and accessibility

Zigzag is a presentation pattern, not a Schema.org type. Its copy remains part of the enclosing Article or WebPage, and product facts may contribute to valid Product or SoftwareApplication markup only when the page and facts independently meet those requirements. Do not emit ItemList merely because the element repeats items, and never emit HowTo when the items are parallel features rather than required steps.

Use a section with an accessible heading for the collection and a semantic section or article for each item. Keep DOM order logical and identical across breakpoints. CSS grid ordering may change where the image appears visually, but keyboard, screen-reader, copy-and-paste, and search extraction order must remain consistent. Never write “as shown on the left” or “in the image to the right,” because those positions reverse or disappear on smaller screens.

Every informative image needs alternative text that states what the image contributes in context. Do not repeat the adjacent paragraph word for word. If a complex chart, interface, or diagram cannot be described concisely, add a visible caption or nearby long description. Decorative imagery is discouraged because every item is required to justify its visual; if a renderer adds decorative flourishes, they receive empty alternative text.

Headings must follow the page hierarchy rather than being hard-coded to a visual size. Item links need descriptive labels such as “Review the inventory workflow,” not repeated “Learn more” text. Do not make the entire text-and-image row one large link: nested links and unclear activation regions create keyboard and screen-reader problems. Respect reduced-motion preferences and never require scroll-triggered animation to reveal the content.

Writing rules

Write the collection title in 3–12 words and its introduction in 20–60 words. Each item title uses 3–9 concrete words, and each body uses 40–120 words. Three to six items is the supported range. These limits exist because the element needs enough substance to justify large visual regions without turning each pair into an independent essay.

Make item headings grammatically parallel. If the first begins with a verb—“Find declining pages”—the others should too. Each body should answer three questions in a natural order: what is this, why does it matter here, and what should the reader notice in the visual? Use specific nouns, interface labels, conditions, and consequences. Avoid unqualified superlatives such as “best,” “powerful,” or “revolutionary.”

Keep the depth balanced. One 110-word item beside two 40-word items signals that the collection may be mixing levels of abstraction. Split the broad item, combine shallow items, or move detail into a linked page. Links are optional and limited to one per item so the sequence remains explanatory rather than becoming a navigation directory.

Never put these inside a zigzag item:

  • A form, newsletter capture, price table, offer, or primary call to action.
  • A comparison table, accordion, tabs, carousel, gallery, video player, or another zigzag.
  • A numbered procedure whose order is required for success.
  • Several unrelated feature bullets added to fill the visual height.
  • An unsupported claim, testimonial fragment, or logo without its source and context.
  • An image added only because the layout has an image slot.

Post types that use it

The postTypes frontmatter is the source of truth for this relationship. A zigzag is optional in each listed type and should appear only when the page has a qualifying parallel, visual sequence.

Post typeTypical rolePlacement and constraint
Ultimate guideShow parallel models, systems, or advanced applicationsAfter the common concept is defined; not for sequential chapters
Product pageTour several primary capabilities with product evidenceAfter problem framing and before specifications, proof, or pricing
Use-case pageConnect stages or operational views to one audience’s jobAfter the use case is named; keep every item specific to that audience
Solution pagePair related problems or outcomes with solution workflowsAfter the solution overview; do not mix outcomes, testimonials, and CTAs as peers
Feature pageExplain distinct sub-capabilities of one featureAfter the core feature answer; use screenshots that demonstrate each sub-capability
Documentation articleExplain parallel interface regions or configuration modesUse only for non-sequential concepts; required actions belong in a step list

QA checklist

  • The sequence contains three to six genuinely parallel items.
  • One H2 and a short introduction explain why the items belong together.
  • Every item has a concrete, grammatically parallel heading.
  • Every body stays within 40–120 words and has comparable depth.
  • Every visual exists, contributes information, and matches its item.
  • Alternative text or an accessible caption conveys each visual’s useful information.
  • The default DOM order is logical without any CSS or images.
  • Wide-screen alternation is derived automatically; authors did not assign arbitrary sides.
  • Mobile uses one consistent stacked order without horizontal scrolling.
  • No wording depends on left, right, or another viewport-specific position.
  • No item contains forms, tables, nested display components, or procedural steps.
  • The collection is not adjacent to another large repeated visual pattern.
  • Links are descriptive and limited to one optional link per item.
  • No schema type is inferred from the alternating layout alone.
  • The page remains useful when animation is disabled and images load slowly.
  • Markdown, Hugo, and WordPress representations preserve the same fields and item order.

Use zigzag sections when parallel ideas deserve parallel evidence. Alternation should help readers notice each coherent item; it should never be why the item exists.

← All Academy tutorials

Ready to put it into practice?

Free check · 7-day trial · no credit card