UX Patterns Guide
Back to compare picker

Disabled controls without recovery vs Disabled button with no explanation vs Inline validation vs Error summary vs Permission recovery vs Fallback path

Choose error summary when a submitted form returns multiple linked errors and users need top-of-page recovery navigation across fields.

Disabled controls without recovery live exampleDisabled button with no explanation live exampleInline validation live exampleError summary live examplePermission recovery live exampleFallback path live example
Learn the decision

Match the interaction to the person's task

Choose error summary when a submitted form returns multiple linked errors and users need top-of-page recovery navigation across fields.

Disabled controls without recovery

Use it when: Auditing disabled primary actions, toolbar commands, menu items, toggles, form controls, checkout actions, invite flows, publish controls, exports, destructive actions, and workflow steps.

Make this state clear: Prerequisite map state that shows each requirement and whether it is met.

Observe the result: A user sees which prerequisites are complete, opens billing setup for the missing prerequisite, saves the invite draft, requests owner approval, and returns to send once eligibility changes.

Study the full pattern →

Disabled button with no explanation

Use it when: Use this anti-pattern entry to audit disabled submit, continue, create, save, delete, publish, invite, export, payment, and setup actions.

Make this state clear: Unavailable action state with visible reason and affected requirement.

Observe the result: Users can satisfy requirements one by one and see the action become available, or submit and receive actionable validation.

Study the full pattern →

Inline validation

Use it when: A single field has a specific correctable problem.

Make this state clear: Invalid field with preserved user value and adjacent correction text.

Observe the result: Validation appears after blur or submit when it helps correction.

Study the full pattern →

Error summary

Use it when: Form submission can produce one or more errors.

Make this state clear: Failed-submit state with summary visible near the form heading.

Observe the result: After failed submit, focus or reading order makes the summary discoverable before users scan the form.

Study the full pattern →

Permission recovery

Use it when: A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue.

Make this state clear: Recovery start state with original blocked task and current account.

Observe the result: A user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report.

Study the full pattern →

Fallback path

Use it when: A primary lookup, verification, upload, payment, search, device feature, online-only step, or channel can fail while the user still needs to finish.

Make this state clear: Primary path available state.

Observe the result: The person reaches a clear outcome.

Study the full pattern →

Practice the judgment: Imagine this situation: A person reaches a result and needs a clear route to continue. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension Disabled controls without recoveryDisabled button with no explanationInline validationError summaryPermission recoveryFallback path
UI or UX UI + UX - Blocked-control anti-patternUI + UX - Blocked action anti-patternUI + UX - Field-level validation feedbackUI + UX - Form recovery summaryUI + UX - Guided workflow for regaining or routing around missing accessUI + UX - User-directed alternate route when the primary path cannot complete
UI guidance Prefer enabled validation, request access, retry after state change, save draft, sign-in recovery, dependency setup, contact owner, or fallback actions over inert controls with hidden causes.Replace a lone greyed-out action with visible requirement text, a checklist, permission message, or enabled validation submit that tells users what blocks progress.Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.Show a recovery workspace after denial with the current account, current role, requested role, safe owner or admin destination, request reason, policy limits, status timeline, and original blocked task.Place the alternate route beside the blocked primary path with a label that names what changes, such as Enter address manually, Use cached report, Call support with reference, or Continue with paper evidence.
UX guidance Model disabled controls as a lifecycle: unavailable with cause, recoverable, pending, available, processing, completed, or honestly stopped.Help users understand whether the block is missing input, invalid data, permission, quota, dependency, safety policy, or temporary processing.Help the person reach a clear task outcome.Move users from the summary to the exact field, group, or first invalid control that needs correction.Use permission recovery when users can take a concrete step to regain access, use another identity, request a different role, escalate a policy block, or continue with a safe fallback after an authorization denial.Use a fallback path when the primary route is unavailable, unsuitable, unsupported, or repeatedly failing, and users still need a credible way to complete the task.
Good UI An Invite teammate panel shows missing billing setup, owner approval, and team domain checks, with Open billing, Request owner approval, Save draft, and Contact admin actions.Create workspace is paired with visible requirements: enter a workspace name, accept billing terms, and request owner access.Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.Top-of-form summary with a clear heading, linked error list, and matching inline field messages.A restricted report recovery panel shows alex@northwind.example lacks Finance viewer access, lets the user request Viewer or Editor with a reason, names Priya as the approver, shows request ACC-2048 as pending, and returns to the report after approval.A service dependency outage panel says Identity check unavailable, shows saved application answers, and offers Upload documents for manual review with expected review time.
Bad UI Users abandon the task because every visible route is inert.Disabled controls hide the only validation feedback from keyboard and assistive technology users.Error message appears far from the field it describes.Summary and field messages visually disconnected or contradictory.A blocked report only has Retry, so the user repeats the same denied request.The only visible action repeats the failing lookup or request.
Good UX A user sees which prerequisites are complete, opens billing setup for the missing prerequisite, saves the invite draft, requests owner approval, and returns to send once eligibility changes.Users can satisfy requirements one by one and see the action become available, or submit and receive actionable validation.Validation appears after blur or submit when it helps correction.After failed submit, focus or reading order makes the summary discoverable before users scan the form.A user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report.The person reaches the intended result with clear feedback.
Bad UX Users abandon the task because every visible route is inert.Disabled controls hide the only validation feedback from keyboard and assistive technology users.Showing errors before users type.Only showing errors below the fold.A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure.A user tries the same failed lookup five times because the manual route is hidden until after repeated failure.
Best fit Auditing disabled primary actions, toolbar commands, menu items, toggles, form controls, checkout actions, invite flows, publish controls, exports, destructive actions, and workflow steps.Use this anti-pattern entry to audit disabled submit, continue, create, save, delete, publish, invite, export, payment, and setup actions.A single field has a specific correctable problem.Form submission can produce one or more errors.A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue.A primary lookup, verification, upload, payment, search, device feature, online-only step, or channel can fail while the user still needs to finish.
Avoid when The control is briefly disabled only to prevent duplicate submission and visible progress explains the temporary state.The action remains available and returns actionable validation after activation.The main recovery task is finding several errors across a submitted page.The message is a system failure, permission problem, or outage rather than a validation issue.The user is unauthenticated and the next step is sign-in or session extension.The only honest next step is retrying the same operation after a transient failure.
Required state Prerequisite map state that shows each requirement and whether it is met.Unavailable action state with visible reason and affected requirement.Invalid field with preserved user value and adjacent correction text.Failed-submit state with summary visible near the form heading.Recovery start state with original blocked task and current account.Primary path available state.
Accessibility burden Keep requirement and recovery text in reading order before or adjacent to the unavailable control.Keep requirement text in normal reading order and near the unavailable action.Expose invalid state on the input and connect error text to the field description where possible.Use a heading and alert behavior that makes the summary discoverable.Move focus to the recovery heading when the workflow opens from a denial.Use specific link and button names that describe the alternate method and outcome.
Common misuse A disabled Invite teammate action hides that billing setup, owner approval, or admin policy is required.Using disabled state to hide permission, quota, account lock, or system dependency problems.Showing field errors before users have interacted with the control.Replacing field-level messages with only a top-level summary.Offering Retry for an unchanged authorization denial.Hiding manual entry or support until users repeatedly fail.

Disabled controls without recovery

UI or UX
UI + UX - Blocked-control anti-pattern
UI guidance
Prefer enabled validation, request access, retry after state change, save draft, sign-in recovery, dependency setup, contact owner, or fallback actions over inert controls with hidden causes.
UX guidance
Model disabled controls as a lifecycle: unavailable with cause, recoverable, pending, available, processing, completed, or honestly stopped.
Good UI
An Invite teammate panel shows missing billing setup, owner approval, and team domain checks, with Open billing, Request owner approval, Save draft, and Contact admin actions.
Bad UI
Users abandon the task because every visible route is inert.
Good UX
A user sees which prerequisites are complete, opens billing setup for the missing prerequisite, saves the invite draft, requests owner approval, and returns to send once eligibility changes.
Bad UX
Users abandon the task because every visible route is inert.
Best fit
Auditing disabled primary actions, toolbar commands, menu items, toggles, form controls, checkout actions, invite flows, publish controls, exports, destructive actions, and workflow steps.
Avoid when
The control is briefly disabled only to prevent duplicate submission and visible progress explains the temporary state.
Required state
Prerequisite map state that shows each requirement and whether it is met.
Accessibility burden
Keep requirement and recovery text in reading order before or adjacent to the unavailable control.
Common misuse
A disabled Invite teammate action hides that billing setup, owner approval, or admin policy is required.

Disabled button with no explanation

UI or UX
UI + UX - Blocked action anti-pattern
UI guidance
Replace a lone greyed-out action with visible requirement text, a checklist, permission message, or enabled validation submit that tells users what blocks progress.
UX guidance
Help users understand whether the block is missing input, invalid data, permission, quota, dependency, safety policy, or temporary processing.
Good UI
Create workspace is paired with visible requirements: enter a workspace name, accept billing terms, and request owner access.
Bad UI
Disabled controls hide the only validation feedback from keyboard and assistive technology users.
Good UX
Users can satisfy requirements one by one and see the action become available, or submit and receive actionable validation.
Bad UX
Disabled controls hide the only validation feedback from keyboard and assistive technology users.
Best fit
Use this anti-pattern entry to audit disabled submit, continue, create, save, delete, publish, invite, export, payment, and setup actions.
Avoid when
The action remains available and returns actionable validation after activation.
Required state
Unavailable action state with visible reason and affected requirement.
Accessibility burden
Keep requirement text in normal reading order and near the unavailable action.
Common misuse
Using disabled state to hide permission, quota, account lock, or system dependency problems.

Inline validation

UI or UX
UI + UX - Field-level validation feedback
UI guidance
Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.
UX guidance
Help the person reach a clear task outcome.
Good UI
Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI
Error message appears far from the field it describes.
Good UX
Validation appears after blur or submit when it helps correction.
Bad UX
Showing errors before users type.
Best fit
A single field has a specific correctable problem.
Avoid when
The main recovery task is finding several errors across a submitted page.
Required state
Invalid field with preserved user value and adjacent correction text.
Accessibility burden
Expose invalid state on the input and connect error text to the field description where possible.
Common misuse
Showing field errors before users have interacted with the control.

Error summary

UI or UX
UI + UX - Form recovery summary
UI guidance
Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance
Move users from the summary to the exact field, group, or first invalid control that needs correction.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Summary and field messages visually disconnected or contradictory.
Good UX
After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX
Only showing errors below the fold.
Best fit
Form submission can produce one or more errors.
Avoid when
The message is a system failure, permission problem, or outage rather than a validation issue.
Required state
Failed-submit state with summary visible near the form heading.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Replacing field-level messages with only a top-level summary.

Permission recovery

UI or UX
UI + UX - Guided workflow for regaining or routing around missing access
UI guidance
Show a recovery workspace after denial with the current account, current role, requested role, safe owner or admin destination, request reason, policy limits, status timeline, and original blocked task.
UX guidance
Use permission recovery when users can take a concrete step to regain access, use another identity, request a different role, escalate a policy block, or continue with a safe fallback after an authorization denial.
Good UI
A restricted report recovery panel shows alex@northwind.example lacks Finance viewer access, lets the user request Viewer or Editor with a reason, names Priya as the approver, shows request ACC-2048 as pending, and returns to the report after approval.
Bad UI
A blocked report only has Retry, so the user repeats the same denied request.
Good UX
A user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report.
Bad UX
A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure.
Best fit
A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue.
Avoid when
The user is unauthenticated and the next step is sign-in or session extension.
Required state
Recovery start state with original blocked task and current account.
Accessibility burden
Move focus to the recovery heading when the workflow opens from a denial.
Common misuse
Offering Retry for an unchanged authorization denial.

Fallback path

UI or UX
UI + UX - User-directed alternate route when the primary path cannot complete
UI guidance
Place the alternate route beside the blocked primary path with a label that names what changes, such as Enter address manually, Use cached report, Call support with reference, or Continue with paper evidence.
UX guidance
Use a fallback path when the primary route is unavailable, unsuitable, unsupported, or repeatedly failing, and users still need a credible way to complete the task.
Good UI
A service dependency outage panel says Identity check unavailable, shows saved application answers, and offers Upload documents for manual review with expected review time.
Bad UI
The only visible action repeats the failing lookup or request.
Good UX
The person reaches the intended result with clear feedback.
Bad UX
A user tries the same failed lookup five times because the manual route is hidden until after repeated failure.
Best fit
A primary lookup, verification, upload, payment, search, device feature, online-only step, or channel can fail while the user still needs to finish.
Avoid when
The only honest next step is retrying the same operation after a transient failure.
Required state
Primary path available state.
Accessibility burden
Use specific link and button names that describe the alternate method and outcome.
Common misuse
Hiding manual entry or support until users repeatedly fail.
Decision rules
  • Choose disabled controls without recovery when a button, menu item, toggle, toolbar command, form control, or workflow action is unavailable and no reachable next step can change, route around, or truthfully close the blocked state.
  • Choose disabled-button-no-explanation when the main defect is a single inactive button that lacks a visible reason, even if the recovery path is otherwise simple once explained.
  • Choose inline validation when users can correct a specific field near the input and then continue without a wider permission, dependency, offline, session, or workflow recovery model.
  • Choose error summary when a submitted form returns multiple linked errors and users need top-of-page recovery navigation across fields.
  • Choose permission recovery when the block is an authorization boundary and the product can request a role, contact an owner, switch account, track pending status, handle approval or decline, or resume after access changes.
  • Choose fallback path when the primary route cannot complete but a different method can finish the same user outcome or provide a named support handoff with context preserved.
  • If the disabled control hides required information in a tooltip, fix the recovery surface first; tooltip-only required information is a separate anti-pattern about where essential instructions are placed.
  • If the disabled state is only temporary processing, show progress, preserve work, and provide timeout or retry behavior instead of classifying it as a durable blocked control.
  • A healthy disabled-control design names the cause, owner, recovery action, and clearing condition; a failed one leaves users guessing or waiting indefinitely.
  • Do not offer retry for permission, dependency, or policy blocks unless the relevant state has changed.
Inspect live examples
Disabled controls without recoveryDisabled button with no explanationInline validationError summaryPermission recoveryFallback path
Failure modes
  • The UI disables Continue until hidden requirements are met and gives no field, checklist, or submit validation route.
  • A disabled menu command has a hover-only title that touch and keyboard users cannot open.
  • A role-limited user sees disabled Export but no current role, required role, owner, request path, or read-only fallback.
  • A dependency lock says Setup required but does not link to the missing setup step or say who owns it.
  • A Save button remains disabled after reconnecting because stale eligibility state never refreshes.
  • A fake fallback link sends users to a help page that cannot complete, preserve, or route the blocked task.

Saved items