Error Recovery Failure: The Signal That Fires When Users Can't Fix Their Mistake
Weight 18 in the confusion score. Fires when a user encounters a form validation error and either can't figure out how to fix it or gives up trying. Almost always points to bad error messaging, not user error.
Error recovery failure is what happens after a form validation error that the user can't resolve. They submit a form, something fails validation, an error state appears, and either they leave within 30 seconds (abandonment after error) or they try to fix the same field 3+ times without success.
Both patterns fire the signal. Weight 18 in the confusion score.
It's weighted high because both patterns indicate the same thing: the error message didn't tell the user what they did wrong. Not a user failure. A product failure.
How it differs from form abandonment
Form abandonment fires before submission. The user hesitates on a field, decides not to fill it out, and leaves. The form was never submitted.
Error recovery failure fires after submission. The user filled out the form, submitted it, got an error, and then couldn't proceed. This is a harder failure because the user showed clear intent. They wanted to complete the form. Something stopped them after they tried.
Intent-to-completion failures have higher conversion cost than pre-submission hesitation. The user crossed the decision threshold. The product failed to let them through.
What bad error messages look like in practice
The most common pattern: a generic "Please review the highlighted fields" message with a red border on one or more inputs. The user looks at the highlighted field, doesn't understand what's wrong with it, tries submitting again, gets the same error, and leaves.
Specific examples from session analysis:
Password fields with opaque requirements. "Password must meet complexity requirements" tells the user nothing. Which requirement did they miss? Length? Special character? Uppercase? The error message knows. It doesn't say. Research on form field abandonment puts password fields at 10.5% abandonment, highest of any field type. Bad error messaging is a significant part of that.
Phone number formatting. The field accepts "555-123-4567" but the user typed "5551234567" without dashes. The error message says "Invalid phone number." The user tries three more formats before giving up. Adding an input mask or accepting any reasonable format costs 30 minutes of development and eliminates the signal entirely.
Email already registered. "Email address is already in use" with no option to log in, reset password, or proceed. The user doesn't know they have an account. They try a different email, then a third, then leave. The error message needed one link. "Log in instead" or "Reset your password."
The 3-attempt threshold
The signal fires at 3 attempts on the same field after a validation error. Three tries means the user has no idea what to change. Same field, same error, no progress. Stuck.
At 3 attempts without resolution, the probability of successful completion drops below 20% based on session data. Users who've tried 3 times and still can't pass validation almost always leave. The signal fires early enough to surface the problem before the data decays.
What the fix looks like
The solution is almost always better error copy, not a code change.
Good error messages: specific, actionable, non-judgmental. "Password must be at least 8 characters and include one number" beats "Password too weak." "Your card declined. Check the expiration date or try a different card" beats "Payment failed."
The error message should answer three questions: what went wrong, why it went wrong, and how to fix it. Most error messages answer none of them.
For complex validation (passwords, phone numbers, addresses): show the requirements before submission, not just after failure. Inline validation that responds as the user types, showing green checkmarks when requirements are met. This reduces error recovery failure to near zero on those fields because users know before they submit whether they've met the requirements.
How it interacts with other signals
Error recovery failure rarely appears in isolation. It clusters with rage clicks on the submit button (users trying to force through the error) and form hesitation on the error-causing field in subsequent attempts.
When loop navigation appears alongside error recovery failure on the same page, users are leaving the form, going to another page (often looking for information to help them fill out the field correctly), and coming back. Add a help link to the field. Whatever they're going to look for, put it on the page.
The confusion score's element attribution identifies which field is generating the recovery failure signal. That's the field that needs better error copy. The fix is targeted. It doesn't require redesigning the form.