Retry Buttons Labeled "Try Again" Get 31% More Taps Than "Resubmit"
The number came out of a batch of A/B tests that a payments-adjacent team I know ran across roughly forty thousand failed checkout sessions. Same button, same position, same color, same weight — the only variable was the copy. "Try Again" pulled 31% more taps than "Resubmit." Nobody on the team had a clean explanation for it, which is why the result stuck with me. It's the kind of finding that looks like a rounding error until you start pulling on the thread and realize it's actually a story about how humans process failure, agency, and the difference between a door and a wall.
The Copy Is the Interface
Most engineers treat button labels as strings. They live in a locale file, they get passed through a translation pipeline, and they're the last thing anyone thinks about before a release. That's a mistake, and the 31% figure is one of the cleaner pieces of evidence for why.
A button label is not a description of what the button does. It's a micro-contract with the user about what happens next. "Resubmit" describes the system's action: a form is being submitted again. "Try Again" describes the user's action: you, a person, are going to attempt something. Those are different sentences with different subjects, and the subject matters enormously when the previous attempt just failed.
This is the same principle behind the classic finding in behavioral economics that people are more motivated by framing that emphasizes their own agency. Kahneman and Tversky's work on framing effects showed that logically equivalent descriptions produce different decisions depending on how they're worded. A program that says "90% survival rate" gets chosen over one that says "10% mortality rate," even though the two are identical. Button copy is framing in miniature. "Resubmit" frames the situation as a bureaucratic re-do. "Try Again" frames it as a fresh attempt.
The gap isn't about clarity. Both labels are perfectly clear. It's about how each one makes the user feel about the state they're in.
Why "Resubmit" Reads as Blame
There's a subtle accusatory edge to "Resubmit." The prefix "re-" implies you already did this, and the base verb "submit" is transactional and formal. Stack them and you get a word that sounds like a form letter from an insurance adjuster. When something has just failed — a payment declined, a file upload timed out, an API returned a 500 — the user is already in a mildly defensive posture. They don't know if it was their fault. They don't know if they typed the card number wrong or if your backend is on fire.
"Resubmit" quietly answers that question in the wrong direction. It implies the thing you did needs to be done over, which is one small step from implying you did it wrong. "Try Again" leaves the question open. It's an invitation, not a correction.
I've watched session recordings where users hover over "Resubmit" for several seconds before clicking, then hover over "Try Again" and click almost immediately. The hesitation is the tell. They're not confused about what the button does. They're deciding whether they want to engage with whatever just happened.
Failure States Are Emotional States
Here's the part that most frontend tutorials skip: an error state is not a neutral UI condition. It's an emotional event. Something the user wanted didn't happen, and depending on what it was, the emotional stakes range from mild annoyance to genuine distress. A failed newsletter signup is nothing. A failed rent payment at 11:47 PM on the last day of the month is a different animal entirely.
Good error handling is therefore partly a design problem and partly a psychological one. The copy is the cheapest lever you have.
Loss Aversion and the Cost of the Second Attempt
Kahneman and Tversky's prospect theory gives us loss aversion: losses feel roughly twice as painful as equivalent gains feel good. In a retry flow, the user has already experienced a loss — the failed attempt cost them time, attention, and possibly a bit of dignity. Every additional friction point in the retry path gets weighed against that existing loss, not against a neutral baseline.
This is why the copy matters more on the second attempt than the first. By the time someone has failed once, they're already in the red. A label that reads like a scolding ("Resubmit") adds cognitive cost on top of the emotional cost they're already carrying. A label that reads like a nudge ("Try Again") doesn't. The 31% lift isn't magic — it's the removal of a small tax.
There's a well-known study from the field of behavioral operations research showing that when you ask people to repeat a task after a failure, the framing of the repeat request predicts whether they'll actually do it. Requests framed as "another attempt" outperform requests framed as "a correction" by a wide margin. The mechanism is straightforward: correction implies the previous attempt was deficient, and people avoid situations that imply they're deficient.
Variable-Ratio Reinforcement, Carefully Applied
I want to be careful here, because this is the concept that gets abused. Variable-ratio reinforcement — the schedule where a reward arrives after an unpredictable number of actions — is the most powerful conditioning schedule known, and it's the mechanism behind a lot of dark patterns in consumer software. You should not build retry flows that exploit it. You should understand it, though, because it explains a real phenomenon: users who succeed on the second or third try of something are often more loyal to the product than users who succeed on the first try.
This is the "pratfall effect" applied to software. A product that fails gracefully and then works feels more trustworthy than a product that never fails, because the failure-and-recovery sequence demonstrates something the smooth path can't: that the system handles adversity. The retry button is where that demonstration happens. If the button says "Resubmit," the user experiences the failure as a bureaucratic dead end. If it says "Try Again," they experience it as a recoverable moment.
The variable-ratio angle is this: the user doesn't know if the second attempt will work. That uncertainty is inherently engaging, and the copy either leans into it ("Try Again" — let's see what happens) or fights it ("Resubmit" — do the thing you already did, again, and hope).
What the Data Actually Shows
The 31% figure I opened with comes from a payments-adjacent context, but the pattern shows up across a lot of surfaces. I've seen similar gaps in:
- Password reset flows. "Try Again" beats "Retry Login" by a meaningful margin, especially on mobile.
- File upload retries. "Try Again" beats "Upload Again" — the word "again" is doing less work than the word "try."
- Form validation failures. "Try Again" beats "Correct and Resubmit" by a landslide, though that's partly because the latter is a mouthful.
- API error toasts. "Try Again" beats "Retry" in most tests, though the gap is smaller than with "Resubmit."
The common thread: verbs that describe the user's intent ("try") outperform verbs that describe the system's operation ("submit," "retry," "upload"). This is consistent with a broad body of research in user experience showing that action-oriented labels drive more engagement than process-oriented labels, but the effect size here is larger than most UX teams expect.
A Concrete Case: The Two-Button Checkout
The cleanest example I've seen was a two-button checkout flow at a small e-commerce shop. When a payment failed, the user saw an error message and a single button. In version A, the button said "Resubmit Payment." In version B, it said "Try Again." Everything else — the error copy, the layout, the retry logic, the timeout — was byte-for-byte identical.
Version B won by 27% on retry taps and 19% on eventual successful completion. The second number is the interesting one. It's not just that more people tapped the button; more people finished the purchase. The copy didn't just change behavior at the button. It changed the user's entire relationship to the failure.
The team's hypothesis was that "Resubmit Payment" made the failure feel like a problem with the payment method, while "Try Again" made it feel like a temporary glitch. That's a plausible read. It also points at something bigger: the copy sets the user's mental model of what went wrong, and that model determines whether they keep going.
Building Retry Flows That Respect the User
If you're building retry flows — and if you're doing anything with payments, uploads, or real-time sync, you are — here's what I'd take from all this.
Treat the Label as a Design Decision
Don't let the label be the last thing anyone touches. Put it in the design review. Put it in the copy review. Argue about it. The 31% gap is not a rounding error; it's a meaningful chunk of your recovery rate, and recovery rate is a direct input to revenue, retention, and support load.
The default should be "Try Again" unless you have a specific reason to deviate. It's short, it's warm, it's agency-preserving, and it wins tests. If you're in a context where "Try Again" feels too casual — a medical portal, a legal filing system — you can reach for "Try Once More" or "Attempt Again," but be aware you're giving up some of the lift.
Match the Copy to the Failure Mode
Not every failure is the same, and the copy shouldn't pretend otherwise. A network timeout is a "Try Again" situation. A validation error is a "Fix and Try Again" situation. A permission error is not a retry situation at all — no amount of tapping will help, and offering a retry button is actively user-hostile.
This is where a lot of teams go wrong. They build one generic error state and slap "Try Again" on everything. That works for transient failures and fails badly for permanent ones. The behavioral principle here is straightforward: users who tap a retry button and get the same error lose trust in the button, and then they lose trust in the product.
Instrument the Second Attempt
Most analytics setups track the first failure and the eventual success or abandonment, but not the retry tap itself. That's a gap. The retry tap is the moment of maximum user uncertainty, and it's the moment where your copy either earns its keep or doesn't.
Track:
- Retry button impressions
- Retry button taps
- Second-attempt success rate
- Time between failure and retry tap
- Drop-off after the second failure
The time-between metric is especially useful. If users are hovering for five seconds before tapping, your copy is making them think. If they're tapping in under a second, the copy is doing its job invisibly. Both are fine outcomes, but they mean different things.
Don't Over-Optimize
One caution: this is an area where A/B testing can go wrong. If you test "Try Again" against "Resubmit" and "Try Again" wins, great. If you then test "Try Again" against "Give It Another Shot" and the longer one wins by 2%, be skeptical. Small lifts on button copy often don't replicate, and the effect sizes you should care about are the ones that show up across multiple surfaces and multiple time periods.
The 31% figure is interesting because it's large enough to be robust. Most copy tests aren't. Treat the big gaps as real and the small ones as noise until proven otherwise.
Where This Connects to the Harder Stuff
The reason I keep coming back to this topic is that retry buttons are the visible tip of a much larger iceberg. Every system that handles money, identity, or real-time state has to decide how it treats failure, and that decision is partly technical and partly psychological.
In payment integrations, the retry flow is where you decide whether a declined transaction is a dead end or a recoverable moment. In KYC flows, it's where you decide whether a failed document upload feels like a bureaucratic wall or a fixable mistake. In WebSocket-based real-time systems, it's where you decide whether a dropped connection is a scary event or a routine one.
The technical architecture matters, obviously. Idempotency keys, exponential backoff, jitter, circuit breakers — all of that is necessary. But the user never sees any of it. The user sees a button. And that button is either telling them "you can do this" or "you already failed at this."
The teams that get this right tend to be the ones that treat error states as first-class product surfaces rather than afterthoughts. They write the copy with the same care they write the happy path. They test it. They measure the second attempt, not just the first. And they understand that the difference between "Resubmit" and "Try Again" is not a matter of style — it's a matter of whether the user believes the system is on their side.
If you're building anything with a retry path, go look at your labels right now. Not the logic. Not the backoff. Just the words. There's a decent chance one of them is costing you more than you think.