Der 300 Millionen Dollar Button, noch einmal erzählt: die stille Macht von UX und Microcopy in der Conversion

Ein Button, so wie Jared Spool ihn beschrieben hat

Im Januar 2009 veröffentlichte Jared Spool, Gründer der Usabilityfirma User Interface Engineering (UIE), einen kurzen Essay mit dem Titel "The $300 Million Button".¹ Die meisten Nacherzählungen haben sich seitdem ein gutes Stück vom Original entfernt. Deshalb hier die Geschichte so, wie er sie aufgeschrieben hat.

Ein großer Onlinehändler, den er nie beim Namen nennt und nur als Händler mit 25 Milliarden Dollar Umsatz beschreibt, hatte am Anfang des Checkouts ein Loginformular. Wer den Warenkorb gefüllt und auf Checkout geklickt hatte, sah zwei Felder (Mailadresse und Passwort), zwei Buttons (Login und Register) und einen Link "Passwort vergessen".¹

In Usabilitytests ärgerten sich Erstkunden darüber, dass sie sich registrieren sollten. Einer brachte es auf einen Satz, der den Essay überlebt hat: "Ich bin nicht hier, um eine Beziehung einzugehen. Ich will einfach etwas kaufen." Im Original: "I'm not here to enter into a relationship. I just want to buy something."¹

Wiederkehrende Kunden wussten nicht mehr, mit welcher Mailadresse oder welchem Passwort sie sich angemeldet hatten. In der Datenbank hatten 45 % aller Kunden mehr als eine Registrierung, manche bis zu 10. Die Website bearbeitete rund 160.000 Passwortanfragen am Tag, und 75 % derer, die ein neues Passwort anforderten, schlossen den Kauf nie ab.¹

Die Lösung war klein. Das Designteam nahm den Button Register weg, setzte an seine Stelle einen Button Continue und schrieb diese Nachricht dazu, hier sinngemäß auf Deutsch:

Du brauchst kein Konto, um bei uns einzukaufen. Klick einfach auf Weiter, um zur Kasse zu gehen. Damit deine nächsten Einkäufe noch schneller gehen, kannst du während des Bezahlens ein Konto anlegen.

Spool berichtet, dass die Zahl der kaufenden Kunden um 45 % stieg, dass die zusätzlichen Käufe im ersten Monat 15 Millionen Dollar mehr einbrachten und dass im ersten Jahr insgesamt 300.000.000 Dollar zusätzlich zusammenkamen.¹

Rechenbeispiel: seine Zahlen lesen

Passwortanfragen pro Tag, aus denen nie eine Bestellung wurde:

$$160{.}000 \times 0{,}75 = 120{.}000$$

Dabei ist $160{.}000$ die tägliche Zahl der Passwortanfragen, die Spool nennt, $0{,}75$ der Anteil dieser Leute, die den Kauf nie abgeschlossen haben, und $120{.}000$ die Zahl der Kundinnen und Kunden am Tag, die Hilfe beim Anmelden wollten und dann aufgegeben haben. Das ist eine einfache Rate, angewandt auf eine Anzahl (Grundlagen: Verhältnisse und Raten).

Jetzt das Geld. Hätten sich die zusätzlichen 15 Millionen Dollar des ersten Monats einfach jeden Monat wiederholt, käme das Jahr auf:

$$15 \times 12 = 180$$

Dabei ist $15$ der zusätzliche Umsatz des ersten Monats in Millionen Dollar, $12$ die Zahl der Monate und $180$ das Jahr in Millionen, wenn sich sonst nichts geändert hätte. Der Essay nennt $300$ Millionen. Also ist der Effekt gewachsen, oder das Jahr hatte eine starke Saison, oder es hat sich noch etwas anderes geändert. Welches davon, sagt der Essay nicht (Grundlagen: Prozente).

Was die Geschichte beweist, und was nicht

Die verbreitete Fassung sagt, ein einziges Wort, Register gegen Continue getauscht, habe 300 Millionen Dollar gebracht. So war es nicht. Die Änderung hat einen erzwungenen Registrierungsschritt abgeschafft. Der neue Button ließ Leute ohne Konto kaufen, und die Nachricht sagte ihnen das. Das Wort war der sichtbare Teil. Die eigentliche Änderung war die Pflicht, die wegfiel.

Dazu drei ehrliche Grenzen:

• Es ist eine einzelne Anekdote. Im Essay gibt es keine Kontrollgruppe, kein Konfidenzintervall, nichts, was du wiederholen könntest.
• Die Zahlen stammen vom Kunden, berichtet von Spool, nie unabhängig geprüft. Der Händler wird nicht genannt. Im Netz liest du, es sei dieser oder jener bekannte Händler gewesen, und ich habe keine Quelle gefunden, die das klärt.
• Die Größenordnung ist ungewöhnlich. Bei 25 Milliarden Dollar im Jahr ist schon eine kleine Verschiebung beim Anteil derer, die den Kauf abschließen, viel Geld. Ein Kerzenladen in Köln sieht 300 Millionen mit gar nichts.

Was die Geschichte tatsächlich zeigt, ist enger und nützlicher. Ein Schritt, den du für eine Bequemlichkeit hältst, kann für die Person davor ein Hindernis sein. Wer das Loginformular gebaut hatte, konnte das Problem nicht sehen, die Kundschaft konnte es nicht übersehen, und der Beweis kam aus Usabilitytests und aus der Datenbank, nicht aus Meinungen.

Es gibt eine aktuelle Wendung. Das Baymard Institute, das große Usabilitystudien zu Checkouts durchführt, rät heute von einem nackten "Continue" beim Kontoschritt ab. In ihren Tests hat "Continue" oder "Check Out Now" die Leute an genau dieser Stelle gebremst, und die Beschriftung sollte das Wort "Guest" enthalten, etwa "Continue as guest".² Auf Deutsch heißt das: "Als Gast bestellen". Selbst das berühmte Wort ist also nicht die Lektion. Die Lektion lautet: Sag klar, was passiert, wenn ich hier drücke.

Eine Buttonbeschriftung ist ein Versprechen über den nächsten Schritt

Microcopy ist der kleine Text in einer Oberfläche: Beschriftungen von Buttons und Feldern, Hinweise, Fehlermeldungen, die Zeile unter dem Zahlungsformular. Der Text ist kurz, seine Aufgabe ist es nicht. Er beantwortet die Frage, die sich jemand genau in diesem Moment stellt.

Eine Buttonbeschriftung ist ein Versprechen: Drück mich, und das hier passiert. Ist sie vage ("Absenden", "Los"), muss die Leserin raten. Ist sie falsch, misstraut sie dem nächsten Button.

Das GOV.UK Design System, die öffentliche Musterbibliothek der britischen Regierung für ihre Onlinedienste, fasst es in einem Satz zusammen: Schreib Buttontexte in Satzschreibung und beschreib die Aktion, die der Button auslöst, etwa "Save and continue".³ Für eine Seite, die eine Frage stellt und dann weitergeht, sollen Teams den Button "Continue" nennen, nicht "Next".⁴ Das widerspricht Baymard nicht. Auf einer Frageseite ist "Weiter" zutreffend: Du antwortest, du gehst weiter. Bei der Kontowahl im Checkout verschweigt "Weiter", welchen von zwei Wegen du nimmst, also muss die Beschriftung den Weg benennen.

Eine gute Buttonbeschriftung hat meist drei Teile: ein Verb, den Gegenstand und alles, was die Verpflichtung verändert.

Rechenbeispiel: die Buttons bei Ehrenfelder Kerzen

Ehrenfelder Kerzen ist ein erfundener Shop in Köln. Lena gießt Sojakerzen in einer Werkstatt in Ehrenfeld und verkauft sie über ehrenfelderkerzen.example. Der durchschnittliche Bestellwert liegt bei 34 €. Jede Zahl zu diesem Shop ist ausgedacht. Lena duzt ihre Kundschaft, wie viele kleine Läden ihrer Art.

Ihre Website hatte diese Buttons. Hier jeweils vorher und nachher, und warum.

• Produktseite. Vorher: "Absenden". Nachher: "In den Warenkorb". Die alte Beschriftung beschrieb, was der Browser tut, nicht, was Lenas Kundin will.
• Warenkorb. Vorher: "Fortfahren". Nachher: "Zur Kasse". Fortfahren wohin?
• Kontoschritt. Vorher: "Registrieren" und "Login". Nachher: zuerst "Als Gast bestellen", dann "Anmelden". Die Gastoption nennt den Weg und steht oben.
• Lieferschritt. Vorher: "Weiter". Nachher: "Weiter zur Zahlung". Die Kundin weiß jetzt, dass als Nächstes die Zahlung kommt, nichts überrascht sie.

Keine davon ist originell. Jede nimmt ein Ratespiel weg.

Die Gastbestellung ist die eigentliche Lektion

Wenn du aus Spools Essay nur eine Sache mitnimmst, dann diese: Zwing niemanden, ein Konto anzulegen, bevor er dich bezahlen darf.

Die aktuelle Datenlage sieht es genauso. In Baymards neuester Befragung von Onlinekäufern in den USA, die in den drei Monaten davor eine Bestellung abgebrochen hatten (ohne die, die nur gestöbert haben), nannten 18 % als Grund: Die Website wollte, dass ich ein Konto anlege.⁵ In einer früheren Baymard Befragung von 4.384 Erwachsenen in den USA aus dem Jahr 2022 lag der Wert bei 24 %.² Unterschiedliche Jahre und Erhebungswellen, deshalb nenne ich beide und mittle keinen.

Eine Gastbestellung anzubieten reicht nicht. Baymard hat festgestellt, dass 47 % der untersuchten Websites, die eine Gastbestellung erlauben, sie beim Kontoschritt nicht zur auffälligsten Option machen.² Die üblichen Fehler: die Gastoption als kleiner Textlink, unter dem Anmeldeformular platziert, so beschriftet, dass "kein Konto nötig" nicht drinsteht, oder erst sichtbar, nachdem jemand eine Mailadresse eingetippt hat.²

Das bessere Muster: zwei Möglichkeiten beim Kontoschritt, Gastbestellung und Anmelden, und die Gastbestellung als Button ganz oben. Das Konto kommt erst auf der Bestätigungsseite, wenn die Adresse schon eingegeben ist und nur noch ein Passwort fehlt. Laut Baymard verlangen 42 % der untersuchten Websites das Konto stattdessen noch vor oder während des Checkouts.⁶

Die Entscheidung ist die einzige Abzweigung, und beide Äste führen zum selben Lieferschritt. Egal, wie die Kundin sich entscheidet, nichts steht zwischen ihr und dem Bezahlen.

Rechenbeispiel: Lenas Kontoschritt, vorher und nachher

Vorher begann Lenas Checkout mit einem Anmeldeformular und einem Link "Registrieren" darunter. Die Gastbestellung gab es, aber nur als Zeile in kleiner grauer Schrift ganz unten: "Oder ohne Konto bestellen".

Nachher lautet der Kontoschritt:

Wie möchtest du bestellen? [Als Gast bestellen] Deine Angaben kannst du nach der Bestellung für das nächste Mal speichern. Du hast schon ein Konto? [Anmelden]

Und die Bestätigungsseite bekommt ein freiwilliges Feld dazu: "Speicher deine Angaben, dann geht es nächstes Mal schneller. Du brauchst nur ein Passwort." Darunter drei Gründe: Bestellung verfolgen, frühere Bestellungen ansehen, Lieblingsdüfte nachbestellen.

Geändert haben sich nur die Worte und ihr Platz.

Fehlermeldungen, die Leuten beim Abschließen helfen

Eine Fehlermeldung ist der Moment, in dem ein Formular jemandem sagt, dass etwas nicht stimmt, und der Moment, in dem er am ehesten aufgibt. Höchste Wärme, kein Witz.

Die Hinweise des GOV.UK Design System zu Fehlermeldungen sind die klarsten, die ich kenne, und sie sind frei lesbar.⁷ Sie sind auf Englisch geschrieben, übertragen sich aber gut. Kurz gefasst:

• Sag, was passiert ist und wie man es behebt, in einfacher Sprache.
• Sei konkret. Vermeide allgemeine Meldungen wie "Dieses Feld ist ein Pflichtfeld".
• Verwende dieselben Worte wie die Frage, damit Meldung und Beschriftung zusammenpassen.
• Bei einem leeren Feld gib eine Anweisung ("Gib deinen Vornamen ein"). Bei einer falschen Eingabe beschreib das Problem ("Der Name darf höchstens 35 Zeichen haben").
• Vermeide Wörter wie "ungültig", "gültig", "verboten", "unzulässig" oder "du hast vergessen", und auch "bitte", "Entschuldigung" und "Hoppla".
• Zeig jede Meldung neben ihrem Feld und in einer Zusammenfassung oben, und lösch nie, was die Person schon eingetippt hat.

Baymard zeigt, warum das im Checkout zählt. In ihrem Benchmark verwenden 98 % der Websites allgemeine Fehlermeldungen. In ihren Tests brauchten Leute wegen vager Formulierungen bis zu fünf Minuten, um einfache Fehler zu beheben, und manche gaben ganz auf.⁸ Oft hat eine Website nur eine Meldung pro Feld. Eine Mailadresse ohne "@" und eine mit kaputter Endung bekommen dann dasselbe "Die Mailadresse ist ungültig", obwohl der Code genau weiß, welches Problem vorliegt. Baymard empfiehlt für komplexe Felder wie Kartennummer, Mailadresse und Telefonnummer vier bis sieben konkrete Meldungen, beginnend mit den Fehlern, die am häufigsten auftreten.⁸

Eine Warnung: Auf Formularen für Anmeldung und neues Passwort hilft "zu dieser Mailadresse gibt es kein Konto" einem Angreifer, deine Kundschaft zu finden. Nutz das nur zusammen mit Ratenbegrenzung und einer Obergrenze für Versuche.⁸

Rechenbeispiel: Lenas Fehlermeldungen neu schreiben

Hier vier Meldungen aus Lenas Checkout, vorher und nachher.

• Mailadresse leer gelassen. Vorher: "Pflichtfeld". Nachher: "Gib deine Mailadresse ein, damit ich dir die Bestellbestätigung schicken kann".
• Mailadresse ohne @. Vorher: "Ungültige Mailadresse". Nachher: "Gib eine Mailadresse mit @ ein, zum Beispiel name@example.com".
• Postleitzahl zu kurz. Vorher: "Ungültige Eingabe". Nachher: "Die Postleitzahl ist zu kurz. Eine deutsche Postleitzahl hat fünf Ziffern".
• Kartennummer unvollständig. Vorher: "Zahlung fehlgeschlagen. Fehler 402". Nachher: "Die Kartennummer ist zu kurz. Prüf die lange Nummer auf der Vorderseite deiner Karte".

Jede neue Meldung nennt das Feld, sagt, was nicht stimmt, und sagt, was zu tun ist. Keine gibt der Kundin die Schuld, und keine entschuldigt sich dreimal.

Hilfetext gehört neben die Frage, nie hinein

Manche Fragen brauchen ein wenig Hilfe. Wozu brauchst du meine Telefonnummer? Wo steht die Prüfnummer auf meiner Karte?

Hilfetext, bei GOV.UK hint text genannt, beantwortet genau diesen einen Zweifel in einer kurzen Zeile neben der Beschriftung. Die Empfehlung dort: jeder Hinweis ein einziger kurzer Satz ohne Punkt, nie Links in Hinweisen, freiwillige Felder mit "(optional)" in der Beschriftung kennzeichnen und Pflichtfelder nie mit Sternchen.⁴ Dasselbe Muster sagt: Wisse, wofür du jede Antwort brauchst, frag nur, was du wirklich brauchst, und mach klar, warum du fragst.⁴

Zwei häufige Fehler. Eine Beschriftung, die als Platzhaltertext im Feld steht, verschwindet, sobald jemand tippt. Und Hilfetext erklärt oft das Offensichtliche und übergeht die echte Sorge. "Gib deine Telefonnummer ein" unter einem Feld namens "Telefonnummer" hilft niemandem. "Nur für den Fall, dass der Paketdienst dich nicht findet" hilft sehr.

Baymards Checkoutleitfaden ergänzt das Problem der Länge. Der durchschnittliche untersuchte Checkout hat 19,9 Formularelemente, ein optimierter Ablauf kommt mit 12 aus.⁹ Jedes Feld, das du streichst, ist ein Hinweis, den du nie schreiben musst.

Rechenbeispiel: das Telefonfeld bei Ehrenfelder Kerzen

Lenas Lieferformular verlangte eine Telefonnummer, ohne Erklärung. Lena vermutete, dass Leute dort zögern, weil sie an Werbeanrufe denken.

Ihr Paketdienst braucht die Nummer aber wirklich, wenn eine Zustellung scheitert. Das Feld zu streichen oder freiwillig zu machen, würde sie also etwas kosten. Sie behält es und erklärt es:

Telefonnummer Geht nur an den Paketdienst, falls er deine Adresse nicht findet

Beschriftung oben, Hinweis zwischen Beschriftung und Feld, nichts im Feld selbst. Eine Zeile, ein ehrlicher Grund.

Vertrauen gehört direkt neben die Zahlungsfelder

Der Zweifel ist bei der Zahlung am größten. Die Kundin ist dabei, ihre Kartendaten einem Laden zu geben, den sie vielleicht vor zehn Minuten gefunden hat.

In Baymards Befragung von 1.026 Erwachsenen in den USA aus dem Jahr 2025 gaben 19 % an, in den drei Monaten davor einen Checkout abgebrochen zu haben, weil sie der Website ihre Kartendaten nicht anvertrauen wollten.¹⁰ Ihre Tests haben außerdem etwas gezeigt, das Entwickler überrascht. Leute beurteilen Sicherheit danach, wie die Seite aussieht, nicht danach, wie sie gebaut ist. Auf einer Seite mit HTTPS ist jedes Feld gleich verschlüsselt, und trotzdem empfinden Leute die Kartenfelder als sicherer, wenn sie anders aussehen: ein Rahmen, ein Hintergrund, ein Schlosssymbol, abgesetzt von den Adressfeldern darüber.¹⁰ Baymard merkt an, dass bekannte Marken davon weniger brauchen und neuere oder kleinere Shops am meisten.¹⁰

Das ist Wahrnehmung, also geh vorsichtig damit um. Ein Schloss auf einer unsicheren Website ist eine Lüge. Vertrauen muss wahr sein, konkret, und direkt neben dem stehen, worauf es sich bezieht, nicht im Footer.

In der Nähe des Zahlungsschritts lohnt es sich zu sagen, wenn es stimmt:

• Wer die Karte verarbeitet ("Die Zahlung läuft über den sicheren Checkout deines Kartenanbieters", oder der Name des tatsächlichen Zahlungsdienstleisters).
• Die Gesamtsumme einschließlich Versand, bevor die Kundin auf Bezahlen drückt. In Baymards Liste nennen 12 % der Abbrecher als Grund, dass sie die Gesamtkosten vorab nicht sehen oder berechnen konnten, und 40 % zusätzliche Kosten wie Versand.⁵
• Was passiert, wenn etwas schiefgeht: das Rückgabefenster, in einer Zeile, mit Link auf die vollständigen Bedingungen.

Rechenbeispiel: Lenas Zahlungsschritt

Vorher sahen die Kartenfelder aus wie das Adressformular, die Versandkosten tauchten erst nach der Zahlung auf, und die Logos der Zahlungsarten standen im Footer. Nachher, in dieser Reihenfolge:

1. Eine Übersicht: "2 Kerzen 32,00 €, Versand 3,95 €, Gesamt 35,95 €".
2. Die Kartenfelder in einem eigenen umrahmten Bereich mit hellem Hintergrund, darin ein kleines Schloss und eine Zeile: "Deine Kartendaten gehen direkt an den Zahlungsdienstleister. Ich sehe und speichere sie nie."
3. Unter dem Bereich: "Passt nicht? Unbenutzte Kerzen kannst du innerhalb von 30 Tagen zurückschicken."
4. Der Bezahlbutton (zu seinen Worten im nächsten Abschnitt mehr).

Die Übersicht muss aufgehen: 32,00 € plus 3,95 € sind 35,95 €. Eine Summe, die sich auf dem letzten Bildschirm ändert, ist der schnellste Weg, eine Bestellung zu verlieren. Die Zeile zu den Kartendaten steht nur da, weil sie für Lenas Setup stimmt.

Der Bestellbutton hat in Deutschland eine rechtliche Aufgabe

Hier hört Microcopy auf, Stilfrage zu sein. In Deutschland regelt das die sogenannte Buttonlösung in § 312j des Bürgerlichen Gesetzbuchs (BGB). Bei einem Vertrag im elektronischen Geschäftsverkehr, der Verbraucher zu einer Zahlung verpflichtet, muss der Unternehmer die Bestellsituation so gestalten, dass der Verbraucher mit seiner Bestellung ausdrücklich bestätigt, dass er sich zu einer Zahlung verpflichtet. Läuft die Bestellung über eine Schaltfläche, ist diese Pflicht nur erfüllt, wenn die Schaltfläche gut lesbar mit nichts anderem als den Wörtern "zahlungspflichtig bestellen" oder mit einer entsprechenden eindeutigen Formulierung beschriftet ist.¹¹ Die Folge steht in Absatz 4: Erfüllt der Unternehmer diese Pflicht nicht, kommt der Vertrag gar nicht zustande.¹¹

"Weiter", "Bestätigen" oder "Absenden" auf dem letzten Button sind also nicht nur vage, sie sind ein rechtliches Risiko. Wo genau die Grenze einer "entsprechenden eindeutigen Formulierung" verläuft, ist eine Frage für deine Anwältin, nicht für mich. Der sichere Weg ist der Wortlaut, den das Gesetz selbst vorgibt, und das Wort "nichts anderem" heißt auch: kein Betrag, kein Zusatz auf dem Button. Die Summe gehört direkt darüber.

Rechenbeispiel: Lenas letzten Button auswählen

Lena wägt vier Beschriftungen ab:

• "Weiter". Raus. Es sagt nicht, dass ein Druck darauf eine Zahlungspflicht auslöst.
• "Bestellung abschließen". Raus, aus demselben Grund.
• "Bestellen". Besser, aber vom Bezahlen steht nichts darin.
• "Zahlungspflichtig bestellen". Rein. Es ist der Wortlaut aus § 312j, es lässt keinen Zweifel, und die Gesamtsumme von 35,95 € steht unmittelbar darüber, sodass eine Kundin, die einen anderen Betrag erwartet hat, ihn sieht, bevor sie drückt.

Die Summe über dem Button wird aus dem Warenkorb berechnet, also stimmt sie immer mit der Übersicht überein.

Barrierefreie Worte sind klare Worte

Barrierefreiheit ist keine Schicht über guter Microcopy. Zum größten Teil ist sie gute Microcopy. Die Web Content Accessibility Guidelines (WCAG) 2.1 auf Stufe AA sind der Maßstab, auf dem das meiste Recht ruht, und mehrere ihrer Erfolgskriterien handeln von Worten. Ich nenne sie mit den Namen der deutschen Übersetzung, die das W3C verlinkt.¹²

• 3.3.2 Beschriftungen oder Anweisungen (Stufe A): Wenn ein Inhalt eine Eingabe verlangt, gibt es Beschriftungen oder Anweisungen.¹³
• 3.3.1 Fehlererkennung (Stufe A): Wird ein Eingabefehler automatisch erkannt, wird das fehlerhafte Element benannt und der Fehler in Textform beschrieben.¹⁴ Ein roter Rahmen allein zählt nicht.
• 3.3.3 Fehlerempfehlung (Stufe AA): Weiß das System, wie der Fehler zu beheben ist, sagt es das, außer das würde die Sicherheit untergraben.¹⁵ "Die Kartennummer ist zu kurz" besteht, "Ungültig" hilft nicht.
• 2.5.3 Beschriftung im Namen (Stufe A): Der zugängliche Name eines Bedienelements enthält den Text, der darauf zu sehen ist.¹⁶ Wer per Sprachsteuerung bedient, sagt, was er sieht, und das muss funktionieren.
• 3.3.4 Fehlervermeidung bei rechtlichen und finanziellen Vorgängen (Stufe AA): Eine Eingabe, die zu einer Zahlung verpflichtet, muss umkehrbar sein, auf Fehler geprüft werden oder vor dem Abschluss zur Prüfung und Korrektur angeboten werden.¹⁷

In Deutschland ist das für viele Onlineshops keine Kür mehr. Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 und erfasst Dienstleistungen im elektronischen Geschäftsverkehr, also Websites und Apps, über die Verbraucher einen Vertrag schließen.¹⁸ Ausgenommen sind Kleinstunternehmen, die Dienstleistungen anbieten, also Unternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme.¹⁹ Ob dein Shop darunter fällt, hängt also an seiner Größe. Die guten Gründe für klare Beschriftungen hängen nicht daran.

Zusammen sagen diese Kriterien, was auch GOV.UK und Baymard sagen: sichtbare Beschriftungen, konkrete Fehler in Textform und ein letzter Schritt, auf dem Leute prüfen können, wozu sie zustimmen. Am meisten profitieren zuerst Menschen mit Screenreader, und genauso alle, die an der Bushaltestelle ein Formular auf dem Handy ausfüllen. Mehr zur rechtlichen Seite habe ich in Barrierefreiheit für eCommerce und SaaS aufgeschrieben.

Rechenbeispiel: Lenas Checkout gegen fünf Kriterien prüfen

Lenas Entwickler geht den neuen Checkout mit Screenreader und Sprachsteuerung durch.

1. Jedes Feld hat eine sichtbare Beschriftung, die im Code mit ihm verknüpft ist. Bestanden für 3.3.2.
2. Jeder Fehler steht als Text neben dem Feld und in der Zusammenfassung, nicht nur als roter Rahmen. Bestanden für 3.3.1.
3. Die Meldungen zu Postleitzahl und Karte sagen, wie sich das Problem beheben lässt. Bestanden für 3.3.3.
4. Der gesprochene Befehl "Klick auf Zahlungspflichtig bestellen" drückt den Button. Eine erste Fassung hatte einen Symbolbutton mit dem versteckten Namen "submit form". Das fiel bei 2.5.3 durch und wurde behoben.
5. Artikel, Versand und Gesamtsumme stehen über dem Bestellbutton, mit einem Link "Ändern" für die Adresse. Bestanden für 3.3.4.

Nach WCAG 2.1 AA gebaut, so lässt es sich ehrlich sagen. Nicht "garantiert konform".

Eine Wortänderung messen, ohne dich selbst zu täuschen

Die Geschichte von Spool hat keine Kontrollgruppe, und die meisten Microcopy Geschichten im Netz sind schlechter belegt. Wenn ich Worte ändere, messe ich den Schritt, auf dem sie stehen, mit Analytics nur nach Einwilligung und ohne Bildschirmaufzeichnungen, und vergleiche fair.

Die Messgröße ist eine Schrittrate: Von denen, die einen Schritt erreicht haben, wie viele sind darüber hinausgekommen.

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

Dabei ist $r$ die Schrittrate, $n_{\text{passed}}$ die Zahl der Leute, die über den Schritt hinausgekommen sind, und $n_{\text{reached}}$ die Zahl derer, die ihn erreicht haben. Es ist dieselbe Idee wie eine Conversion Rate (Grundlagen: Verhältnisse und Raten). Wie du jeden Schritt mit einem Event nach Einwilligung zählst, steht in Event Tracking und Consent Mode.

Der faire Vergleich ist ein A/B Test: Die Hälfte sieht den alten Schritt, die Hälfte den neuen, zur selben Zeit, sodass die Saison beide gleich trifft. Dann sagt ein z Test für zwei Anteile, ob der Unterschied größer ist als der Zufall:

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

Dabei sind $p_A$ und $p_B$ die Schrittraten der alten und der neuen Fassung, $n_A$ und $n_B$ die Zahl der Leute, die den Schritt in der jeweiligen Fassung erreicht haben, und $p$ die gepoolte Rate, also alle, die durchgekommen sind, geteilt durch alle, die angekommen sind. Ein $z$ jenseits von etwa $1{,}96$ in eine der beiden Richtungen heißt, dass der Unterschied auf dem 5 % Niveau signifikant ist. Die ganze Erklärung steht in Grundlagen: Hypothesentests, und wie viele Besucher du brauchst, bevor du überhaupt anfängst, in wie viele Daten du wirklich brauchst.

Rechenbeispiel: Lenas Test am Kontoschritt

In einem Monat erreichen 1.200 Kundinnen und Kunden mit Einwilligung den Kontoschritt. Die Hälfte sieht die alte Fassung (A), die andere Hälfte die neue mit der Gastbestellung oben (B).

Schritt eins, die Schrittraten. Fassung A ließ 390 von 600 durch, also $p_A = 390 / 600 = 0{,}65$. Fassung B ließ 468 durch, also $p_B = 468 / 600 = 0{,}78$.

Schritt zwei, die gepoolte Rate: alle Durchgänge geteilt durch alle Ankünfte, $p = 858 / 1{.}200 = 0{,}715$, also $1 - p = 0{,}285$.

Schritt drei, alles in den Test einsetzen:

$$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$$

Dabei sind $0{,}78$ und $0{,}65$ die Werte $p_B$ und $p_A$, $0{,}715$ die gepoolte Rate $p$, $0{,}285$ der Wert $1 - p$, die beiden $600$ sind $n_A$ und $n_B$, und $0{,}0261$ ist der Standardfehler, die Wurzel im Nenner. Ein $z$ von $4{,}99$ liegt weit über $1{,}96$, der Unterschied ist also sehr wahrscheinlich kein Zufall. Die Methode steht in Grundlagen: Hypothesentests.

Schritt vier, was das für Bestellungen heißt. In beiden Fassungen haben 70 % derer, die über den Kontoschritt hinausgekommen sind, auch bezahlt. Fassung A brachte also $390 \times 0{,}70 = 273$ Bestellungen und Fassung B $468 \times 0{,}70 = 327{,}6$, gerundet 328.

Entlang der waagrechten Achse liegen die drei Schritte des Checkouts in ihrer Reihenfolge. Die senkrechte Achse zeigt, wie viele Kundinnen und Kunden noch im Checkout sind, von 600 je Fassung. Die Lücke öffnet sich am Kontoschritt und bleibt bis zur Bestellung offen, weil sich danach nichts geändert hat. Der ganze Gewinn kommt aus dem einen Schritt, an dem sich die Worte geändert haben.

Schritt fünf, das Geld, wenn die neue Fassung für alle 1.200 Kundinnen und Kunden eines Monats gelaufen wäre. Alt: $1{.}200 \times 0{,}65 \times 0{,}70 = 546$ Bestellungen, mal 34 € sind 18.564 €. Neu: $1{.}200 \times 0{,}78 \times 0{,}70 = 655{,}2$, also rund 655 Bestellungen, mal 34 € sind 22.270 €. Der Unterschied beträgt 3.706 € im Monat. Als prozentuale Veränderung der Bestellungen:

$$\Delta\% = \frac{655 - 546}{546} \times 100 = \frac{109}{546} \times 100 = 20{,}0\%$$

Dabei ist $\Delta\%$ die prozentuale Veränderung, $655$ die neue Zahl der Bestellungen im Monat und $546$ die alte (Grundlagen: Prozente). Die 3.706 € würde ich für eine Präsentation vor der Geschäftsführung nicht mal 12 nehmen. Der Dezember eines Kerzenladens hat mit seinem Juli nichts gemein, und die 70 % stammen aus einem einzigen Monat. Ein ehrlicher Bericht sagt: "etwa ein Fünftel mehr Bestellungen, gemessen über einen Monat".

Womit du am Montag anfängst

Nichts davon braucht ein Redesign. In jedem Beispiel oben steckte die Reibung in den Worten, und Worte ändern sich in Tagen. Die Reihenfolge, in der ich arbeite:

1. Zuerst die erzwungene Registrierung abschaffen: Gastbestellung als Button ganz oben, das Konto erst nach der Bestellung.
2. Jeden Button laut vorlesen, und der letzte muss sagen, dass ein Druck darauf zahlungspflichtig ist.
3. Jede Fehlermeldung absichtlich auslösen und die allgemeinen neu schreiben.
4. Dem einen Feld, bei dem Leute zögern, eine ehrliche Hilfezeile geben, oder es streichen.
5. Die vollständige Summe und einen wahren Vertrauenshinweis neben die Kartenfelder stellen.
6. Die fünf WCAG Kriterien mit Screenreader und Sprachsteuerung prüfen.
7. Den geänderten Schritt mit einem Event nach Einwilligung messen und, wo der Traffic reicht, mit einem A/B Test, dessen Größe vorher feststeht.

Nichts davon ist ein Trick. Wenn eine Änderung wirkt, weil sie das Neinsagen schwerer macht, ein vorangekreuztes Kästchen oder ein verstecktes "Nein danke", dann ist das ein Dark Pattern, keine Microcopy. Wo diese Grenze verläuft, habe ich in DSGVO Dark Patterns aufgeschrieben. Die breitere Prüfung von Text, Ablauf, Gestaltung und Tempo steht im Clarity Framework.

Spools Händler hat die 300 Millionen Dollar nicht in einem Wort gefunden. Er hat sie gefunden, indem er Leuten beim Einkaufen zugesehen hat und ihnen dann aus dem Weg gegangen ist. Dieser Teil funktioniert in jeder Größe, auch in einer Kerzenwerkstatt in Ehrenfeld.

Footnotes

1. Jared M. Spool, The $300 Million Button, Center Centre (früher 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. 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

10. Jamie Holst, How Users Perceive Security During the Checkout Flow, Baymard Institute, 2016 mit Daten aus 2023 und 2025, https://baymard.com/blog/perceived-security-of-payment-form

11. Bürgerliches Gesetzbuch (BGB), § 312j Besondere Pflichten im elektronischen Geschäftsverkehr gegenüber Verbrauchern, Abs. 3 und 4, Bundesministerium der Justiz, Gesetze im Internet, https://www.gesetze-im-internet.de/bgb/__312j.html

12. Aktion Mensch e.V. und outline, Richtlinien für barrierefreie Webinhalte (WCAG) 2.1, inoffizielle deutsche Übersetzung, verlinkt auf der Übersetzungsseite des W3C, 15. Juni 2022, https://outline-rocks.github.io/wcag/translations/WCAG21-de/

13. 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

14. 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

15. 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

16. 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

17. 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

18. Bundesministerium der Justiz, Barrierefreiheitsstärkungsgesetz (BFSG) vom 16. Juli 2021, § 1 Abs. 3 Nr. 5, § 2 Nr. 26 und die Fußnote zum Inkrafttreten am 28. Juni 2025, Gesetze im Internet, https://www.gesetze-im-internet.de/bfsg/BJNR297010021.html

19. Bundesministerium der Justiz, Barrierefreiheitsstärkungsgesetz (BFSG), § 2 Nr. 17 Kleinstunternehmen, Gesetze im Internet, https://www.gesetze-im-internet.de/bfsg/__2.html, sowie § 3 Abs. 3, https://www.gesetze-im-internet.de/bfsg/__3.html