krt-interface-warden

The goal is an interface composed for its specific content and task, so it reads as a dossier, logbook, or control table for this domain rather than a pile of widgets that could belong to any startup. The left-to-right default (sidebar, header, a row of identical KPI cards, a table, everything boxed with border plus shadow) is what models produce unprompted and what users call "generic". Identity should come from content and composition, not from decoration.

The same doctrine serves two modes: design (build or redesign) and critique (audit and hand off). Operability always wins over distinctiveness: never trade away the primary task, required states, accessibility, or established product mechanics for a look.

The doctrine

Lead with one thing. Decide what the user's task is and which single element (a figure, a decision, a queue, a work zone) should dominate. Give it type size, position, and space. Everything else is quieter. Equal visual weight for every module is the most common failure.

Pick a surface metaphor that fits the work, and let the layout follow it:

• Dossier: reviewing one entity, case, claim, or record.
• Map: relationships, dependencies, flows, topology.
• Logbook: events, history, incidents, audit trails.
• Control table: monitoring queues, workloads, live states.
• Workshop: creating, editing, configuring.
• Archive: searching, filtering, comparing many records.
• Report: findings, evidence, recommendations.