Matrix Table Layout

April 23, 2026 · View on GitHub

Layout: Labeled row × column matrix with selectively highlighted cells and a legend strip Best for: MxN classification grids where both axes carry meaning — task type × complexity, capability × tier, persona × journey stage

Template

Classification · MxN Matrix

Task Complexity vs Processing Depth

Cells are not just positions — they name the archetype that lives there. Highlighted cells mark the investments the program has already committed to.

Task ↓   /   Depth → P1 · Parse P2 · Retrieve P3 · Reason P4 · Generate
T1 · Cross-function Email triageIntake · shallow Case lookupRanked recall Root-cause briefFlagship Stakeholder memoFlagship
T2 · Multi-station Field extractionStructured Cross-source joinBounded Compliance checkGated Template renderControlled
T3 · Single-step Intent classify Knowledge lookup Rule match Short reply
Reading the Matrix Darker rows carry more coordination cost. The framed cells are the crown jewels — they need the strongest review, the largest models, and the tightest evaluation loop. Lighter cells can ship with lighter controls.
Program Map · Planning Artifact

Variations

  • Smaller grid: a 2x3 or 3x3 remains readable; beyond 4x5 the cells get too narrow to carry a named archetype.
  • Axis swap: put the heavier axis on rows when row labels need more room to breathe.
  • Tier banding: use t1 / t2 / t3 to shade whole rows or whole columns, not individual cells — the goal is to show gradient across the axis, not checkerboard noise.
  • Highlights sparingly: at most one-quarter of the cells should carry hl. Over-highlighting defeats the point.

When Not to Use

  • The axes are exactly two values each → use quadrant-matrix.
  • Only one axis has meaning; the other is a flat list → use comparison or badge-grid.
  • Cells carry long paragraphs, not short archetype names → use stacked-modules with subsection tables instead.