P292 · Context management

Lock invariants, vary composition

Keep shared identity fixed while varying individual artifact purpose and composition.

Editorially reviewed

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Create checkout, receipt and order-detail mockups that share product identity but serve different tasks. Teaching invariants are #1D4ED8, 16px body text, 6px corners and Cart/Orders/Profile navigation. Checkout emphasizes input, receipt a success summary and details order information.

Mechanism

Define invariants and allowed variation before generating the set. Palette, type hierarchy, components and navigation share one contract; composition/emphasis vary by purpose. Compare each actual artifact with sibling screens, including states and spacing. A written internal contract alone does not establish consistency.

Bad example

Design the three screens independently with new colors, fonts and navigation on each to maximize creativity, without comparing shared rules.

Good example

Use the teaching invariants: #1D4ED8, 16px body, 6px corners, Cart/Orders/Profile navigation and shared button/spacing treatment. Vary checkout toward inputs, receipt toward success and details toward grouped information. Record shared rules and purpose-driven composition differences, compare actual outputs together and repair unexplained drift.

Why the change matters

Reinventing identity makes learned interface behavior harder to reuse. Separating invariants from composition preserves recognizable operations without forcing every screen into the same template.

Observable expectation

An illustrative matrix has three screen rows and palette/type/navigation/button/emphasis columns. Shared columns agree; emphasis differs as input, success and details.

Inspect actual mockups, not prompt text alone. An unexplained navigation or corner-style change requires revision; differing composition does not.

Limits

The values are teaching choices, not universal design standards. Responsive behavior, interaction states and accessibility need implementation checks; static mockups cannot prove them. Encode legitimate differences as named variants rather than deleting them for uniformity.

Sources and evidence

Read the editorial criteria