Design Principle Card¶

A reusable knowledge artifact — instantiates Design-Principle Extraction and Reapplication

A durable, reusable card that states the extracted principle in a form specific enough to guide a design and testable enough to be wrong — with its evidence, transfer conditions, and failure warnings attached.

The Design Principle Card is where the whole analysis crystallizes into something a future designer can pick up and reuse. It is a short, standardized record — one principle per card — that states the design logic in the abstract, but not so abstract it becomes a platitude: the discipline is that the statement must be specific enough to guide a real design decision and falsifiable enough to be wrong. What distinguishes it from every other mechanism here is that it is the durable output, the library entry — and that it deliberately carries its own failure warnings: the negative cases and boundary conditions under which the principle stops holding, recorded right alongside the principle so no one reuses it blind.

Example¶

A reliability team studies how a regional electrical grid handles overload: instead of tripping to a total blackout, it sheds non-critical load in stages — brownouts — and keeps hospitals and core services up. They card the principle. Name: Graceful load-shedding. Statement: "Under overload, degrade service in priority order rather than fail whole; pre-classify load into tiers so the system knows what to drop first." Evidence: grid behavior during summer peaks; the same shape in aircraft power management. Transfer conditions: works only where load can be pre-tiered and partial service is genuinely useful. Failure warnings — the negative cases: the principle backfires where every unit of load is equally critical (dropping any of it fails the mission), and where users treat "degraded" as "broken" and abandon the system entirely, so the brownout costs more than a clean stop.

Months later a SaaS team facing traffic spikes finds the card, reads the failure warnings first, confirms their load can be tiered and partial service is useful, and adapts the principle into feature-level rate-limiting — reusing the design logic without having to rediscover it, and knowing exactly where it would break.

How it works¶

The card's distinguishing structure is a fixed set of fields — principle statement, the objective it serves, evidence, transfer conditions, and failure warnings — that force two things a looser note skips. First, an abstraction that is testable: the statement is written so a design either honors it or doesn't, banning mush like "be user-friendly." Second, a negative-case section that is mandatory, not optional: the card is not considered complete until someone has named the conditions and known cases where the principle fails. That pairing — a crisp claim plus the boundary of where it holds — is what makes a card safe to reuse by someone who never met the source.

Tuning parameters¶

Abstraction level — how far the statement rises above the source. Too concrete and it only fits the original context; too abstract and it degrades into a slogan that guides nothing. The card lives or dies on this dial.
Evidence bar — how much and how strong the supporting evidence must be before a card is published. A high bar keeps the library trustworthy; a low bar fills it fast with untested folklore.
Failure-warning rigor — how hard the negative-case section is pushed. Demanding real counter-cases (not hypotheticals) makes the card safer but slower to write.
Granularity — one broad principle per card vs several narrow ones. Narrow cards transfer more reliably; broad cards cover more ground but blur their own transfer conditions.

When it helps, and when it misleads¶

Its strength is compounding: cards turn one-off extractions into a growing, searchable library, and the failure-warning field means each reuse starts from where this breaks rather than from scratch. A good card format is why an organization's design knowledge accumulates instead of evaporating with the people who held it.

Its failure mode is over-abstraction into truism — a card that says something unfalsifiable ("prefer simplicity") looks wise and guides nothing, and a card without honest failure warnings invites confident misuse. The useful anchor is Christopher Alexander's pattern format, which pairs each principle with the context in which it applies and the forces it resolves^[1] — precisely the transfer-conditions and failure-warnings fields that keep a card from being a decontextualized slogan. The discipline is to reject any card whose statement can't be wrong and any card with an empty negative-case section.

How it implements the components¶

design_principle_abstraction — the card's core field: it converts the source analysis into reusable design knowledge, stated specifically enough to guide a design and testably enough to be falsified.
negative_case_comparison — the mandatory failure-warnings section records the conditions and known cases where the principle does not hold, so reuse begins from its boundaries.

It records the principle but does not extract the raw material that feeds it — the constraints (Constraint Laddering Interview), structure (Function-Behavior-Structure Matrix), or cross-source recurrence (Benchmark Deconstruction Grid) — nor does it map the principle onto a target (the Analogy Mapping Canvas).

Instantiates: Design-Principle Extraction and Reapplication — the card is the reusable-knowledge artifact the extraction produces.
Consumes: the analytic mechanisms (Constraint Laddering Interview, Function-Behavior-Structure Matrix, Benchmark Deconstruction Grid, Essential/Incidental Feature Sort) supply the analysis the card distills.
Sibling mechanisms: Analogy Mapping Canvas · Benchmark Deconstruction Grid · Biomimetic Translation Sheet · Constraint Laddering Interview · Essential/Incidental Feature Sort · Function-Behavior-Structure Matrix · IP and Provenance Checklist · Post-Transfer Boundary Review · Teardown Workshop · Transfer Prototype Experiment

References¶

[1] Christopher Alexander's pattern language records each design pattern as a context–problem(forces)–solution triple: the pattern is stated together with the situation in which it applies and the competing forces it resolves. The Design Principle Card's transfer-conditions and failure-warnings fields are the same discipline — a principle is never recorded without the boundary of where it holds. ↩