UX Invariants for AI-powered Software Engineering
Build faster with AI, without breaking UX fundamentals.
A framework-agnostic set of enforceable UX invariants that constrain LLM behavior and prevent usability regressions in AI-generated user interfaces.
Observed Failure Modes in LLM-Generated Interfaces
LLMs can generate functional UI code in seconds. They also reliably:
- Break interaction consistency
- Ignore accessibility edge cases
- Introduce silent UX regressions
- Optimize for syntax rather than human behavior
Speed without guardrails compounds UX debt.
UX Invariants as Guardrails
UX Invariants are non-negotiable rules that tell AI coding agents what must stay true when they generate UI code, regardless of framework or platform.
- Generation-time guardrails for AI coding agents
- Clear, universal UX acceptance criteria the agent must meet
- Lightweight governance to compliment any design system
This is UX as infrastructure for AI-built products.
What You Get
A curated, production-ready set of UX invariants expressed in plain Markdown, designed for direct use in AI-assisted workflows.
Copy the Markdown into AGENTS.md, CLAUDE.md or system prompts, then instruct agents to validate their output against the invariants before you merge or ship.
Includes invariants covering:
- Core interaction patterns
- Accessibility baselines and affordances
- Error handling and recovery
Each invariant includes:
- Rule
- Rationale
- Implementation guidance
- Common violations to avoid
Where it fits:
- System prompts
- Agent instructions (AGENTS.md, etc…)
- Human review rubrics and QA checklists
- Pre-merge agent self-checks
No tooling lock-in. No proprietary formats.
What’s Covered
**Category**: Input
Input controls must match the data type being collected so the browser, OS, and assistive tech can help the user enter it correctly.
## Invariant
Use the most specific, semantically correct input type (and related attributes) for the data expected, instead of a generic text field.
**Example**: Use `type="email"` for email, `type="tel"` for phone numbers, and `type="number"` with min/max/step for numeric values in browser-based apps.
## Applies When
Any form or flow that collects structured data with known formats or constraints.
**Example**: Signup, checkout, profile settings, billing, or scheduling fields.
## Why This Exists
Correct input types unlock native keyboards, validation, autofill, and accessibility semantics, reducing errors and friction.
**Example**: Email keyboards expose `@`, numeric keyboards reduce typos, and screen readers announce expected input.
## AVOID: Common Violations
Using generic text inputs when a specific type or control exists.
**Example**:
- `type="text"` for email, phone, or number fields
- Freeform text for dates instead of a date input or picker
- Numeric inputs without min/max/step or units, leading to ambiguous values
**Category**: Navigation
Navigation elements must use consistent icons and labels so the same destination or action is always recognizable.
## Invariant
Icons and labels used for navigation must be clear, unambiguous, and consistent across the product, and the same destination or action must not be represented by different icon/label combinations.
**Example**: The "Settings" destination always uses the same gear icon and "Settings" label in the sidebar, header menu, and mobile nav.
## Applies When
Any time navigation choices are presented, including global nav, sidebars, menus, tabs, breadcrumbs, toolbars, and in-context navigation links.
**Example**: A list view's tab bar, a product's left nav, and the account dropdown.
## Why This Exists
Consistent iconography and labeling reduce cognitive load, prevent misnavigation, and help users build a reliable mental model of where things live.
**Example**: Reusing the same icon/label for "Reports" helps users find it quickly without re-learning the UI.
## AVOID: Common Violations
Mix icons or labels for the same destination, or use ambiguous icon-only navigation without supporting text or tooltip.
**Example**:
- Using a star icon for "Favorites" in one area and a heart icon in another
- Labeling the same destination as "Projects" in the sidebar and "Workspaces" in the header
- Icon-only nav with no label or tooltip to clarify meaning
**Category**: Feedback
When submission fails validation, the interface must guide the user to the first invalid field immediately.
## Invariant
On submit attempts, the first invalid input is clearly highlighted and brought into focus so the user can correct it without hunting.
**Example**: After clicking Submit, focus moves to the first invalid field and its error is visible.
## Applies When
Any form or data entry flow where a submit/save/continue action can be blocked by validation errors.
**Example**: A checkout form, signup flow, or settings save can fail due to validation errors.
## Why This Exists
Users should never have to guess why a submit failed. Guiding them to the first error reduces confusion, speeds recovery, and prevents abandonment.
**Example**: Users lose confidence when a submit fails without guidance, so we lead them to the first fix.
## AVOID: Common Violations
The submission fails but the user is left to find errors manually.
**Example**:
- Error messages only appear at the top of the page with no field focus
- Inline errors are shown, but focus stays on the submit button
- Multiple fields fail, but nothing indicates which one is first
**Category**: Accessibility
Every interactive element must be focusable and fully operable with a keyboard alone.
## Invariant
All interactive elements (links, buttons, inputs, toggles, menus, dialogs, custom controls) must be reachable via a logical keyboard focus order and be fully operable using standard keyboard interactions without requiring a pointer.
**Example**: A custom dropdown opens with Enter/Space, navigates options with Arrow keys, and confirms with Enter.
## Applies When
Any time a user can take an action or change state in the UI, including custom components, modals, overlays, and in-context controls.
**Example**: A table row action menu, a date picker, and a drag-and-drop alternative action.
## Why This Exists
Keyboard access is essential for users who cannot use a mouse, supports assistive technologies, and is a baseline accessibility requirement for compliance and usability.
**Example**: Users navigating via switch control rely on predictable keyboard focus and activation.
## AVOID: Common Violations
Controls that are not focusable, not visible in the tab order, or require mouse-only interactions to complete.
**Example**:
- Click-only icons or div-based buttons without keyboard handlers
- Custom dropdowns that trap focus or cannot be opened with Enter/Space
- Drag-and-drop flows with no keyboard alternative
**Category**: Destructive Actions
Irreversible actions must require an explicit confirmation step.
## Invariant
Irreversible actions must require an explicit confirmation step.
**Example**: Deleting an account requires a confirmation dialog with clear consequences.
## Applies When
An action permanently deletes or irreversibly alters user data.
**Example**: Removing a workspace, deleting a project, or revoking access cannot be undone.
## Why This Exists
Users make accidental clicks under stress. Irreversible loss breaks trust.
**Example**: A single misclick should not erase data, so we require explicit confirmation.
## AVOID: Common Violations
Single-click destructive actions with no confirmation step.
**Example**:
- Single-click delete buttons
- Confirmation via toast only
Install the Samples
Not Another Prompt Pack
Prompt packs help you talk to AI. UX Invariants control what AI ships.
UX Invariants vs Prompt Packs
Prompt packs optimize how you ask. UX Invariants define what must be true.
Prompt packs:
- Are brittle and context-dependent
- Drift as prompts evolve
- Encode instruction, not outcome
UX Invariants:
- Persist across prompts and agents
- Define non-negotiable outcomes
- Improve results regardless of prompt quality
UX Invariants vs Design Systems
Design systems define components. UX Invariants define behavior.
Design systems:
- Are framework- and brand-specific
- Assume human implementation
- Break down under AI-generated code
UX Invariants:
- Are framework-agnostic
- Apply before components exist
- Constrain AI behavior directly
They complement design systems, they don’t replace them.
Why Not Just Ask an AI to Generate UX Rules?
You can. You’ll likely get a plausible-sounding list of guidelines, many of them vague, conflicting, unenforceable, or subtly harmful in production.
UX Invariants are distilled from repeated failure, enforced tradeoffs, and long feedback loops across real systems.
The value isn’t the wording. It’s the judgment behind what’s included, what’s constrained, and what’s deliberately left out.
AI can generate rules. It can’t reliably tell you which ones survived contact with reality.
Who It’s For
- Solopreneurs shipping AI-generated UI without a design team
- Technical founders balancing speed and product quality
- Senior engineers responsible for long-term UX integrity
If you use LLMs to build user interfaces, these invariants are for you.
About the Author
Authored by a staff frontend engineer with over 20 years of experience designing, building, and maintaining production user interfaces.
These UX invariants are distilled from real failure modes encountered across decades of UI development, now amplified by AI-generated code.
Decades of UI/UX experience, distilled into guardrails your agents will follow.
Licensing & Pricing
UX Invariants are licensed, not subscribed to.
- One-time purchase
- Stable, platform-agnostic rule set
- Intended for production systems
- Individual, team, and organization licenses
Buy once, bake the rules into every build.
Save review time, prevent UX regressions, align multiple contributors, and reduce rework from AI-generated code.
Get the UX Invariants →