R1.15.1semantic retargetingdesign

Brands share structure and only retarget semantic values

Aliases: shared structure · brand theming · retarget the semantic layer

What it is

Several brands share one component tree, one set of slots, and one set of state names. Difference between brands is confined to semantic values: the role called “primary action surface” is one blue for brand A and one orange for brand B. Semantic retargeting replaces those role values and does not copy components or change the tree. Once structure forks per brand, every new state and every new slot must be done once per brand, and sharing is over.

The retarget is a role, not a particular pixel on a page. A button’s “primary action” is still primary action in every brand; what changes is what primary action is painted as. Cloning “brand-A button” and “brand-B button” abandons shared structure, and later interaction fixes will land on only one of the clones.

Why it happens

A component tree encodes duties and a state machine: which slot, which empty-state edge, where focus enters. None of that is a brand. A brand encodes a map from roles to concrete measures. Split the layers and the map can be swapped as a table without touching the tree. The swap happens at the semantic layer because raw values (a hex, a radius in pixels) are shared by many roles; changing a raw value would retarget places that should not change brand. The semantic layer is indexed by “what role this sentence plays in the UI”, so a table swap only moves positions that declared that role.

The moment a brand-specific special carves the structure (an extra slot only A has, a state only B walks), the shared tree can no longer describe both sides. Later edits must first ask “which tree is this”; the system has become two. Retargeting keeps sharing only if specials are pushed back into values, not into structure.

Where it stops holding

When brand difference is already at information architecture and navigation model, shared structure is a fiction and retargeting will not save it; those are two products, not one tree in a wig. Where law or trademark forbids one brand from ever showing the other’s measures, semantic tables must be isolated at build time, not swapped after the fact — if the other table is still in the package, isolation failed. With one brand and no white-label plan, building an empty table “for retargeting” is extra indirection; add it when a second brand is a real demand. Disguising a structural difference as a value (a brand switch for “whether this slot shows”) recuts the tree per brand; that is not retargeting.

Applying it

  • Components reference role names only (primary action surface, danger text, card radius). Brand packages supply the role-to-value table. Hard-coding a brand’s numbers inside a component is forbidden.
  • A new brand is a new table, not a component clone. Review rejects “add a slot for this brand” unless that slot has a duty in every brand.
  • Build an artefact that can swap tables, and render the same flow on the same tree under two brands.
  • How to check: walk primary action, danger, and empty state on brand A’s flow; switch to brand B — the tree and state names must not change, only role values. Then add a state in A: B must own that state automatically, values coming from B’s table. If B needs its own component source to paint the state, structure has already forked by brand.

Related

  • Same group: R1.15.2 Validation cost grows as brands times states when brands are added · R1.15.3 Theme is not only light and dark; it includes contrast and density · R1.15.4 A user-chosen theme must persist across sessions and take effect immediately
  • Adjacent: R1.01 Named values · R1.09 Value layers and semantics
  • Search terms: semantic retargeting · multi-brand shared structure · brand theme table

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/R1.15.1