Integrity Console Design System

Tokens

One name per surface, state and colour

Primitives

Button, badge, input, table

Surfaces

Inbox, dashboard, reports

Compositions

12, assembled at real scale

Two artefacts, one product

The Support Agent Dashboard shipped as a 25-screen clickthrough: vanilla HTML, CSS and JavaScript, no framework, no build step. Right shape for proving an interaction, wrong shape for handing to engineering, since a prototype has no components in it. It has markup that happens to look like components.

This is the other half: the same product expressed as a library.

The system

Base UI primitives, Tailwind v4, shadcn conventions, typeset in Geist. 40 components across four groups, plus 12 page compositions that assemble them at real scale.

Primitives, at the token level

Two reds, one meaning each. --primary (#c70036) carries every primary action. --red-deep (#b20030) is reserved for the inbox Close button and the live-attempt badge, and nothing else. A single --red would have blurred two meanings into one swatch, and they'd have drifted apart in code anyway.

Inbox

One elevation, everywhere. The content card is the only shadowed surface on a page; nested blocks get --surface-nested and a hairline border, never a second shadow.

Dashboard and reports

Role colour is semantic, not decorative. Student, instructor and admin each own a background/foreground pair, and the same three hues carry the chart series: an orange line on the Overview chart means the same thing an orange badge means in the Inbox.

The token layer is the actual deliverable

The prototype already had a disciplined tokens.css: surfaces, chat row states, a series palette for charts. Rather than redraw those decisions in Tailwind's vocabulary, the rebuild promotes them into a @theme layer under the same names, so a value never means one thing in the clickthrough and another in the React build.

:root {
  --primary: #c70036; /* the one red that means "primary action" */
  --background: #efeceb; /* app ground: cards float on it, no dividers */
  --surface-nested: #f8f7f6; /* tiles and chart wells inside a white card */
  --sel: #dbd3d1; /* selected chip, filter pill, received bubble */
 
  /* Inbox rows carry their own scale, because "unread" has to read as
     lighter than the ground while "read" reads as a step darker. */
  --unread: #fdfcfc;
  --chat-read: #e6e1e0;
}

Role pairs

Student, instructor and admin each own a background/foreground pair. The chart series reuse the same hues, so a colour carries one meaning across the whole product rather than one meaning per view.

Status

Inbox row states

The one place the palette gets fussy, because three states have to be distinguishable at a glance down a long list. Unread reads lighter than the ground; read reads a step darker; selected gets its own warm grey rather than borrowing --sel.

Type

Geist Variable throughout: --font-heading is an alias of --font-sans, not a second family. Headings differentiate by weight and size against Tailwind's default scale; there is no bespoke scale to memorise.

Radius

One base, everything else derived. Changing --radius reshapes the product.

--radius: 0.75rem; /* lg */
--radius-sm: calc(var(--radius) * 0.6);
--radius-md: calc(var(--radius) * 0.8);
--radius-xl: calc(var(--radius) * 1.4);
--radius-2xl: calc(var(--radius) * 1.8);

Elevation

--shadow-card: 0 0 4px rgba(0, 0, 0, 0.15);

That is the entire elevation system. The content card is the only shadowed surface on a page; anything nested inside it uses --surface-nested with a hairline border. A second shadow is a bug.

What I'd do next

• Wire Code Connect so the Figma components point at these implementations rather than at a description of them.
• Publish the report views as a template, since seven of the eight are the same layout with a different metric.