The $300 million button, revisited: the quiet power of UX and microcopy in conversion

One button, as Jared Spool told it

In January 2009 Jared Spool, founder of the usability firm User Interface Engineering (UIE), published a short essay called "The $300 Million Button".¹ Most retellings have drifted since, so here it is as he wrote it.

A large online retailer, which he never names and describes only as a $25 billion retailer, had a login form at the start of checkout. Shoppers filled their basket, pressed Checkout and met two fields (email address and password), two buttons (Login and Register) and a "Forgot password" link.¹

In usability testing, first time shoppers resented being asked to register. One put it in a line that has outlived the essay: "I'm not here to enter into a relationship. I just want to buy something."¹

Returning shoppers could not remember which email or password they had used. In the database, 45% of all customers had more than one registration, some as many as 10. The site handled about 160,000 password requests a day, and 75% of the people who asked for a password never went on to complete the purchase.¹

The fix was small. The designers took away the Register button and put a Continue button in its place, with this message:

You do not need to create an account to make purchases on our site. Simply click Continue to proceed to checkout. To make your future purchases even faster, you can create an account during checkout.

Spool reports that the number of customers purchasing went up by 45%, that the extra purchases brought in an extra $15 million in the first month, and that the first year saw an additional$300,000,000.¹

Worked example: reading his numbers

Password requests that never turned into an order, per day:

$$160{,}000 \times 0.75 = 120{,}000$$

Here $160{,}000$ is the daily count of password requests Spool reports, $0.75$ is the share of those people who never completed the purchase, and $120{,}000$ is the number of shoppers a day who asked for help getting in and then gave up. This is a plain rate applied to a count, see Foundations: ratios and rates.

Now the money. If the first month's extra $15 million had simply repeated every month, the year would come to:

$$15 \times 12 = 180$$

Here $15$ is the first month's extra revenue in millions of dollars, $12$ is the number of months, and $180$ is the year in millions if nothing else changed. The essay says $300$ million, so the effect grew, or the year held a busy season, or something else changed too. The essay does not say which. See Foundations: percentages.

What the story proves, and what it does not

The popular version says that one word, "Register" swapped for "Continue", made $300 million. That is not what happened. The change removed a forced registration step. The new button let people buy without an account, and the message told them so. The word was the visible part. The removed obligation was the change.

Three more honest limits:

• It is one anecdote. There is no control group in the essay, no confidence interval, nothing you could rerun.
• The figures are the client's, reported by Spool, never independently checked. The retailer is not named. You will read online that it was one famous retailer or another, and I have found no source that settles it.
• The scale is unusual. At $25 billion a year, a small change in the share who finish is a lot of dollars. A shop in Galway will not see$300 million from anything.

What the story does prove is narrower and more useful. A step you think of as a convenience can be an obstacle for the person in front of it. The builders of that login form could not see the problem, the shoppers could not stop seeing it, and the evidence came from usability testing and the database, not from opinion.

There is a modern twist. Baymard Institute, which runs large usability studies of checkouts, now advises against a bare "Continue" at the account step. Their testing found that "Continue" or "Check Out Now" slows people down there, and that the label should contain the word "Guest", as in "Continue as guest".² So even the famous word is not the lesson. The lesson is: say plainly what happens when I press this.

A button label is a promise about what happens next

Microcopy is the small text in an interface: button labels, field labels, hints, error messages, the line under the payment form. It is short, but its job is not. It answers the question in the reader's head at the exact moment they have it.

A button label is a promise: press me and this will happen. When it is vague ("Submit", "Go") the reader has to guess. When it is wrong, they distrust the next one.

The GOV.UK Design System, the British government's public pattern library for its online services, puts it in one sentence: write button text in sentence case, describing the action it performs, such as "Save and continue".³ For a page that asks one question and moves on, it tells teams to label the button "Continue", not "Next".⁴ That is not a contradiction with Baymard. On a question page, "Continue" is accurate: you answer, you go on. At an account choice in a checkout, "Continue" hides which of two paths you are taking, so the label has to name the path.

A good button label usually has three parts: a verb, the object, and anything that changes the commitment.

Worked example: the buttons at Shandon Candle Company

Shandon Candle Company is an invented shop in Cork. Siobhán pours soy candles in a small unit near Shandon and sells them at shandoncandles.example. The average order is €34. Every number about this shop is made up.

Her site had these buttons. Here is each one before and after, and why.

• Product page. Before: "Submit". After: "Add to basket". The old label described what the browser does, not what Siobhán's customer wants.
• Basket. Before: "Proceed". After: "Go to checkout". Proceed where?
• Account step. Before: "Register" and "Login". After: "Continue as guest" first, then "Sign in". The guest option names the path and comes first.
• Delivery step. Before: "Next". After: "Continue to payment". The reader learns that payment is the next screen, so nothing is sprung on them.

None is clever. Each removes a guess.

Guest checkout is the real lesson

If you take one thing from Spool's essay, take this: do not make people create an account before they can pay you.

The current evidence agrees. In Baymard's latest survey of US shoppers who had abandoned an order in the previous three months (leaving out the people who were only browsing), 18% gave "the site wanted me to create an account" as a reason.⁵ In an earlier Baymard survey of 4,384 US adults in 2022, the figure was 24%.² Different years and waves, so I quote both and average neither.

Offering guest checkout is not enough. Baymard found that 47% of the sites they benchmarked that allow guest checkout do not make it the most prominent option on the account step.² The common mistakes: a guest option written as a small text link, placed below the sign in form, labelled in a way that does not say "no account needed", or only revealed after the shopper types an email address.²

The better pattern: two choices at the account step, guest checkout and sign in, with guest as a button at the top. Account creation waits for the confirmation page, where the shopper has already typed their address and only adds a password. Baymard found that 42% of the sites they benchmark still ask for the account before or during checkout instead.⁶

The decision is the only fork, and both branches lead to the same delivery step. Whatever the shopper chooses, nothing stands between them and paying.

Worked example: Siobhán's account step, before and after

Before, Siobhán's checkout opened with a sign in form and a "Register" link underneath. Guest checkout existed, but only as a line of small grey text at the bottom: "Or checkout without an account".

After, the account step reads:

How would you like to check out? [Continue as guest] You can save your details for next time after you order. Already have an account? [Sign in]

And the confirmation page adds one optional box: "Save your details for faster checkout next time. Just choose a password." with three reasons underneath: track your order, see past orders, reorder your favourite scents.

Only the words and their places changed. Same shop, same code, same stock.

Error messages that help people finish

An error message is the moment a form tells someone they got it wrong, and the moment they are most likely to give up. Highest warmth, no wit at all.

The clearest guidance on error messages I know comes from the GOV.UK Design System, the British government's pattern library, and it is free for anyone in Ireland to read too.⁷ In short:

• Say what happened and how to fix it, in plain English.
• Be specific. Avoid generic messages such as "This field is required".
• Use the same words as the question, so the message and the label match.
• For an empty field, give an instruction ("Enter your first name"). For something wrong, describe the problem ("Name must be 35 characters or less").
• Avoid words like "invalid", "valid", "forbidden", "illegal", "you forgot", and avoid "please", "sorry" and "oops".
• Show each message next to its field and in a summary at the top, and never clear what the person typed.

Baymard shows why this matters at a checkout. In their benchmark, 98% of sites use generic error messages. In their testing, people took up to five minutes to fix simple errors because of vague wording, and some gave up altogether.⁸ A site often has one message per field, so an email missing its "@" and an email with a broken ending get the same "The email is invalid", even though the code knows exactly which problem it is. Baymard recommends four to seven specific messages for complex fields such as card number, email and phone, starting with the errors that fire most often.⁸

One caution: on sign in and password reset forms, "this email has no account" helps an attacker find your customers. Use it only with rate limits and attempt caps.⁸

Worked example: rewriting Siobhán's error messages

Here are four messages from Siobhán's checkout, before and after.

• Email left empty. Before: "Required field". After: "Enter your email address so I can send your order confirmation".
• Email missing the @. Before: "Invalid email". After: "Enter an email address with an @, like name@example.com".
• Eircode too short. Before: "Invalid input". After: "Eircode is too short. An Eircode has seven letters and numbers".⁹
• Card number incomplete. Before: "Payment failed. Error 402". After: "Card number is too short. Check the long number on the front of your card".

Each new message names the field, says what is wrong and says what to do. None blames the shopper, and none apologises three times.

Help text belongs next to the question, never inside it

Some questions need a little help. Why do you want my phone number? Where is the security code on my card?

Help text, which the GOV.UK Design System calls hint text, answers that one doubt in one short line next to the label. Their guidance: keep each hint to a single short sentence without full stops, never put links in hints, mark optional fields with "(optional)" in the label, and never mark mandatory ones with asterisks.⁴ The same pattern says to know why you need each answer, ask only for what you really need, and make it clear why you are asking.⁴

Two common mistakes. A label inside the field as placeholder text vanishes the moment someone types. And help text often explains the obvious and ignores the real worry. "Enter your phone number" under a field labelled "Phone number" helps nobody. "Only used if the courier cannot find you" helps a lot.

Baymard's checkout guide adds the length problem. The average checkout they study has 19.9 form elements, and an optimised flow can be as short as 12.¹⁰ Every field you remove is a hint you never have to write.

Worked example: the phone field at Shandon Candle Company

Siobhán's delivery form required a phone number with no explanation. Siobhán suspected shoppers hesitated there, picturing marketing calls.

Her courier does need a number for failed deliveries, so dropping it or making it optional would cost her. She keeps it and explains it:

Phone number Only shared with the courier if they cannot find your address

Label above, hint between label and field, nothing inside the box. One line, one honest reason.

Reassurance belongs next to the payment fields

Doubt peaks at payment. The shopper is about to hand card details to a business they may have found ten minutes ago.

In Baymard's 2025 survey of 1,026 US adults, 19% said they had abandoned a checkout in the previous three months because they did not trust the site with their card details.¹¹ Their testing also found something that surprises engineers. Shoppers judge security by how the page looks, not by how it is built. Every field on an HTTPS page is encrypted the same way, yet people feel the card fields are safer when they look different: a border, a background, a padlock icon, set apart from the address fields above.¹¹ Baymard notes that well known brands need less of this, and newer or smaller shops need it most.¹¹

This is perception, so be careful with it. A padlock on an insecure site is a lie. Reassurance has to be true, specific, and right next to what it reassures about, not in a footer.

Worth saying near the payment step, if true:

• Who processes the card ("Payments handled by your card provider's secure checkout", or the name of the real payment provider).
• The total, including delivery, before the shopper presses pay. Baymard's list has "couldn't see or calculate total order cost up front" as a reason for 12% of abandoning shoppers, and extra costs such as delivery for 40%.⁵
• What happens if something goes wrong: the returns window, in one line, with a link to the full policy.

Worked example: Siobhán's payment step

Before, the card fields looked like the address form, delivery cost appeared only after payment, and the payment logos sat in the footer. After, in this order:

1. A summary: "2 candles €32.00, delivery €3.95, total €35.95".
2. The card fields inside their own bordered panel with a light background, and a small padlock and one line inside the panel: "Card details go straight to the payment provider. I never see or store them."
3. Under the panel: "Not right? Return unused candles within 30 days."
4. The pay button (more on its words in the next section).

The summary must add up: €32.00 plus €3.95 is €35.95. A total that changes on the last screen is the fastest way to lose an order. The card line is there only because it is true for Siobhán's setup.

The pay button has a legal job in Ireland

Here microcopy stops being style. Ireland carries Article 8(2) of the EU Consumer Rights Directive in section 108 of the Consumer Rights Act 2022.¹² When an order made online places the consumer under an obligation to pay, the trader must make sure the consumer explicitly acknowledges that when placing the order. If placing the order means pressing a button, the button must be labelled, in an easily legible manner, only with the words "order with obligation to pay" or a corresponding unambiguous formulation.¹³ If the trader gets this wrong, the Act says the consumer is not bound by the contract or order, and it makes the failure an offence as well.¹³

If you learned this rule from older guidance, it used to sit in the European Union (Consumer Information, Cancellation and Other Rights) Regulations 2013 (S.I. No. 484 of 2013). The 2022 Act revoked those regulations in full, so section 108 is the one to read now.¹⁴

So "Continue", "Confirm" or "Submit" on the final button is not just vague, it is a legal risk. "Pay now" or "Place order and pay" says plainly that money is about to move. The exact line is a solicitor's call, not mine. A button such as "Pay €35.95 now" names both the action and the amount on the button itself.

Worked example: choosing Siobhán's final button

Siobhán weighs four labels:

• "Continue". Out. It does not say that pressing it creates an obligation to pay.
• "Complete". Out, for the same reason.
• "Place order". Better, but it does not mention paying.
• "Pay €35.95 now". In. It is unambiguous, it repeats the total from the summary above, and a shopper who expected a different amount sees it before pressing.

The button text is built from the basket total, so it always matches the summary.

Accessible words are clear words

Accessibility is not a layer on top of good microcopy. Mostly it is good microcopy. The Web Content Accessibility Guidelines (WCAG) 2.1 at level AA are the benchmark most of the law rests on.

In Ireland that law now has teeth. The European Accessibility Act applies here from 28 June 2025, through the European Union (Accessibility Requirements of Products and Services) Regulations 2023 (S.I. No. 636 of 2023), and eCommerce services are named in them.¹⁵ Services run by a microenterprise (fewer than 10 people, and an annual turnover or balance sheet of no more than €2 million) are exempt from the service requirements,¹⁵ so a small shop may fall outside the rules. The words below are still what a clear checkout looks like, and a shop that grows past the line will need them anyway.

Several of the WCAG success criteria are about words:

• 3.3.2 Labels or Instructions (level A): labels or instructions are provided when content requires user input.¹⁶
• 3.3.1 Error Identification (level A): if an input error is automatically detected, the item in error is identified and the error is described to the user in text.¹⁷ A red border alone does not count.
• 3.3.3 Error Suggestion (level AA): if the system knows how to fix the error, it tells the user, unless that would undermine security.¹⁸ "Card number is too short" passes, "Invalid" does not help.
• 2.5.3 Label in Name (level A): the accessible name of a control contains the text that is shown on it.¹⁹ Someone using voice control says what they see, "Pay now", and that has to work.
• 3.3.4 Error Prevention for legal and financial transactions (level AA): a submission that commits the user to pay must be reversible, checked for errors, or offered for review and correction before it is final.²⁰

Together they say what the GOV.UK Design System and Baymard say: visible labels, specific errors in text, and a final step where people can check what they agree to. Screen reader users benefit first, and so does everyone filling in a form on a phone at a bus stop. I wrote more about the legal side in accessibility requirements for eCommerce and SaaS.

Worked example: checking Siobhán's checkout against five criteria

Siobhán's developer walks through the new checkout with a screen reader and voice control.

1. Every field has a visible label tied to it in the code. Pass for 3.3.2.
2. Each error is text next to the field and in the summary, not just a red border. Pass for 3.3.1.
3. The Eircode and card messages say how to fix the problem. Pass for 3.3.3.
4. Saying "click Pay €35.95 now" presses the button. A first version had an icon button with the hidden name "submit form", which failed 2.5.3 and was fixed.
5. The items, delivery and total sit above the pay button, with a "Change" link for the address. Pass for 3.3.4.

Built to WCAG 2.1 AA, which is the honest way to say it. Not "guaranteed compliant".

Measuring a word change without fooling yourself

The Spool story has no control group, and most microcopy stories online are worse. When I change words, I measure the step they sit on, with consented analytics and no screen recordings, and compare fairly.

The measure is a step rate: of the people who reached a step, how many got past it.

$$r = \frac{n_{\text{passed}}}{n_{\text{reached}}}$$

Here $r$ is the step rate, $n_{\text{passed}}$ is the number of people who moved past the step, and $n_{\text{reached}}$ is the number who arrived at it. It is the same idea as a conversion rate, see Foundations: ratios and rates. Counting each step with one consented event is covered in event tracking with consent mode.

The fair comparison is an A/B test: half see the old step, half the new, at the same time, so the season hits both alike. Then a two proportion z test says whether the gap is bigger than chance:

$$z = \frac{p_B - p_A}{\sqrt{p(1-p)\left(\frac{1}{n_A} + \frac{1}{n_B}\right)}}$$

Here $p_A$ and $p_B$ are the step rates in the old and new versions, $n_A$ and $n_B$ are the number of people who reached the step in each, and $p$ is the pooled rate, all passes divided by all arrivals. A $z$ beyond about $1.96$ either way means the difference is significant at the 5% level. The full explanation is in Foundations: hypothesis tests, and the question of how many visitors you need before you start is in how much data you actually need.

Worked example: Siobhán's account step test

In one month, 1,200 consenting shoppers reach the account step. Half see the old version (A), half the new guest first one (B).

Step one, the step rates. Version A let 390 of its 600 through, so $p_A = 390 / 600 = 0.65$. Version B let 468 through, so $p_B = 468 / 600 = 0.78$.

Step two, the pooled rate: all passes over all arrivals, $p = 858 / 1{,}200 = 0.715$, so $1 - p = 0.285$.

Step three, put it all into the test:

$$z = \frac{0.78 - 0.65}{\sqrt{0.715 \times 0.285 \times \left(\frac{1}{600} + \frac{1}{600}\right)}} = \frac{0.13}{\sqrt{0.000679}} = \frac{0.13}{0.0261} = 4.99$$

Here $0.78$ and $0.65$ are $p_B$ and $p_A$, $0.715$ is the pooled rate $p$, $0.285$ is $1 - p$, the two $600$s are $n_A$ and $n_B$, and $0.0261$ is the standard error under the square root. A $z$ of $4.99$ is far beyond $1.96$, so the difference is very unlikely to be chance. Method in Foundations: hypothesis tests.

Step four, what it means for orders. In both versions, 70% of the people who got past the account step went on to pay. So version A produced $390 \times 0.70 = 273$ orders and version B $468 \times 0.70 = 327.6$, which rounds to 328.

Along the bottom are the three checkout steps, in order. Up the side is the number of shoppers still in the checkout, out of 600 per version. The gap opens at the account step and stays open to the order, because nothing later changed. The whole gain comes from the one step where the words changed.

Step five, the money, if the new version ran for all 1,200 shoppers in a month. Old: $1{,}200 \times 0.65 \times 0.70 = 546$ orders, times €34 is €18,564. New: $1{,}200 \times 0.78 \times 0.70 = 655.2$, call it 655 orders, times €34 is €22,270. The difference is €3,706 a month. As a percentage change in orders:

$$\Delta\% = \frac{655 - 546}{546} \times 100 = \frac{109}{546} \times 100 = 20.0\%$$

Here $\Delta\%$ is the percentage change, $655$ is the new monthly order count, $546$ the old one. See Foundations: percentages. I would not multiply the €3,706 by 12 for a board pack. A candle shop's December is nothing like its July, and the 70% was measured in one month. An honest report says "about a fifth more orders, measured over one month".

Where to start on Monday

None of this needs a redesign. In every example above the friction lived in the words, and words change in days. The order I work in:

1. Fix forced registration first: guest as a button at the top, accounts after the order.
2. Read every button aloud, and make the final one say that pressing it means paying.
3. Trigger every error message on purpose and rewrite the generic ones.
4. Give the one field people hesitate over an honest line of help, or remove it.
5. Put the full total and one true reassurance next to the card fields.
6. Check the five WCAG criteria with a screen reader and voice control.
7. Measure the changed step with a consented event and, where traffic allows, a sized A/B test.

None of this is a trick. If a change works by making it harder to say no, a pre ticked box or a hidden "no thanks", it is a dark pattern, not microcopy, and I wrote about where that line sits in GDPR dark patterns in UX. The wider review of copy, flow, visuals and speed is in the Clarity Framework.

Spool's retailer did not find $300 million in a word. It found it by watching people try to buy something and then getting out of their way. That part works at every size, including a candle unit in Cork.

Footnotes

1. Jared M. Spool, The $300 Million Button, Center Centre (formerly User Interface Engineering), 2009, https://articles.centercentre.com/three_hund_million_button/

2. Edward Scott, Make "Guest Checkout" the Most Prominent Option (47% Don't), Baymard Institute, 2023, https://baymard.com/blog/make-guest-checkout-prominent

3. GOV.UK Design System, Button, Government Digital Service, https://design-system.service.gov.uk/components/button/

4. GOV.UK Design System, Question pages, Government Digital Service, https://design-system.service.gov.uk/patterns/question-pages/

5. Baymard Institute, Cart Abandonment Rate: 50 Statistics and Why People Abandon, Baymard Institute, 2026, https://baymard.com/lists/cart-abandonment-rate

6. Edward Scott, Save Account Creation for the Confirmation Step (42% Don't), Baymard Institute, 2023, https://baymard.com/blog/delayed-account-creation

7. GOV.UK Design System, Error message, Government Digital Service, https://design-system.service.gov.uk/components/error-message/

8. Edward Scott, Improve Validation Errors with Adaptive Messages (98% Don't), Baymard Institute, 2023, https://baymard.com/blog/adaptive-validation-error-messages

9. Eircode, What is Eircode, Eircode, https://www.eircode.ie/what-is-eircode

10. Carl MacDonald, The Checkout UX Guide: Optimizing Your Ecommerce Order Flow with Research Backed Insights, Baymard Institute, 2026, https://baymard.com/blog/checkout-flow-ux-optimization

11. Jamie Holst, How Users Perceive Security During the Checkout Flow, Baymard Institute, 2016 with 2023 and 2025 data, https://baymard.com/blog/perceived-security-of-payment-form

12. Directive 2011/83/EU of the European Parliament and of the Council on consumer rights, Article 8(2), EUR-Lex, 2011, https://eur-lex.europa.eu/eli/dir/2011/83/oj/eng

13. Consumer Rights Act 2022 (No. 37 of 2022), section 108, Irish Statute Book, Office of the Attorney General, 2022, https://www.irishstatutebook.ie/eli/2022/act/37/section/108/enacted/en/html

14. Consumer Rights Act 2022 (No. 37 of 2022), section 8 and Schedule 1, Part 2, Irish Statute Book, Office of the Attorney General, 2022, https://www.irishstatutebook.ie/eli/2022/act/37/schedule/1/enacted/en/html

15. European Union (Accessibility Requirements of Products and Services) Regulations 2023, S.I. No. 636 of 2023, regulations 1, 3 and 5, Irish Statute Book, Office of the Attorney General, 2023, https://www.irishstatutebook.ie/eli/2023/si/636/made/en/print

16. W3C, Understanding Success Criterion 3.3.2: Labels or Instructions, Web Content Accessibility Guidelines 2.1, 2018, https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html

17. W3C, Understanding Success Criterion 3.3.1: Error Identification, Web Content Accessibility Guidelines 2.1, 2018, https://www.w3.org/WAI/WCAG21/Understanding/error-identification.html

18. W3C, Understanding Success Criterion 3.3.3: Error Suggestion, Web Content Accessibility Guidelines 2.1, 2018, https://www.w3.org/WAI/WCAG21/Understanding/error-suggestion.html

19. W3C, Understanding Success Criterion 2.5.3: Label in Name, Web Content Accessibility Guidelines 2.1, 2018, https://www.w3.org/WAI/WCAG21/Understanding/label-in-name.html

20. W3C, Understanding Success Criterion 3.3.4: Error Prevention (Legal, Financial, Data), Web Content Accessibility Guidelines 2.1, 2018, https://www.w3.org/WAI/WCAG21/Understanding/error-prevention-legal-financial-data.html