Vittorio Vittori

Design System Architect / Senior UX Designer

Constraints-Driven Design

Define clear constraints so teams build consistent solutions without stifling flexibility.

Design Systems
Architecture

When I design a design system, I treat constraints as a design tool, not as a limitation to work around.

Explicit constraints reduce ambiguity, guide decision-making, and prevent the gradual erosion of the system.

In the absence of clearly defined constraints, teams tend to:

  • improvise solutions,
  • stretch components beyond their intended purpose,
  • and introduce inconsistencies that are difficult to detect and even harder to remove.

A constraints-driven system makes boundaries visible.

It defines not only what is possible, but also what is intentionally unsupported, allowing teams to move faster and with greater confidence.

  • Constraints are most effective when they are:
  • explicit,
  • documented,
  • and enforced by the system itself.

Limited and intentional component APIs

Components were designed with intentionally constrained APIs to prevent misuse and uncontrolled variation.

Expose only properties that support known and validated use cases. Add configuration options to solve isolated problems. Treat every new prop as a design decision with long-term impact. Turn components into generic containers with unlimited flexibility.
A list of tools and services related to this argument. Documentation tools Curated component APIs Robust API design it may be outdated

Design tokens as enforced boundaries

Design tokens were used to encode visual constraints directly into the system.

Use tokens to control spacing, color, typography, and motion. Allow arbitrary values outside the token set. Make tokens the only supported way to express system values. Treat tokens as optional or decorative abstractions.
A list of tools and services related to this argument. Tokens documentation Tokens tools it may be outdated

Composition rules instead of free assembly

Composable components were governed by explicit composition rules.

Documentation from codebase

html
// StencilJS component documentation
/**
 * @slot default - Add `text string`, `HTML elements` or `components` to this slot.
 * @slot action - Add `HTML elements` or `components`, it is **recommended** to use `mds-button` element.
 */

Component composition

html
<mds-modal>
  <mds-banner
    headline="Modal title"
    icon="mi/outline/info"
    slot="window"
    tone="weak"
    variant="primary"
  >
    <mds-text typography="caption">This is a modal text content.</mds-text>
    <mds-button
      icon="mi/outline/email"
      slot="action"
      tone="strong"
      variant="primary"
    >
      Proceed
    </mds-button>
  </mds-banner>
</mds-modal>
Define which components can be nested or combined. Allow unrestricted component nesting. Document supported compositions and known anti-patterns. Rely on visual review to catch invalid compositions.
A list of tools and services related to this argument. Documentation tools it may be outdated

Accessibility constraints as non-negotiable

Accessibility requirements were encoded as hard constraints rather than guidelines.

Enforce color contrast, focus management, and keyboard navigation by default. Allow opt-out accessibility features. Prevent configurations that violate accessibility standards. Treat accessibility as a downstream responsibility.

System-level defaults over local overrides

Defaults were treated as part of the system's contract.

allowed

Using component attributes as defaults

html
<mds-modal
  headline="Modal title"
  icon="mi/outline/info"
  tone="weak"
  variant="primary"
>
  <mds-text typography="caption">This is a modal text content.</mds-text>
  <mds-button
    icon="mi/outline/email"
    slot="action"
    tone="strong"
    variant="primary"
  >
    Send email
  </mds-button>
</mds-modal>
not allowed

Skipping attributes for out of scope customization

html
<mds-banner
  icon="mi/outline/info"
  class="bg-tone-neutral text-tone-neutral-01 fill-variant-primary-03"
>
  <mds-text typography="caption">This is a modal text content.</mds-text>
  <mds-button
    icon="mi/outline/email"
    slot="action"
    class="bg-variant-primary-03 fill-tone-neutral text-variant-primary-10"
  >
    Send email
  </mds-button>
</mds-banner>
Provide strong, opinionated defaults aligned with system goals. Encourage local overrides for stylistic reasons. Encourage teams to rely on defaults instead of customization. Allow silent deviations from system behavior.
A list of tools and services related to this argument. Pratical documentation Component testing it may be outdated

Explicit "out of scope" decisions

Some use cases were intentionally excluded from the system.

Clearly document what the system does not support. Attempt to cover every possible scenario. Use exclusions to protect system integrity. Expand the system reactively without evaluating systemic impact.
A list of tools and services related to this argument. Issue templates it may be outdated

Why this principle matters

Constraints are what make systems scalable and trustworthy.

They reduce cognitive load, prevent entropy, and make correct usage the easiest path.

A design system without constraints is not flexible, it is fragile.

By designing constraints intentionally, the system enables creativity within safe and predictable boundaries.