R1.15.2brand-state combinatorial costdesign

Validation cost grows as brands times states when brands are added

Aliases: combinatorial QA · brand matrix · brands times states

What it is

Adding a brand is not a few extra home-page screenshots. It is every existing state run again: default, hover, disabled, loading, empty, error, selected, focus. Validation cost grows as brands × states (times any theme axis still in play). Three brands and eight states are twenty-four cells, not three pictures. Missing cells hide failures that explode only in one brand’s one state: contrast, truncation, focus rings.

The product is multiplication because state and brand are orthogonal: brands do not delete states, and states do not know brands. Orthogonality is the benefit of shared structure, and it is the shape of validation. Treating validation as “glance at each brand” pretends the product is a sum.

Why it happens

Human walkthrough budget grows linearly with pages and brands; the matrix grows with the product. When budget runs out, the cells cut are always the tail: one brand’s empty state, one brand’s error-plus-focus. The tail is exactly where value tables show: danger colour contrasts on a light surface and fails on that brand’s dark surface; long copy fits brand A’s wide button and bursts on brand B’s rounder, narrower primary action.

Automation that only captures “default × brand” squashes the product back into a sum. States must be driven to their real enum, brand tables must be swapped, and the Cartesian product of the two is the smallest complete set. Theme axes (light-dark, contrast, density) are a third multiplier; ignoring them lets a report that “three brands were tested” still miss the same state under high-contrast compact.

Where it stops holding

If a brand only swaps a mark and component values are identical, the multiplier is 1 and validation need not multiply — but only after proving the tables are equal item by item, not “they look close”. When a product forbids a state in a brand (no dangerous action), that cell may be removed from the matrix; the removal must be written down, not skipped in silence. Sampling (two states per brand) can only find cells the sample hit; unsampled cells cannot be marked passed. Tiny internal tools with a handful of call sites and a brand baked at build time have no runtime product; the matrix collapses to one brand, all states.

Applying it

  • Write the matrix: rows are states (including stacked states), columns are brands, theme axes as layers when needed. Each cell is pass / fail / not applicable, and not-applicable needs a reason.
  • Automate at least default, disabled, error, empty, focus × every brand; humans cover stacked states and long copy.
  • Acceptance for a new brand is “the matrix gained a column and that column is filled”, not “the home page swapped a mark”.
  • How to check: count public states n and brands b; require at least n×b driven records (shots or assertions). If records are fewer than the product, list the missing cells. In a missing cell, lengthen copy and put focus on: if it fails while the report still says “three brands tested”, multiplication was treated as addition. When a brand is added, see whether hours scale near ×n, not “a few extra pictures”.

Related

  • Same group: R1.15.1 Brands share structure and only retarget semantic values · 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: brand-state combinatorial cost · combinatorial QA · theme matrix

Cards in the same group

Quick Actions

Share

Share this page

ios_share

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