Skip to main content

Great Interface Design Standard

What makes an interface ready to release?

Great interface design makes the next useful action obvious and the supporting information effortless to read. It is not decoration, novelty, or a contrast score in isolation.

The Interface Design Manifesto states the public commitments behind this operational gate.

Use these five gates before implementation, during iteration, and before release. A page does not pass by averaging the gates. One failed gate blocks release.

PURPOSE -> HIERARCHY -> READABILITY -> COHERENCE -> PROOF

Five-Gate Checklist​

1. Purpose​

  • Name the audience, situation, desired outcome, and primary action in one sentence.
  • Start with the feature, decision, or task—not a decorative layout.
  • Give the page one dominant focal point and one primary action.
  • Remove any section or effect that does not improve comprehension, confidence, or action.
  • Choose a visual character that fits the subject; do not inherit a fashionable style by default.

Pass test: a first-time reader can say what the page is for and what to do next after a five-second glance.

Failure signals: several competing calls to action, a hero that communicates mood before meaning, or content forced into cards because cards were chosen first.

2. Hierarchy​

  • Rank every element as primary, secondary, or supporting before styling it.
  • Build hierarchy with a deliberate combination of size, weight, contrast, colour, and space—not size alone.
  • Make the primary message visibly dominant; keep one hero line and one support line where the format permits.
  • De-emphasise supporting information without making it hard to read.
  • Group related elements by proximity; use more space between different ideas than within one idea.
  • Eliminate unnecessary labels and borders. Prefer position, spacing, background, or type treatment when they communicate the same structure.
  • Keep visual hierarchy separate from semantic heading order: both must be correct.

Pass test: blur or squint at the page. The intended reading order remains obvious without reading the words.

Failure signals: everything has equal visual weight, every item is boxed, accent colours compete, or metadata attracts more attention than body content.

3. Readability​

  • Default body text is at least 16px; use 18–20px for long-form or spacious editorial reading when the typeface supports it.
  • Captions and secondary prose are at least 14px. Reserve 12px for short, genuinely peripheral labels—not repeated reading or navigation.
  • Body line-height is normally 1.45–1.7; headings use tighter but non-colliding leading.
  • Maintain prose measure near 45–75 characters per line; target roughly 60–70 for sustained reading.
  • Align multi-line Latin-script prose left. Reserve centred type for short, self-contained statements.
  • Reserve uppercase, mono type, italics, and wide letter spacing for rare structural emphasis; never combine them as the default treatment for frequent small text.
  • Every text/background pair reaches WCAG AA: 4.5:1 for normal text and 3:1 for large text. Important UI boundaries and focus indicators reach 3:1.
  • Do not create muted text with opacity. Use a measured solid colour, and judge comfort in the rendered page—not only the ratio.
  • Image- or gradient-backed text has a stable contrast treatment across the entire text area.
  • Text zoom, browser zoom, and user font preferences do not hide content or actions.

Pass test: read two full paragraphs on the smallest supported viewport at normal zoom. No squinting, refocusing, or hunting is required.

Failure signals: the design repeatedly sits on the minimum type floor, passes contrast mathematically but still looks faint, uses long dense lines, or treats metadata styling as body typography.

4. Coherence​

  • Define a small type scale, spacing scale, colour roles, radii, and elevation model before polishing components.
  • Use spacing tokens with a clear rhythm. Avoid arbitrary one-off values unless the exception is documented.
  • Assign each colour one semantic role and pair colour with text, shape, position, or iconography.
  • Apply shadows to explain elevation and borders to explain boundaries; do not use either as ambient decoration.
  • Reuse established components and interaction patterns. A repeated pattern behaves the same everywhere.
  • Prefer strong real references over adjective-heavy direction. Capture the whole reference page so section pacing and hierarchy are visible, not only the hero.
  • Record goal, format, layout, typography, colour, constraints, and acceptance checks in the design spec.
  • Generate meaningful variants within one system; do not reroll the whole design. Change one or two variables per iteration.

Pass test: another designer or agent can extend the page without inventing a new visual grammar.

Failure signals: near-duplicate colours, arbitrary spacing, several shadow styles, inconsistent controls, or a prompt made mostly of mood words.

5. Proof​

  • Render at 320px, 375px, a tablet width, and at least one desktop width.
  • Capture full-page screenshots so hierarchy, density, and section rhythm can be compared.
  • Verify computed font sizes, colours, backgrounds, line-height, overflow, and touch-target sizes in the browser.
  • Find no clipped text, accidental horizontal scroll, orphaned headings, collision, or layout-dependent reading-order error.
  • Confirm keyboard navigation, visible focus, semantic headings, landmarks, labels, and 44px minimum touch targets.
  • Exercise hover, focus, active, disabled, loading, empty, error, and success states that the interface can enter.
  • Test reduced motion, high zoom, long real content, and both light/dark bands when present.
  • Ask one unfamiliar person to identify the page purpose, primary action, and reading order without coaching.
  • Compare the render with its chosen references and written acceptance criteria. Record intentional differences.

Pass test: the release evidence contains viewport captures, computed-value checks, interaction-state checks, and one human comprehension check.

Failure signals: approval from source code or Figma alone, desktop-only screenshots, a hero-only capture, or “looks good to me” without acceptance evidence.

90-Second Preflight​

Use this shortened gate for every interface change:

  1. Purpose: can I name the one job and one primary action?
  2. Hierarchy: does the first glance land on the most important thing?
  3. Readability: is frequent text comfortably sized, spaced, measured, and contrasted?
  4. Coherence: did I reuse a system and change no more than two variables?
  5. Proof: did I inspect the rendered interface at mobile and desktop, with real states and content?

Any “no” returns the work to that gate.

Review Receipt​

Attach this receipt to a design PR or review:

Page job:
Primary action:
First-glance focal point:
Body / secondary / label sizes:
Longest prose measure:
Lowest text contrast pair:
Viewport evidence:
Interaction states checked:
Reference captures:
Human comprehension result:
Known variance and owner:

Control Loop​

Interface QA is a feedback loop, not a folder of screenshots:

dogfood → log evidence → classify recurrence → approve standard
→ bind control → verify release → track recurrence

Classify findings as purpose, hierarchy, layout, typography, color, component, motion, accessibility, or robustness. Give repeated observable failures one stable, lower-kebab-case mistake type so recurrence can be counted across routes and components.

  • Correct and record the first occurrence.
  • The second occurrence before a durable control creates a Design Standard Card candidate.
  • Only named human authority activates or revises a durable standard.
  • A recurrence after activation means the control failed. Check the wording, prompt injection, component default, and review execution instead of writing another duplicate rule.
  • Critical and high findings block release until fixed or resolved by named human authority.

Each Design Standard Card names the beneficiary and intent, scope, testable requirement, evidence method, failure condition, prompt snippet, component/default control, exceptions, owner, lifecycle, and effective date. Delivery ledgers may remain private; reusable interface teaching belongs here and operative implementation defaults belong in src/components/DESIGN.md.

Every release receipt ends READY, HOLD, or STOP and includes a non-author review of purpose, hierarchy, readability, coherence, accessibility/robustness, and motion.

Wisdom Dogfood​

The Wisdom page shows why numeric floors are not targets. Its page-local design memory requires body text >=16px, captions >=14px, and labels >=12px, but the implementation repeatedly renders structural labels at 0.75rem and several supporting controls around 0.76–0.85rem. The colour pairs may pass AA while the overall experience still feels small and delicate.

Apply this standard before aesthetic refinement:

  1. promote frequent instructional and interactive text to at least the caption tier;
  2. reserve 12px mono uppercase for rare peripheral markers;
  3. re-check hierarchy without colour and without reading the copy;
  4. capture the entire page at 320, 375, tablet, and desktop widths;
  5. treat the result as failed until a reader can identify the argument and next action without effort.

This is a standards diagnosis, not a mandate to enlarge every token. Importance and reading frequency decide the tier.

Failure Modes​

  • A team averages the five gates and releases despite one blocking failure.
  • Screenshots exist, but computed values, interaction states, or human comprehension remain unknown.
  • A repeated mistake produces another note instead of a candidate standard or control-failure review.
  • An agent activates a durable standard without named human authority.

Proof Of Done​

The method is complete when the release receipt cites all four viewport captures, computed values, interaction evidence, and a non-author reading; every critical or high finding is resolved; and the verdict is READY. The ledger validator must also classify recurrence without broken references.

Action Ladder​

  1. Do it now: run the preflight, log findings, and attach a release receipt.
  2. Do it with guidance: use the Journey diagnostic to bound one interface improvement and its proof.
  3. Vote to build: record demand when automatic standard-card injection needs platform support.

Changes my mind: repeated independent reviews show that a simpler taxonomy or fewer gates predicts release failures with equal accuracy without weakening accessibility, human authority, or evidence.

Retrieval​

Pull this method before implementation, material interface review, or release verification.

Version delta: the 2026-07-30 revision added stable finding taxonomy, recurrence classification, human activation authority, Design Standard Cards, prompt binding, and typed release verdicts.

Source Basis​

Context​

Questions​

  • Which mistake has now occurred twice?
  • Which active control failed after its effective date?
  • Which remaining variance needs human judgment rather than another automated rule?
  • What makes an interface ready to release once recurrence and control failure are visible?

Next question: which recurring interface mistake should become the next human-approved component default?