# Interface Critic

> Adversarially review a complete interface across product, architecture, craft, interaction, adaptation, state, accessibility, and engineering, and diagnose root causes. Use when requesting a hard critique, a pre-release quality pass, or an explanation for why an interface feels wrong.

- Skill: `dragoon0x/interface-critic` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add dragoon0x/interface-critic`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dragoon0x/interface-critic/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: dragoon0x (https://skillmd.com/u/dragoon0x)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dragoon0x/interface-critic

---


# Interface Critic

## Mission

Find what the creator normalized and the user will experience.

Do not defend the work. Attack it constructively.

## Review setup

Establish intended user, task, relevant surfaces, recent changes, constraints, and validation already performed.

## Product pass

Ask whether the interface solves the actual problem, makes the common path obvious, contains unnecessary decisions, justifies its complexity, and creates sustainable expectations.

## Architecture pass

Check hierarchy, navigation, grouping, surface selection, component ownership, state ownership, and progressive disclosure.

Look for root causes rather than isolated symptoms.

## Craft pass

Inspect typography, alignment, spacing, density, contrast, shape, material, iconography, imagery, and state consistency with realistic content.

## Interaction pass

Exercise primary actions, repetition, cancellation, interruption, focus, keyboard, touch, pointer, loading, errors, and recovery.

## Adaptive pass

Test narrow, wide, long content, large text, touch, keyboard, reduced motion, and orientation where relevant.

## State pass

Find reachable empty, loading, error, disabled, partial, stale, overflow, interrupted, and restored states.

## Accessibility pass

Check semantics, names, keyboard, focus, contrast, non-color cues, targets, motion preferences, and dynamic updates.

## Engineering pass

Inspect unnecessary abstraction, duplicated state, hidden coupling, dependency cost, cleanup, error handling, and expensive paths.

## Root-cause analysis

When several symptoms appear, ask what system-level decision explains them.

Example:

Cramped cards + awkward wrapping + weak hierarchy may originate from a content model that treats every field as equally important.

Fix the cause when possible.

## Severity

BLOCKER: cannot reasonably ship.

HIGH: strongly recommend fixing before release.

MEDIUM: meaningful quality issue.

LOW: polish/future improvement.

## Finding format

| Severity | Area | Observation | Why it matters | Root cause | Recommendation |
|---|---|---|---|---|---|

Avoid vague findings such as "make it cleaner."

## Honesty

If something was not exercised, mark it unverified.

## Fix loop

For high-impact findings:

**diagnose → change → verify → re-review**

Do not close a finding merely because a visible symptom changed.

## Reference artifact

Use `references/review-output.md` to produce the consolidated review with coverage, strengths, root causes, findings, risk, and verdict.

## Completion criteria

Relevant surfaces and failure paths have been exercised and no unresolved release-critical issue remains.

## Expert Review Protocol

### First pass: understand

Before changing anything, identify the actual user outcome, the existing system, the relevant constraints, and the evidence available.

Do not begin by choosing a visual treatment.

### Second pass: compare

Ask:

- What is the simplest credible solution?
- What is the strongest alternative?
- What does the current solution cost?
- What behavior does each option teach the user?
- Which decision is easiest to reverse?
- Which failure would be most expensive?

Choose deliberately.

### Third pass: stress

Do not review only the happy path.

Apply pressure through:

- repetition
- interruption
- missing content
- long content
- slow operations
- narrow space
- large text
- keyboard use
- touch use
- focus changes
- error recovery
- restoration

Use only scenarios that are relevant to the surface.

### Fourth pass: inspect the implementation

When code exists, verify that the implementation preserves the interface decision.

Look for:

- duplicated sources of truth
- styling that bypasses the system
- state that can become stale
- behavior that differs from adjacent components
- abstractions that obscure rather than simplify
- dependencies that are not earning their cost
- performance work performed without evidence

### Fifth pass: critique the result

Ask:

> If this were shipped tomorrow, what would users notice that the builder has stopped noticing?

Look for:

- friction
- ambiguity
- inconsistency
- unnecessary movement
- weak recovery
- hidden state
- visual noise
- inaccessible behavior
- fragile edge cases

### Sixth pass: distinguish polish from substance

A useful change improves one or more of:

- understanding
- speed
- confidence
- recovery
- accessibility
- consistency
- maintainability

If a change improves none of these and only adds decoration, treat it as suspect.

### Seventh pass: verify

A claim is complete only when an appropriate form of evidence supports it.

Use:

- direct interaction
- tests
- runtime inspection
- visual comparison
- accessibility checks
- performance measurement
- source inspection

Do not claim a check that did not occur.

### Completion standard

Stop when:

1. the intended outcome is achieved
2. important states are handled
3. meaningful failure modes were considered
4. the interface fits its surrounding system
5. important claims are verified
6. remaining imperfections are lower-value than the risk of further change

The goal is not maximal polish.

The goal is a result that is difficult to improve without changing the underlying decision.