ux-antipatterns

name	ux-antipatterns
description	Use when reviewing, building, or refactoring frontend UI — components, pages, forms, or interactive flows. Triggers on code review, pull requests, and new feature implementation involving user-facing interfaces.

UX Anti-Pattern Detection

Scan frontend code for patterns that cause user frustration.

Core Axioms

Before checking individual rules, internalize these. They are the "why" behind every item below.

#	Axiom	One-liner
1	Acknowledge every action	Every user action must produce visible feedback within 100ms, even if the result takes seconds.
2	Never destroy user input	Not on error, not on navigation, not on timeout, not on refresh.
3	State survives the unexpected	Refresh, double-clicks or double submits, network loss — code must handle edge cases.
4	Most recent intent wins	Stale responses must never overwrite a newer user action.
5	Explain every constraint	If it's disabled, say why. If it failed, say how to fix it. If it succeeded, say what happened.
6	Don't fight the platform	Browser conventions, OS gestures, native controls, and accessibility APIs encode billions of hours of UX research.

When NOT to Use

• Backend-only code with no UI layer
• CLI tools or non-visual interfaces
• Design system tokens/docs without implementation code
• Pure API or data-layer reviews
• Performance profiling (unless it manifests as a UX symptom like layout shift)