---
title: "Interaction, Performance & Error Tolerance"
source: "/reference/interaction-performance-error-tolerance"
description: "Rules for responsive controls, reachable targets, resilient input, bounded tasks, and recovery patterns that keep the interface trustworthy under real-world conditions."
---
# Interaction, Performance & Error Tolerance

Rules for responsive controls, reachable targets, resilient input, bounded tasks, and recovery patterns that keep the interface trustworthy under real-world conditions.

> Rules for responsive controls, reachable targets, resilient input, bounded tasks, and recovery patterns that keep the interface trustworthy under real-world conditions.

Interaction quality is experienced through a continuous loop: act, receive feedback, understand state, continue. Break that loop and users hesitate, repeat actions, lose context, or make mistakes. The relevant design surface includes target geometry, latency, validation, parsing, progress, state durability, and recovery.

Layr should evaluate this category with concrete evidence wherever possible. Target sizes can be measured. Response times can be traced. Validation rules can be inspected. Duplicate requests can be detected. Error states can be exercised. This makes interaction review one of the strongest opportunities for high-confidence agent findings.

Error tolerance deserves special treatment. A resilient interface accepts harmless variation, prevents serious mistakes where possible, and gives users a path back when prevention fails. Leniency must remain bounded by security, ambiguity, financial consequence, and data integrity.

## Principles in this category

- [Doherty Threshold](/__layr/pages/reference/doherty-threshold.md) — Interaction feels fluid when feedback arrives quickly enough that users can maintain a continuous task rhythm.
- [Fitts's Law](/__layr/pages/reference/fitts-law.md) — Acquiring a target generally becomes easier as the target grows and as the required pointer travel decreases.
- [Postel's Law](/__layr/pages/reference/postels-law.md) — Interfaces benefit when they accept reasonable variation in user input while producing clear, predictable output.
- [Parkinson's Law](/__layr/pages/reference/parkinsons-law.md) — Work tends to expand to fill the time or space available; in product design, loose task boundaries can encourage unnecessary effort.

## Category model

Interaction design is a control loop. The user acts, the system acknowledges the action, work occurs, state changes, and the interface communicates what happened. Reliability depends on every link in that loop. A visually elegant control can still be poor interaction design when the hit target is hard to acquire, feedback is delayed, duplicate actions are possible, or failure leaves no recovery path.

Layr should prefer measurable evidence in this category. Geometry, timing, request state, validation logic, retry behavior, idempotency, and job durability can often be inspected directly. These are valuable because they allow the agent to issue high-confidence findings with concrete fixes instead of subjective recommendations.

### Agent evidence hierarchy

Prefer runtime behavior and code-path evidence over screenshot inference. For latency, distinguish acknowledgement from completion. For errors, distinguish prevention, detection, explanation, and recovery. For tolerant input, distinguish harmless syntactic variation from ambiguous or risky semantic variation.

## Category review questions

- Does every user action receive feedback quickly enough to prevent uncertainty or duplicate input?
- Are important controls easy to acquire with the relevant input methods?
- Can benign input variation be normalized safely instead of rejected mechanically?
- Are consequential errors preventable, reviewable, reversible, or recoverable?
- Does a task have a clear completion boundary, especially during setup and long-running work?

## How agents should use this file

Treat these rules as review criteria, not as automatic violations. A finding is valid only when the interface provides observable evidence that the principle applies and that the current implementation creates a meaningful usability, comprehension, accessibility, or interaction cost.

For every finding:

1. Identify the exact component, state, route, or interaction.
2. State the observable evidence.
3. Name the principle that applies.
4. Explain the user consequence in the current context.
5. Estimate severity from the consequence, frequency, and reversibility.
6. Recommend the smallest change that addresses the issue while preserving the product's existing design system.
7. Lower confidence when intent, frequency, audience, device, or product constraints must be inferred.
8. Do not produce generic advice such as "improve hierarchy" or "make this clearer" without specifying what is wrong and why.

### Finding contract

```yaml
finding:
  rule_id: string
  location: string
  evidence:
    - observable fact
  impact: string
  severity: low | medium | high | critical
  confidence: low | medium | high
  recommendation:
    change: string
    rationale: string
    preserve:
      - existing design-system behavior
      - valid product constraints
```

A clean interface can legitimately produce zero findings.

## Agent routing hints

Route a review here when evidence is measurable in interaction behavior: latency, target geometry, validation, parsing, task completion, duplicate actions, failed input, or recovery. Prefer instrumented evidence over aesthetic judgment.

## Error-tolerance application layer

Error tolerance is a cross-rule review lens rather than a new psychological law in this collection. Use it together with Postel's Law, Tesler's Law, working-memory guidance, and accessibility requirements.

### Error-tolerance review model

An error-tolerant product assumes that users, networks, integrations, and background jobs will fail in ordinary ways. The design goal is to keep those failures bounded. Layr should inspect the full lifecycle:

1. **Prevention:** Can an impossible or dangerous action be prevented before submission?
2. **Early detection:** Can the system detect invalid state close to where it is created?
3. **Specific explanation:** Does the error identify the object, field, record, or constraint involved?
4. **State preservation:** Does valid work survive the failure?
5. **Recovery:** Can the user retry, undo, edit, resume, or isolate the failed part?
6. **Verification:** After recovery, can the user confirm what succeeded and what remains unresolved?

A strong error experience reduces the amount of rework after failure. A weak one discards context, collapses several causes into a generic message, or forces the user to restart an otherwise valid task.

#### High-value agent checks

- Forms preserve valid values after server-side rejection.
- Bulk operations report partial success instead of returning one undifferentiated failure when isolation is safe.
- Retried mutations are idempotent where duplicate execution would be harmful.
- Destructive actions name the exact object and scope before commitment.
- Long-running jobs can resume or be inspected after navigation, refresh, or connection loss.
- Error messages expose a next action rather than only a cause.
- Recovery controls remain available after the original transient notification disappears.

#### Example finding

> **High — A single malformed CSV row fails the entire import and discards validated work.** The backend can identify the failing row, but the UI returns one generic error and requires a full restart. Preserve accepted rows, isolate invalid records, show row-level reasons, and allow retry of only the failed subset.

### Prevention

Prefer preventing predictable, high-cost mistakes before submission. Examples include disabling impossible date ranges, validating incompatible configuration, warning before destructive scope changes, and showing the exact resource that will be affected.

### Detection

When an error occurs, identify the specific field, record, object, or action. A generic banner such as `Something went wrong` is insufficient when the system can provide a useful recovery path.

### Recovery

For reversible operations, prefer undo, retry, draft preservation, idempotency, and resumable jobs. When rollback is impossible, require stronger review before commitment.

### Batch resilience

For imports and bulk actions, isolate bad records when safe instead of failing an entire batch. Report what succeeded, what failed, why it failed, and what the user can retry.

### Accessibility baseline

For web interfaces, review error behavior against WCAG 2.2 Input Assistance. Current guidance includes identifying detected errors in text, providing labels or instructions, offering correction suggestions when known, and adding prevention mechanisms for consequential submissions.

Reference: [W3C WCAG 2.2 — Input Assistance](https://www.w3.org/WAI/WCAG22/Understanding/input-assistance)

---