---
title: Apply consistent property design patterns across commerce components
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

## 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](https://docs.kentico.com/documentation/developers-and-admins/customization/extend-the-administration-interface/ui-form-components/reference-admin-ui-form-components.md#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](https://docs.kentico.com/documentation/developers-and-admins/development/builders/builder-component-properties-visibility-and-validation.md) 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.