HTML Design Archetype Registry

Our recurring HTML output does not look the same because the color palettes are too similar. It looks the same because the same page skeleton is selected before the design problem is modeled.

Do not start with a hero, cards, or a dashboard shell. Start with the reader’s posture: read, learn, compare, decide, explore, or operate.

1. Outcome. What must the audience understand, decide, or do after using the artifact?
2. Posture. Is the dominant activity reading, learning, comparing, deciding, exploring, or operating?
3. Topology. Is the knowledge linear, hierarchical, networked, tabular, temporal, spatial, or procedural?
4. Evidence. Which claims, data, diagrams, alternatives, risks, and provenance must remain visible?
5. Context. What are the likely viewport, input, attention, connectivity, authorization, and accessibility conditions?
6. Lineage. Which public system has solved the nearest structural problem? Choose one primary influence and one supporting influence.
7. Distance. What must be materially different from the previous three artifacts?

Decision shortcut

type DesignGenome = {
  archetype:
    | "editorial-authority"
    | "public-trust"
    | "technical-precision"
    | "enterprise-operations"
    | "executive-decision"
    | "adaptive-learning"
    | "domain-workflow"
    | "knowledge-network"
    | "mobile-field-guide"
    | "narrative-persuasion";

  audience: string[];
  requiredOutcome: string;
  interactionPosture: "read" | "learn" | "compare" | "decide" | "explore" | "operate";
  informationTopology: "linear" | "hierarchical" | "hub-and-spoke" | "matrix" | "timeline" | "spatial" | "task-flow";
  primaryInfluence: string;
  supportingInfluence?: string;
  density: "airy" | "balanced" | "compact" | "dense";
  containment: "mostly-open" | "selective-panels" | "card-driven" | "workspace-regions";
  navigation: "minimal" | "document-outline" | "section-jump" | "sidebar-tree" | "tabs" | "task-steps" | "dashboard-filter";
  hierarchyExpression: "typographic" | "spatial" | "chromatic" | "container-based" | "data-driven";
  responsiveStrategy: "reflow" | "recompose" | "progressive-disclosure" | "mode-switch";
  evidenceModel: string[];
  prohibitedDefaults: string[];
  visualDistanceTarget: number; // 0–20, recommended >= 13
};

Required preflight output

Purpose

Why the artifact exists and the decision or task it must enable.

Audience

Who will use it and what each audience must understand, decide, or do.

Evidence

Claims, data, sources, diagrams, alternatives, and uncertainty that must remain visible.

Archetype

The selected communication architecture and why it fits better than the nearest alternative.

Lineage

One primary framework philosophy and one supporting influence.

Responsive strategy

How information will recompose for the smallest credible context.

Prohibited defaults

Patterns that must not be used unless independently justified.

Validation

Quality, function, evidence, accessibility, and visual-distance release criteria.

Alternative containment vocabulary

Rules, indentation, definition lists, side notes, tables, timelines, process rails, comparison columns, split panes, annotated figures, sticky contextual margins, numbered sequences, inline callouts, and expandable appendices.

Structural prototype requirement

For substantial artifacts, produce three unstyled candidate outlines from different archetypes. Select one. Do not produce three color themes for the same shell.

Interpretation: 0–8 indicates template reuse. 9–12 indicates partial adaptation. 13–16 indicates meaningful architectural variation. 17–20 indicates a strongly distinct mode.

Research
→ organize content
→ choose polished SPA shell
→ apply familiar components
→ audit spacing and accessibility

Research
→ identify audience outcome
→ model information relationships
→ select archetype
→ select primary lineage
→ define design genome
→ compare structural candidates
→ implement visual expression
→ validate invariants
→ validate visual distance

Normative implementation rules

MUST

Select and record an archetype before choosing a component shell.

MUST

Keep source evidence and conceptual relationships independent from presentation code.

MUST

Use semantic HTML and the simplest architecture that supports the intended task.

MUST

Define mobile recomposition, not merely column collapse.

MUST

Run the same artifact-quality scars during preflight and release.

SHOULD

Use one primary design lineage and no more than one supporting influence.

SHOULD

Produce structural alternatives before CSS for substantial or consequential artifacts.

SHOULD NOT

Use cards, pills, gradients, heroes, sticky regions, or disclosures without semantic justification.

MAY

Reuse a family shell when the artifacts intentionally belong to the same product or publication series.

{
  "archetype": "technical-precision",
  "audience": ["artifact authors", "design-system maintainers", "engineers"],
  "requiredOutcome": "Select a materially appropriate HTML architecture before implementation",
  "interactionPosture": "reference",
  "informationTopology": "hierarchical",
  "primaryInfluence": "Primer",
  "supportingInfluence": "Spectrum + USWDS",
  "density": "compact",
  "containment": "mostly-open",
  "navigation": "sidebar-tree",
  "hierarchyExpression": "typographic",
  "responsiveStrategy": "recompose",
  "prohibitedDefaults": ["hero-as-marketing", "card-grid", "rounded-section-shells", "decorative-gradients"],
  "visualDistanceTarget": 16
}

1. Apple Human Interface Guidelines
2. Material 3 canonical layouts
3. Microsoft Fluent 2 design principles
4. Adobe Spectrum principles
5. Adobe Spectrum platform scale
6. IBM Carbon overview
7. AWS Cloudscape foundation
8. AWS Cloudscape layout
9. GitHub Primer getting started
10. GitHub Primer layout
11. U.S. Web Design System principles
12. SAP Fiori design principles
13. Atlassian Design System foundations

Method

The framework guidance was normalized into six fields: problem class, dominant user posture, information topology, hierarchy mechanism, responsive adaptation, and transfer limits. The resulting archetypes are analytical constructs. They are not official categories published by the referenced companies.

Limitations

A registry can improve selection discipline but cannot replace user research, product-domain knowledge, content modeling, accessibility testing, or design review. Some artifacts intentionally belong to a consistent publication family; in those cases, reduced visual distance may be correct when documented.