Opening reference…
Rules for responsive controls, reachable targets, resilient input, bounded tasks, and recovery patterns that keep the interface trustworthy under real-world conditions.
4 principlesRules 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.
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.
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.
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:
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 — 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.
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.
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.
For reversible operations, prefer undo, retry, draft preservation, idempotency, and resumable jobs. When rollback is impossible, require stronger review before commitment.
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.
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