What this is

A blank mapping template for turning a design component into a real content management system (CMS) contract before anyone builds a page. It is the artifact that stops a Figma file from being mistaken for a component library. Fill one row per component, agree it across the design and engineering teams, and you have a contract instead of an argument.

This template is CMS-agnostic. The right-hand columns use Sitecore terms because that is where the discipline is richest, but the same table works for Storyblok, Contentful, Sanity, or any structured CMS: the point is to decide, once, where every piece of content lives and how an author is prevented from breaking it.

How to use it

List every component from the design, using the designer-facing names.
For each field in the component, decide the CMS field type and its constraint. Prefer the most restrictive type that works (a droplink over free text, a general link over separate label and URL fields).
Decide how variants are handled: rendering parameters for layout and theme toggles, a separate rendering only when the markup structure genuinely differs.
Record the accessibility requirements as build requirements, not a later cleanup pass.
Note where the CMS enforces a rule so an author cannot undo it.

If the two teams cannot fill a row in one sitting, that disagreement is the finding. Resolve it before building.

The terminology map (fill this first)

Term	Design meaning	CMS meaning (your agreed definition)
Component
Variant
Token
Frame / artboard
Library

The per-component mapping table

Component	Field (design)	CMS field type	Constraint	Variant handling	Accessibility requirement	CMS-enforced?

Column notes

CMS field type: single-line text, rich text, image, general link, droplink, treelist, number, checkbox.
Constraint: character limit, required, allowed link types, allowed values.
Variant handling: rendering parameter, template inheritance, SXA variant, or separate rendering.
Accessibility requirement: required alt text, 24px min target size, aria-current, keyboard order, contrast token.
CMS-enforced?: yes or no. A "no" is a note to add a field constraint, a rendering default, or a render-time check so the requirement does not depend on the author remembering.

Worked example row

Component	Field (design)	CMS field type	Constraint	Variant handling	Accessibility requirement	CMS-enforced?
SectionNav	Heading	Single-line text	Required, max 40 chars	Variant param: Default / Compact / Sticky	Nav label must match page title; 24px min targets	Yes: required field + droplink variant

Companion reading

The full process this template belongs to is in Figma Developer Handoff, Sitecore Edition, and the accessibility column ties into the WCAG 2.2 AA checklist.

## What this is A blank mapping template for turning a design component into a real content management system (CMS) contract before anyone builds a page. It is the artifact that stops a Figma file from being mistaken for a component library. Fill one row per component, agree it across the design and engineering teams, and you have a contract instead of an argument. This template is CMS-agnostic. The right-hand columns use Sitecore terms because that is where the discipline is richest, but the same table works for Storyblok, Contentful, Sanity, or any structured CMS: the point is to decide, once, where every piece of content lives and how an author is prevented from breaking it. ## How to use it 1. List every component from the design, using the designer-facing names. 2. For each field in the component, decide the CMS field type and its constraint. Prefer the most restrictive type that works (a droplink over free text, a general link over separate label and URL fields). 3. Decide how variants are handled: rendering parameters for layout and theme toggles, a separate rendering only when the markup structure genuinely differs. 4. Record the accessibility requirements as build requirements, not a later cleanup pass. 5. Note where the CMS enforces a rule so an author cannot undo it. If the two teams cannot fill a row in one sitting, that disagreement is the finding. Resolve it before building. ## The terminology map (fill this first) | Term | Design meaning | CMS meaning (your agreed definition) | |---|---|---| | Component | | | | Variant | | | | Token | | | | Frame / artboard | | | | Library | | | ## The per-component mapping table | Component | Field (design) | CMS field type | Constraint | Variant handling | Accessibility requirement | CMS-enforced? | |---|---|---|---|---|---|---| | | | | | | | | | | | | | | | | | | | | | | | | **Column notes** - **CMS field type:** single-line text, rich text, image, general link, droplink, treelist, number, checkbox. - **Constraint:** character limit, required, allowed link types, allowed values. - **Variant handling:** rendering parameter, template inheritance, SXA variant, or separate rendering. - **Accessibility requirement:** required alt text, 24px min target size, aria-current, keyboard order, contrast token. - **CMS-enforced?:** yes or no. A "no" is a note to add a field constraint, a rendering default, or a render-time check so the requirement does not depend on the author remembering. ## Worked example row | Component | Field (design) | CMS field type | Constraint | Variant handling | Accessibility requirement | CMS-enforced? | |---|---|---|---|---|---|---| | SectionNav | Heading | Single-line text | Required, max 40 chars | Variant param: Default / Compact / Sticky | Nav label must match page title; 24px min targets | Yes: required field + droplink variant | ## Companion reading The full process this template belongs to is in [Figma Developer Handoff, Sitecore Edition](/blog/enterprise-cms/figma-developer-handoff-sitecore-component-library), and the accessibility column ties into the [WCAG 2.2 AA checklist](/tools/wcag-22-aa-checklist).

Figma-to-CMS Component Mapping Table (Template)