# Interface Lab

> Turn a design uncertainty into a controlled comparison of materially different directions that produces a decision. Use when a consequential interface choice is genuinely unresolved and prototyping would reduce the risk of committing.

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

---


# Interface Lab

## Mission

Reduce expensive uncertainty before production commitment.

A prototype is an instrument for a decision, not a smaller final product.

## Experiment question

Start with one concrete question, such as which editing model reduces context switching or which navigation model improves orientation.

## Hypothesis

Use:

> If we use [direction], then [outcome] should improve because [reason].

## Decision axis

Choose the real variable: architecture, navigation, density, editing, feedback, automation, information hierarchy, or interaction model.

## Variants

Build a small number of materially different directions. Each needs name, hypothesis, advantage, cost, and failure risk.

Do not create variants that differ only by styling.

## Real context

Use realistic content, surrounding UI, states, density, and interaction. A variant that works only in isolation is weak evidence.

## Fidelity

Prototype the behavior that determines the decision. If navigation is being tested, make navigation real enough to judge. If editing is the question, make editing real enough to judge.

## Evaluation

Assess task clarity, interaction cost, discoverability, recovery, density, accessibility, responsive behavior, implementation complexity, and product fit.

## Evidence

Separate:

- OBSERVED: what happened
- PREFERENCE: personal taste
- INFERENCE: what observations suggest

Never present preference as evidence.

## Tradeoff record

| Direction | Wins | Costs | Risks | Evidence |
|---|---|---|---|---|

## Kill criteria

Discard directions that fail the core task, add disproportionate complexity, create serious accessibility problems, break context, or offer only cosmetic advantage.

## Decision

Record selected direction, evidence, rejected alternatives, and remaining uncertainty. Do not force a winner if evidence is genuinely inconclusive.

## Promotion

Translate prototype behavior into production architecture, replace hacks, integrate real components, rerun acceptance criteria, and remove experiment-only code.

## Reference artifact

Use `references/experiment-report.md` to structure the question, variants, evaluation criteria, evidence, and decision for an experiment.

## Completion criteria

The experiment is complete when it reduces the targeted uncertainty enough to justify, reject, or defer a production decision.

## 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.