From Zeplin and Figma to a Sitecore Component Library (and Multi-Level Navigation That Stays Oriented)

A Figma (or Zeplin) file is not a Sitecore component library. Design systems that stop at frames and tokens leave delivery teams guessing: which fields belong on the datasource, which placeholders are nested, how global nav differs from section nav, and what breaks when authors invent a one-off variant. This field note walks from simple definitions to a practical build path: map design tokens and components into Sitecore templates and renderings, keep multi-level navigation oriented as users drill in, and govern the library so agencies cannot silently fork it.

Executive Summary

Enterprise Sitecore programs fail the design-to-CMS handoff in predictable ways. Designers ship a polished library in Zeplin or Figma. Developers invent parallel templates. Authors pick the wrong rendering. Accessibility and navigation rules never make it into the component contract. The fix is not another workshop. It is a documented component library that lives in Sitecore (and in source control) with the same names, variants, and constraints the design system already defined.

• Outcome: One named component equals one rendering + datasource template + documented variants.
• Navigation: Global (top-level) and section (in-page / section) nav are separate components with shared orientation rules.
• Tools: Zeplin and Figma are inputs. Sitecore Helix/modules, serialization, and Storybook (or equivalent) are the library of record for engineering.
• Governance: New variants require a design token + template field + rendering parameter change, not a copy-paste of an old rendering.

Basics: Words Teams Confuse

Term	Design meaning	Sitecore meaning
Component	Reusable UI block in Figma/Zeplin	Rendering + datasource template (+ optional view model)
Variant	Visual state (size, theme, layout)	Rendering parameters, template inheritance, or SXA variant
Token	Color, type, spacing variable	CSS variables / theme dictionary, not free-text fields
Frame / artboard	Layout canvas	Not a CMS object; map to page types or placeholders
Library	Shared Figma/Zeplin library	Serialized module of templates, renderings, and tests

If your team cannot fill that table in one meeting, stop building pages and fix vocabulary first.

Zeplin Era vs Figma Era (Same Sitecore Outcome)

Many regulated programs still have Zeplin in the rear-view mirror and Figma as the current source. The Sitecore mapping does not change. Only the export and comment workflow changes.

Concern	Zeplin (typical)	Figma (typical)	Sitecore library action
Specs	Screen + measurement panels	Dev Mode / inspect	Capture field max lengths and spacing tokens in the component README
Components	Symbols / styleguide	Components + variants	One Sitecore rendering per published component set
Handoff comments	Zeplin comments	Figma comments / FigJam	Decisions land in ADR or component changelog, not only in the design tool
Tokens	Often manual	Variables / tokens	Export to CSS variables; forbid hex in rich text

Step 1: Inventory the Design System Before You Open Content Editor

1. List every published component in the design library (name as designers say it).
2. Mark each as page chrome (header, footer, nav), section (hero, cards, FAQ), or utility (skip link, cookie banner).
3. Flag multi-level navigation separately: global top nav vs section nav vs mobile drawer.
4. Note WCAG notes already in design (focus rings, tap targets, motion). Those become rendering requirements, not optional CSS.

# Example inventory row (keep in git as CSV or YAML)
name: SectionNav
design_source: Figma / Foundations / Navigation
sitecore_rendering: Foundation.Navigation.SectionNav
datasource_template: Foundation.Navigation.SectionNav
placeholders: none
variants: Default, Sticky, Compact
a11y: aria-current, skip-to-section, 24px AA / 44px practice targets

Step 2: Map One Design Component to One Sitecore Contract

Use a fixed mapping table. Do not invent fields during the first sprint of page builds.

Design property	Sitecore field / parameter	Notes
Title text	Single-Line Text or Rich Text (capped)	Match Figma character limits
CTA label + URL	General Link	Separate fields if design shows icon + label
Theme (light/dark)	Rendering parameter or droplink	Never free text
Layout (2-col / 3-col)	Rendering parameter	Drive CSS grid classes only
Image	Image field + alt text required	Alt is content, not optional
Nested blocks	Placeholder + child datasources	Prefer placeholders over mega-templates

Helix-style folders keep Foundation navigation separate from Feature marketing components and Project site wiring. Official guidance: Sitecore Helix and Sitecore Documentation, items and templates.

Step 3: Multi-Level Navigation That Keeps Users Oriented

Michael-style requirements (top-level plus section-level nav) fail when teams build one mega menu component and reuse it everywhere. Split the problem.

Global (top-level) navigation

• Owns primary destinations across the site (product, about, resources, HCP vs consumer gates).
• Datasource is usually a nav root item with children as links or folders.
• Must expose current section state (aria-current="page" or section).
• Mobile: one disclosure pattern, keyboard operable, focus return on close.

Section-level navigation

• Owns orientation inside a section (About YEZTUGO, Starting YEZTUGO, Cost & Coverage style trees).
• Reads the current page context and highlights the active sibling or ancestor.
• Should not duplicate the entire global tree.
• Sticky section nav needs a skip control and must not trap keyboard users.

Orientation rules (put these in the component README)

Rule	Why it matters	Implementation hint
Always show where you are	Users drilling into deep trees get lost	aria-current, visible active class, optional breadcrumb sibling
Section nav scoped to section root	Prevents dumping the whole site into a side rail	Resolve section root from page template or ancestor
Same link labels as page titles	Mismatched labels break trust	Nav label field with fallback to display name
Keyboard order matches visual order	WCAG focus order	No positive tabindex; CSS order must match DOM
Mobile drawer closes on Escape	Expected pattern	Focus trap only while open; restore trigger focus

// Pseudocode: resolve section nav root from current page
var page = Sitecore.Context.Item;
var sectionRoot = page.Axes.GetAncestors()
  .FirstOrDefault(a => a.TemplateID == SectionRootTemplateId)
  ?? page;
var links = sectionRoot.Children
  .Where(c => c.TemplateID == NavLinkTemplateId);

Step 4: Build the Library in Layers

1. Tokens: colors, type scale, spacing, focus ring. Ship as CSS variables consumed by all renderings.
2. Primitives: Button, Link, Icon, Text styles. No page-specific logic.
3. Composites: Card, Hero, Accordion. Datasource templates with strict fields.
4. Chrome: GlobalNav, SectionNav, Footer, SkipLink. Highest review bar.
5. Page types: compose placeholders only; authors should not invent new chrome.

Serialize templates and renderings with Sitecore Content Serialization or Unicorn/TDS equivalents so the library is reviewable in pull requests. See Sitecore Content Serialization.

Step 5: Variant Strategy Without Template Explosion

Approach	Use when	Avoid when
Rendering parameters	Layout/theme toggles	Content that authors must translate
Template inheritance	Shared fields across related components	Unrelated components sharing a god template
SXA variants / styles	SXA sites with style toolkit	Headless-only shops without SXA
Separate rendering	Markup differs enough to confuse authors	Two nearly identical heroes with one field difference

Rule of thumb: if a designer called it a variant of the same component, prefer parameters. If markup structure changes (for example carousel vs static grid), prefer a separate rendering.

Step 6: Author Experience Is Part of the Library

• Field sections ordered like the Figma panel (content, media, behavior).
• Help text that names the design component ("Maps to Figma: Section Nav / Compact").
• Validation: required alt text, max lengths, allowed link types.
• Experience Editor / Pages chrome that does not encourage nested one-offs.

Step 7: Headless and MVC Both Need a Contract

For Layout Service / XM Cloud headless, the component library is also a JSON contract. Field names in Sitecore must match what the front-end component map expects. Document the map next to the Figma component name.

{
  "uid": "...",
  "componentName": "SectionNav",
  "fields": {
    "heading": { "value": "About" },
    "items": [ { "fields": { "link": { "value": { "href": "/about", "text": "About" } } } } ]
  },
  "params": { "variant": "sticky" }
}

Further reading: XM Cloud layout and architecture.

Worked Mini-Example: Section Nav from Figma to Sitecore

1. Figma component Nav / Section / Default with variants Compact and Sticky.
2. Create template Section Nav with fields: Heading (single-line), Links (treelist of Nav Link items).
3. Create Nav Link template: Link (general link), Show In Mobile (checkbox).
4. Rendering parameters: Variant = Default | Compact | Sticky.
5. View renders ordered list, sets aria-current when link target matches context item or ancestor.
6. Add Storybook (or static HTML fixture) with three states: default, active child, mobile open.
7. Accessibility check: tab order, Escape closes mobile, focus visible on all links.

Governance Checklist (Keep the Library from Forking)

• No new rendering without a design component ID in the README.
• No hex colors in rich text; tokens only.
• Nav changes require IA review, not only visual QA.
• Serialization PR required for template/rendering changes.
• Quarterly audit: unused renderings, duplicate heroes, orphan placeholders.

Further Reading

• Sitecore Helix documentation
• Sitecore renderings
• Sitecore Content Serialization
• XM Cloud layout and architecture
• WAI-ARIA Authoring Practices: Disclosure (mobile nav)

Actionable Checklist

1. Export a component inventory from Zeplin/Figma with Sitecore names blank; fill names in a working session.
2. Split Global Nav and Section Nav into two renderings with orientation rules written down.
3. Create mapping tables (design property → field/parameter) before the first page build sprint.
4. Serialize templates/renderings; reject PRs that add one-off copies of library components.
5. Add fixtures for Default / Active / Mobile for every chrome component.
6. Schedule a monthly library review: variants, unused renderings, a11y regressions.