Treatment | UXLab

Definition

A purely stylistic way of rendering one component — a primary against a secondary button, or two differently styled accordions — with the same content model, the same props and states, the same behavior and the same accessibility pattern; only the values differ, and they resolve through the component's token contract

The Agentic DS draft's word (2026-09-21) for what the team used to call a theme variant or component theme variant, and what Helium exports as a component's named theme. Naming it settles the ambiguity from the other side: a difference that is only visual is a treatment, never a variant. Mechanically a treatment is sparse — it states only what it diverges on and everything else falls through to the token contract's defaults — and it is selected by a treatment prop, which is a per-instance authoring choice; the values a treatment carries (an accordion's icon position, say) are design decisions and live in the contract, not in props. Core defines every treatment (ruled 2026-09-28). A brand may adjust a treatment's touchpoints as a configuration override, but it cannot create one.

Design System

The test is what an adapter has to do about it: nothing new. A treatment changes values within the same structure and behavior, so an adapter written from the schema renders it once its tokens are declared. If the adapter needs new markup or new handlers, it was a variant. The converse doesn't hold: a missing binding in an adapter is an implementation gap, not by itself evidence of a variant. Changing anchor behavior or the content model needs a separate assessment even when the result looks similar.

In cwds, a variants entry with kind: presentational is not automatically a treatment. Most are props (a flexbox's direction, a hero's position), and a few are treatment values (the accordion's icon position). Each value's mapsTo says which (cwds #59, 2026-09-25). Declared treatments live in the Component Schema's token contract, not in cwds.

Definition

Related Terms