AI agents: the content index is at /llms.txt. Every page is also available as Markdown — send the request header Accept: text/markdown, or append .md to the page URL.
Xperience Docs
  • Community Questions & Answers (opens in a new tab)
  • Contact support (opens in a new tab)

Cookie consent

We use necessary cookies (opens in a new tab) to run our website and improve your experience while browsing. Additional cookies are only used with your consent. You may revoke your consent on the Cookies Policy (opens in a new tab) page or in your browser at any time.

Configure (opens in a new tab)
  • Documentation
    Administration interface basicsDevelopers and adminsBusiness usersChangelogGlossary
  • Guides
    Welcome to Xperience by KenticoAdministration interface basicsCustomer journeysDigital marketingConfigurationDevelopmentArchitectureUpgrade to Xperience by Kentico
  • Training
    For AdminsFor Business usersFor DevelopersFor Solution architects
  • API Examples
    ConfigurationContent managementDevelopmentDigital marketing
  • Changelog
    Documentation updatesSecurity advisories

Commerce content modeling

  • Introduction to commerce content modeling
  • Model product content type
  • Define product content types fields
  • Model financial fields
  • Model product benefits and features
  • Model product taxonomies
  • Model a reusable SKU product content type
  • Define fields for the reusable SKU product content type
  • Choose a product storage strategy
  • Define core product fields with reusable field schemas
  • Model SKU details as a reusable field schema
  • Compose related content to ProductSKUs
  • Model product variants
  • Model price options for variants
  • Model shipping data fields
  • Verify your product model with stakeholders
  • Test your product content type with real data
  • Model commerce wrapper pages
  • Model a product listing page
  • Model a product detail page
  • Design considerations for commerce wrapper pages
  • Content governance considerations for commerce pages
  • Naming conventions and organization
  • Avoid common modeling mistakes for commerce pages
  • Model commerce presentation components with Page Builder
  • Understand the three widget patterns
  • Design mixed content widgets
  • Design referenced content widgets
  • Design stored content widgets
  • Design section components
  • Design commerce page templates
  • Apply consistent property design patterns across commerce components
  • Establish content governance for commerce presentation components
  • Commerce presentation components wrap-up
  • Explore commerce content modeling in Training guides
  • Content querying and content modeling training guides
  • Browse the commerce content modeling training guides
  • Learn more about commerce content modeling

Module: Commerce content modeling

32 of 38 Pages

Apply consistent property design patterns across commerce components

Apply consistent property design patterns

Consistent property design across all your widgets, sections, and page templates creates a predictable editing experience. We'll talk mostly about widget properties in this section, but the principles apply to all Page Builder component properties.

We recommend grouping widget properties into these five categories:

Content source properties - These properties define where the widget gets its data. Built-in Combined content selector form component allows you to restrict which reusable content users can link to. They also provide options for allowing single or multiple selections.

Override properties - Text overrides (choose between short text, text area, and rich text based on the content) and provide clear labeling. Use naming conventions across the whole project, for example, "Override [FieldName] (optional)." Include a description that explains the fallback behavior, for example: "If empty, displays the product name from the Content hub."

Display/Styling properties - Layout options (grid, list, card styles), color schemes (use presets rather than custom color pickers to maintain brand consistency), spacing controls (padding, margins, gaps), and responsive behavior toggles.

Behavior properties - Interactive elements (links, buttons, hover effects), animation and transition options, and loading behaviors such as lazy loading and autoplay settings with sensible defaults.

Visibility/Conditional properties - Show/hide toggles for optional elements (dates, authors, metadata), conditional display based on whether data is present in the referenced content item, and permission-based visibility for audience-specific content.

How these categories apply across component types

Widgets use all five categories extensively, where content source and override properties are mostly relevant to Mixed content patterns.

Sections primarily use display/styling and visibility properties, with minimal content source needs (mainly widget zone configuration, background image/color, and rarely section title) and no override properties.

Templates balance content source (page-level filtering), display (global layout modes), and visibility (conditional areas) with fewer behavior properties than widgets.

Property design principles by component type

All components:

  • Use clear, non-technical labels.
  • Provide helpful descriptions and tooltips.
  • Set sensible defaults.
  • Use visibility conditions for context-specific properties

Widgets:

  • Limit to 15 properties maximum; consider applying visibility conditions.
  • Group logically: Content → Overrides → Display → Behavior.
  • Avoid duplicating Content hub fields.

Sections:

  • Limit to 10 properties.
  • Focus on layout, spacing, and responsive behavior.
  • Don't include other content-specific properties than section styling.

Templates:

  • Limit to 5-8 global properties.
  • Affect the entire page, not individual components.
  • Focus on page-level decisions and defaults.
← Previous page

32 of 38

Mark complete and continue →