Audit your UI before you redesign it: baseline first, then compare

We just spent two weeks improving six dashboard pages in our research system. The tempting move was to open each page, feel what was wrong, and start fixing. That approach produces exactly what you expect: pages that each look individually fine but feel like they were designed by six different people.
Instead, we ran an audit first. Here is the method and what it caught.

The method: baseline, compare, classify

Step 1: Extract a baseline. Pick two or three pages in your system that already feel right — not because they are beautiful, but because they are consistent. Write down every convention they share: segmented controls, button styles, icon usage, font sizes, color semantics, spacing.
In our case, three pages shared a set of conventions we hadn't written down anywhere:

• Segmented controls: gray track, pill-shaped, white floating active state
• Back buttons: shared icon component, gray hover state
• Icons: one shared icon library, no emoji
• Text buttons: link-style gray-to-accent on hover
• Loading: shared spinner component

Step 2: Compare every target page against the baseline. Not "does this look good?" but "does this match?" Each deviation gets written down as a specific, nameable difference.

Step 3: Classify each deviation. There are only two kinds:

• The page is wrong — it should adopt the baseline convention
• The baseline is wrong — the deviation reveals a better pattern that should be promoted to the system This classification prevents the two failure modes: inconsistency (everything is special) and rigidity (nothing can improve).

What the audit caught: 8 deviations in 6 pages

Deviation Fix
Square segmented controls Changed to gray-track pill with floating white active
Back button with red hover Changed to shared icon + gray hover
Three-line page headers Aligned to single-line pattern from reference page
Star icon in accent red Changed to neutral gray
Inline SVG chevron Changed to shared icon component
Outlined box button Changed to link-style text button
No loading indicator Added shared spinner
Inconsistent filter-clear hover Unified to same color token

None of these are dramatic individually. Together, they made six pages feel like six different products. After the audit, they feel like one system.

The color rule that fell out

One deviation taught us a principle worth keeping: a back button had red on hover. Red in UI means destructive — delete, danger, irreversible. A back button is none of those. Using red there trains users to hesitate on every red hover.
The rule we wrote down:
Accent red is reserved for numeric values and selected states. Icons and button hovers use neutral gray.

This is not a aesthetic preference. It is semantic hygiene: red should mean "pay attention to this number" or "you are here", never "this is clickable decoration".

The discipline part

After fixing, three things make it stick:

1. Shared components only. Icons go through one file. Buttons go through one component. No page-local SVGs or ad-hoc button styles.
2. Full verification after changes. TypeScript zero errors, all frontend tests pass, build succeeds, deployed chunk hash verified on both production ends.
3. When a new pattern is better, promote it to the baseline. The point is not stasis — it is that changes happen at the system level, not scattered across pages.

The connection to agent governance

If you have been following this series, you will see the pattern: this is the same method as the shadow-to-gate pipeline from the previous post. In both cases:

1. Measure before you change (shadow audit / UI baseline)
2. Fix the mechanism, not individual instances (citation rebuild / shared components)
3. Add a gate to prevent regression (citation gate / component-only rule) Whether you are governing agent output or UI consistency, the sequence is the same: baseline → compare → fix mechanism → gate.

Takeaway

If your multi-page application feels inconsistent, resist the urge to redesign page by page. Instead:

1. Write down the conventions your best pages already share
2. List every deviation in every other page
3. Fix deviations — or promote better patterns to the baseline
4. Enforce with shared components and full verification The audit itself took 30 minutes. The fixes took one afternoon. The result is six pages that feel like one system — something no amount of per-page tweaking had achieved.