Das Clarity Framework: wie ich mit UX, Text und Analytics Reibung aus der Conversion nehme

Interessierte gehen, weil etwas unklar ist

Die meisten Seiten, die nicht konvertieren, scheitern nicht am fehlenden Interesse. Wer dort landet, kam mit Absicht. Und dann stand etwas im Weg. Eine schwammige Überschrift. Ein Formular, das nach dem Budget fragt, bevor es überhaupt Hallo gesagt hat. Ein Button, der genau dann nach unten rutscht, wenn man auf ihn tippen will. Zusammen ergibt das ein leises "heute lieber nicht".

Die Arbeit, solche Hindernisse zu finden und wegzuräumen, nenne ich das Clarity Framework. Es ist meine eigene Art, eine Seite oder einen Ablauf zu prüfen, und es hat vier Ebenen, die ich in dieser Reihenfolge durchgehe:

1. Text: Sagen die Worte, was das ist, für wen es ist und was als Nächstes passiert?
2. Ablauf: Folgt jeder Schritt aus dem vorigen, ohne Sackgassen und ohne Fragen, die zu früh kommen?
3. Gestaltung: Fällt der Blick zuerst auf das Richtige, und kann es wirklich jeder lesen?
4. Tempo und Technik: Lädt die Seite schnell, reagiert sie sofort, und bleibt sie ruhig stehen?

Die Reihenfolge ist kein Zufall. Tempo lässt sich bequem messen, deshalb fangen Agenturen gern dort an. Eine Seite, die in einer Sekunde lädt und nichts Brauchbares sagt, enttäuscht die Leute allerdings nur schneller. Ich beginne bei den Worten, denn dort sitzt in den Abläufen, die ich prüfe, der Großteil der Reibung.

Um die vier Ebenen herum stehen zwei Gewohnheiten: vorher wissen, was der Besucher eigentlich vorhat, und hinterher messen, ob die Änderung geholfen hat.

Rechenbeispiel: der Ablauf, um den es geht

Damit das greifbar bleibt, begleitet uns ein erfundenes Unternehmen durch den ganzen Text. Rheinplan ist eine kleine Softwarefirma aus Köln. Sie verkauft eine Dienstplan SaaS an inhabergeführte Zahnarztpraxen, für 149 € im Monat pro Praxis. Gründerin Amara führt sie mit zwei Entwicklern. Jeder neue Kunde startet mit einer Live Demo, der Ablauf für die Demoanfrage ist also die gesamte Vertriebspipeline.

So sieht der Ablauf aus, den Amara übernommen hat:

1. Die Demoseite öffnet mit der Überschrift "Workforce Optimierung für moderne Praxen", darunter ein Video, das von selbst startet.
2. Auf dem Button steht "Anfrage absenden".
3. Das Formular hat 11 Pflichtfelder: Name, Mailadresse, Telefon, Firma, Position, Praxisgröße, Anzahl der Behandlungsstühle, aktuelle Software, Budget, "Wie hast du von uns erfahren?" und ein Nachrichtenfeld. Die Beschriftungen stehen als graue Platzhalter in den Feldern.
4. Nach dem Absenden kommt "Danke, wir melden uns."
5. Innerhalb von zwei Werktagen schreibt jemand eine Mail, um einen Termin abzustimmen.
6. Die Demo findet statt. Oder eben nicht.

Im Oktober kamen 2.400 Besucher, die der Analyse zugestimmt hatten, auf die Demoseite. 40 von ihnen saßen am Ende in einer Demo. Alle Zahlen in diesem Beispiel sind erfunden, das Unternehmen auch. Jede Ebene weiter unten greift diese Zahlen wieder auf.

Zuerst klären, was der Besucher vorhat

Eine Seite kann nicht allgemein klar sein, nur klar für jemanden, der etwas Bestimmtes erledigen will. Bevor ich also ein einziges Wort anfasse, schreibe ich in einem Satz auf, was die Person auf dieser Seite vorhat und was sie wissen muss, bevor sie es tut.

Klingt selbstverständlich und wird ständig übersprungen. Eine Demoseite ist oft für die Wunschliste des Vertriebs geschrieben (Lead qualifizieren, Budget abfragen, Quelle erfassen), nicht für die Frage des Besuchers. Und die lautet meistens: "Löst das mein Problem, und worauf lasse ich mich hier ein?"

Um das herauszufinden, schau dir die Anzeige oder die Suche an, über die die Leute kommen, lies, was bestehende Kunden bei der ersten Kontaktaufnahme geschrieben haben, und frag nach.

Rechenbeispiel: der eine Satz für Rheinplan

Amara liest die Nachrichtenfelder der letzten 20 Demoanfragen. Drei Sorgen tauchen immer wieder auf: "Wir machen den Dienstplan noch in Excel", "Wie lange dauert die Einrichtung?" und "Kommt das mit Teilzeitkräften in der Prophylaxe klar?". Die Anzeige, über die die meisten kommen, lautet "Dienstpläne für Zahnarztpraxen, ohne Excel".

Der Satz heißt also: Eine Praxismanagerin, die es leid ist, den Dienstplan in Excel zu basteln, will in einem kurzen Gespräch sehen, ob das hier mit ihren schwierigen Schichten klarkommt, ohne sich auf irgendetwas festzulegen. Ein Budgetfeld dient diesem Satz nicht. Eine Demo von 20 Minuten mit klarem Ablauf schon.

Ebene eins: ein Text, der sagt, was es ist

Webseiten werden nicht gelesen, sie werden überflogen. Jakob Nielsen stellte in frühen Studien der Nielsen Norman Group fest, dass 79 % der Testpersonen eine neue Seite immer überflogen und nur 16 % Wort für Wort lasen.¹ Eine spätere Auswertung echter Surfdaten kam zu dem Schluss, dass Menschen bei einem durchschnittlichen Seitenbesuch höchstens 28 % der Wörter lesen können, wahrscheinlicher sind 20 %.²

Überschrift, Unterzeile, Button und Beschriftungen tragen also die ganze Last. Dieselbe Studie von 1997 verglich Varianten einer Website. Knapper Text verbesserte die gemessene Gebrauchstauglichkeit um 58 %, überfliegbarer Text um 47 % und sachlicher Text ohne Werbesprache um 27 %. Alles zusammen schnitt 124 % besser ab als das Original.¹ Die Studie ist alt, die genauen Prozentwerte sehe ich deshalb als Geschichte. Die Richtung hat sich in jedem Ablauf bestätigt, an dem ich seither gearbeitet habe.

Was ich auf der Textebene prüfe:

• Die Überschrift nennt die Sache und die Zielgruppe in den Worten des Besuchers, nicht in der Kategorie, die das Unternehmen gern besetzen würde.
• Der Button sagt, was als Nächstes passiert. "Absenden" sagt nichts. "Demo buchen, 20 Minuten" sagt was, wie lange und welcher Art.
• Der eigentliche Zweifel des Besuchers (Zeit, Kosten, Verbindlichkeit) wird direkt neben der Aktion beantwortet.

Ausführlicher über die kleinen Worte habe ich in einem eigenen Beitrag über Microcopy und Conversion geschrieben.

Rechenbeispiel: neue Worte für die Demoseite

Eine Praxismanagerin, die "Workforce Optimierung für moderne Praxen" überfliegt, muss erst übersetzen: Optimierung wovon? Amara schreibt die Seite in den Worten ihrer Anzeige und ihrer Kunden neu:

• Überschrift: "Dienstpläne für Zahnarztpraxen. Ohne Excel."
• Unterzeile: "Teilzeit in der Prophylaxe, Vertretungen und Urlaub in einem Plan. Die meisten Praxen sind an einem Nachmittag eingerichtet."
• Button: "Demo buchen, 20 Minuten".
• Die Zeile unter dem Button: "Amara zeigt es dir live. Kein Vertrag, keine Karte."

Raus flogen "Workforce", "Optimierung" und "modern". Rein kamen die Begriffe des Besuchers, eine Zeitangabe und ein Name.

Ebene zwei: ein Ablauf, der nie zu früh fragt

Klarheit im Ablauf ist eine Frage der Reihenfolge. Jeder Schritt folgt aus dem vorigen, behält, was der Besucher schon gesagt hat, und fragt nur, was jetzt nötig ist. Die meiste Reibung, die ich hier finde, ist eine Frage, die zu früh kommt.

Die Forschung zu Formularen ist ungewöhnlich einig. Die wichtigste Empfehlung der Nielsen Norman Group für Formulare lautet schlicht: kurz halten. Felder, die sich ableiten, später erfragen oder ganz weglassen lassen, fliegen raus.³ Dieselben Empfehlungen verlangen eine Spalte, Beschriftungen nah am Feld, höchstens ein oder zwei optionale Felder, deutlich als optional markiert, und Formatvorgaben, die vorher genannt werden.³ Sie warnen außerdem davor, die Beschriftung als Platzhalter ins Feld zu setzen. Der Hinweis verschwindet, sobald jemand tippt. Das belastet das Gedächtnis, erschwert das Prüfen der Eingaben und noch mehr das Korrigieren von Fehlern, und manche Screenreader lesen ihn gar nicht vor.⁴

Das Baymard Institute, das die Nutzbarkeit von Checkouts vergleicht, findet im eCommerce dasselbe Muster. In seinem Benchmark zeigt der durchschnittliche Checkout standardmäßig 23,48 Formularelemente, davon 14,88 Eingabefelder. Laut seiner Forschung reichen für einen Checkout 12 bis 14 Elemente, also sieben bis acht Felder.⁵ Von den Käufern, die eine Bestellung aus einem anderen Grund als bloßem Stöbern abgebrochen haben, gingen 18 %, weil die Seite ein Kundenkonto verlangte, und 17 %, weil der Checkout zu lang oder zu kompliziert war.⁵ Ein Demoformular ist kein Checkout, aber die Lehre gilt trotzdem: Jedes Feld kostet ein bisschen.

Zwei Werkzeuge machen einen Ablauf kürzer, ohne dass Information verloren geht. Das erste ist schrittweise Offenlegung, bei der Nielsen Norman Group "progressive disclosure": zuerst die wenigen Dinge zeigen, die die meisten brauchen, den Rest erst auf Nachfrage.⁶ Das zweite ist Aufschieben: die Frage später stellen, wenn die Antwort gebraucht wird und der Besucher dir schon vertraut. Barrierefreiheit zieht in dieselbe Richtung. Die Web Content Accessibility Guidelines (WCAG) 2.1 verlangen auf Stufe A Beschriftungen oder Anweisungen überall dort, wo eine Eingabe erwartet wird.⁷ Auf Stufe AA müssen Felder, die Angaben über die Person selbst abfragen, ihren Zweck im Code ausweisen. In der Praxis heißt das: das HTML Attribut autocomplete, damit der Browser sie ausfüllen kann.⁸ Ein Formular nach diesem Standard ist für alle schneller.

Rechenbeispiel: von 11 Feldern auf vier

Amara nimmt sich jedes der 11 Felder vor und stellt eine Frage: Brauche ich das, bevor die Demo gebucht werden kann?

Feld	Zum Buchen nötig?	Was damit passiert
Name	Ja	Bleibt
Mailadresse	Ja	Bleibt, beschriftet als "Geschäftliche Mailadresse"
Name der Praxis	Ja	Bleibt, ersetzt "Firma"
Zahl der Mitarbeitenden	Ja, danach richtet sich die Demo	Bleibt, als vier Auswahlknöpfe
Telefon	Nein	Kommt im Kalenderschritt, als optional markiert
Position	Nein	Wird in der Demo gefragt
Praxisgröße, Anzahl der Behandlungsstühle	Nein	Durch die Zahl der Mitarbeitenden abgedeckt
Aktuelle Software	Nein	Wird in der Demo gefragt
Budget	Nein	Gestrichen, der Preis steht auf der Preisseite
Wie hast du von uns erfahren?	Nein	Gestrichen, das verrät schon der Kampagnenlink
Nachricht	Nein	Ein optionales Feld im Kalenderschritt

Die vier Felder bekommen sichtbare Beschriftungen darüber, eine Spalte und autocomplete Attribute. Dann die größte Änderung: Nach dem Absenden öffnet sich auf dem nächsten Bildschirm ein Kalender, und der Besucher wählt direkt dort einen Termin. Das Mail Pingpong über zwei Tage fällt weg.

Ebene drei: der Blick landet auf dem Richtigen

Klarheit in der Gestaltung heißt, dass die Rangordnung der Seite den Prioritäten des Besuchers folgt. Das Wichtigste ist das Auffälligste. Pro Bildschirm gibt es eine Hauptaktion. Was zusammengehört, steht zusammen, was nicht zusammengehört, bekommt Abstand. Und alles kann von allen gelesen werden.

Der letzte Punkt ist keine Kür. Das WCAG 2.1 Erfolgskriterium 1.4.3 verlangt auf Stufe AA ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text, den es als mindestens 18 Punkt oder 14 Punkt fett definiert.⁹ Hellgrauer Text auf Weiß, der Liebling vieler Designsysteme, fällt da öfter durch, als man denkt. Dieselben Formularempfehlungen verlangen, dass Fehler nicht nur über Farbe angezeigt werden, sondern auch über Umrandung, Text und Schriftstärke, damit sie niemand übersieht.³

Für das Kontrastverhältnis hat der Standard eine exakte Definition:¹⁰

$$C = \frac{L_1 + 0{,}05}{L_2 + 0{,}05}$$

Dabei ist $C$ das Kontrastverhältnis, von 1 (kein Kontrast) bis 21 (Schwarz auf Weiß). $L_1$ ist die relative Leuchtdichte der helleren Farbe und $L_2$ die der dunkleren, jeweils eine Zahl von 0 für das tiefste Schwarz bis 1 für das hellste Weiß. Die $0{,}05$, die auf beiden Seiten dazukommen, stehen für das Licht, das ein echter Bildschirm reflektiert, und halten das Verhältnis endlich, wenn die dunklere Farbe reines Schwarz ist. Es ist ein Verhältnis zweier Größen wie jedes andere (Grundlagen: Verhältnisse und Raten).

Rechenbeispiel: das Platzhaltergrau

Amaras altes Formular zeigte seine Beschriftungen als Platzhalter in einem hellen Grau, #9ca3af, auf einem weißen Feld. Weiß hat eine relative Leuchtdichte von 1. Rechnet man das Grau mit der Formel des Standards durch, kommt man auf eine relative Leuchtdichte von etwa $0{,}364$. Also:

$$C = \frac{1 + 0{,}05}{0{,}364 + 0{,}05} = \frac{1{,}05}{0{,}414} \approx 2{,}54$$

Dabei ist $C$ das Kontrastverhältnis des grauen Textes auf Weiß, $1$ die Leuchtdichte des weißen Hintergrunds, $0{,}364$ die Leuchtdichte des Graus und $0{,}05$ dieselbe Konstante wie oben. Mit 2,54:1 liegt es weit unter den 4,5:1, die normaler Text braucht. Die neuen Beschriftungen stehen außerhalb der Felder in #52525b, einem dunklen Grau mit einer Leuchtdichte von etwa $0{,}086$. Das ergibt $1{,}05 / 0{,}136 \approx 7{,}73$, bequem über der Grenze (Grundlagen: Verhältnisse und Raten).

Zwei weitere Korrekturen. Die alte Seite hatte zwei gleich laute Buttons, "Anfrage absenden" und "Broschüre herunterladen". Die Broschüre wird zu einem dezenten Textlink, damit der Demobutton die einzige Hauptaktion ist. Und die Fehlermeldungen an den Feldern, bisher nur ein dünner roter Rahmen, bekommen einen Satz: "Trag bitte deine geschäftliche Mailadresse ein, damit ich dir die Kalendereinladung schicken kann." Dazu eine Umrandung am Feld und fetten Text.

Ebene vier: Tempo und Stabilität sind auch Klarheit

Eine Seite, die ihren Inhalt langsam zeigt, langsam reagiert oder sich bewegt, während man liest, ist im wörtlichsten Sinn unklar.

Googles Core Web Vitals machen alle drei messbar. Largest Contentful Paint (LCP) misst, wie schnell der Hauptinhalt sichtbar wird. Interaction to Next Paint (INP) misst, wie schnell die Seite auf Klicks, Tippen und Tastendrücke reagiert. Cumulative Layout Shift (CLS) misst, wie stark sich Inhalte während der Nutzung unerwartet verschieben.¹¹ Die Grenzwerte, gemessen am 75. Perzentil echter Seitenaufrufe und getrennt nach Mobilgeräten und Desktop, sind:

Messwert	Gut	Schlecht
LCP	2,5 Sekunden oder weniger	über 4,0 Sekunden
INP	200 Millisekunden oder weniger	über 500 Millisekunden
CLS	0,1 oder weniger	über 0,25

Alles dazwischen gilt als verbesserungswürdig.¹²¹³¹⁴ Das 75. Perzentil bedeutet, dass drei von vier Besuchen den Grenzwert erreichen müssen. Ein schneller Laptop im Büro beweist also wenig. Google benennt die Kosten bei CLS ganz direkt: Eine Verschiebung kann dazu führen, dass jemand den falschen Link oder Button erwischt, und das Beispiel dort ist ein Nutzer, der eine große Bestellung bestätigt, die er eigentlich stornieren wollte.¹⁴ Tiefer in die Messwerte gehe ich im Beitrag über Core Web Vitals und User Experience.

Rechenbeispiel: das Video und der springende Kalender

Amara lässt die Seite ihre Core Web Vitals aus echten Besuchen als Event mit Einwilligung melden. Auf dem Smartphone hat die Demoseite einen LCP von 4,3 Sekunden am 75. Perzentil, also schlecht. Das größte Element ist das selbststartende Video ganz oben. Der CLS liegt bei 0,31, ebenfalls schlecht, weil ein Chat Widget spät nachlädt und den Button genau dann nach unten schiebt, wenn die Leute danach greifen.

Die Korrekturen sind unspektakulär, und das ist meistens ein gutes Zeichen:

1. Aus dem Video wird ein Standbild mit Play Button. Die Videodatei lädt erst, wenn jemand auf Play drückt.
2. Das Chat Widget bekommt seinen Platz im Layout reserviert, bevor es lädt, damit darunter nichts verrutscht.
3. Der neue Kalenderschritt bekommt eine feste Höhe, solange die Termine laden, aus demselben Grund.

Im Monat darauf liegt der LCP auf dem Smartphone bei 2,1 Sekunden und der CLS bei 0,02. Beides gut. Der INP lag schon vorher bei 140 Millisekunden und bleibt dort.

Messen, was sich geändert hat, ohne jemandem zuzuschauen

Jede Änderung oben ist eine Vermutung, bis sie gemessen ist. Session Recordings oder Heatmaps nutze ich dafür nicht. Sie beobachten den Leser, statt ihn zu respektieren, sie passen schlecht zu einem Datenschutzversprechen, und nach meiner Erfahrung liefern sie Bilder, die selten eine Entscheidung ändern. In Deutschland kommt das Recht dazu. Schon das Speichern oder Auslesen von Informationen auf dem Gerät des Besuchers braucht nach § 25 TDDDG eine Einwilligung, es sei denn, es ist unbedingt nötig, um einen Dienst bereitzustellen, den der Nutzer ausdrücklich gewünscht hat. Eine Ausnahme für Statistik kennt das Gesetz nicht.¹⁵ Und eine Aufzeichnung dessen, was ein einzelner, über eine Online Kennung identifizierbarer Besucher tut, ist eine Verarbeitung personenbezogener Daten, die nach der DSGVO eine Rechtsgrundlage braucht.¹⁶

Stattdessen nutze ich vier Dinge.

1. Events mit Einwilligung, eines pro Schritt, der zählt. Nichts feuert, bevor der Besucher zustimmt. Wie ich das aufsetze, steht im Beitrag über Event Tracking und Consent Mode.
2. Schrittraten, die aus einem vagen "die Conversion ist niedrig" ein "die meisten geben zwischen Formularstart und Absenden auf" machen.
3. Eine kurze Frage an echte Menschen, im richtigen Moment. Eine Frage beantwortet das Warum, das kann kein Event.
4. A/B Tests, wo der Traffic reicht, mit einer Stichprobengröße, die vor dem Start feststeht.

Die Schrittrate ist das nützlichste davon:

$$r_k = \frac{n_k}{n_{k-1}}$$

Dabei ist $r_k$ die Rate von Schritt $k$, $n_k$ die Zahl der Leute, die Schritt $k$ abgeschlossen haben, und $n_{k-1}$ die Zahl derer, die den Schritt davor abgeschlossen haben und damit überhaupt die Chance auf Schritt $k$ hatten (Grundlagen: Verhältnisse und Raten).

Die Gesamtconversion des Ablaufs ist dann das Produkt der Schrittraten:

$$R = r_1 \times r_2 \times \cdots \times r_K$$

Dabei ist $R$ der Anteil der Leute am Anfang des Ablaufs, die das Ende erreichen, $r_1$ bis $r_K$ sind die Schrittraten und $K$ die Zahl der Schritte. Das Multiplizieren funktioniert, weil jede Rate ein Anteil derer ist, die den Schritt davor überstanden haben. Genau das ist die Multiplikationsregel für "erst das und dann das" (Grundlagen: Wahrscheinlichkeit). Ein schwacher Schritt irgendwo drückt das ganze Produkt nach unten, deshalb schaue ich zuerst auf den schwächsten.

Eine Einschränkung: Events mit Einwilligung zählen nur die Leute, die der Analyse zugestimmt haben. Zwei Monate zu vergleichen ist nur fair, wenn die Zustimmungsrate ungefähr gleich geblieben ist.

Rechenbeispiel: der Oktober Funnel von Rheinplan

Ausgehend von den 2.400 Besuchern mit Einwilligung, die im Oktober die Demoseite erreicht haben:

Schritt	Personen	Schrittrate
Demoseite erreicht	2.400
Formular begonnen	600	600 / 2.400 = 25,0 %
Formular abgeschickt	132	132 / 600 = 22,0 %
Termin per Mail vereinbart	66	66 / 132 = 50,0 %
An der Demo teilgenommen	40	40 / 66 = 60,6 %

Die Gesamtrate ist:

$$R = 0{,}250 \times 0{,}220 \times 0{,}500 \times 0{,}606 \approx 0{,}0167$$

Dabei ist $R$ der Anteil der Besucher der Demoseite, die an einer Demo teilgenommen haben, rund 1,67 %, und die vier Faktoren sind die Schrittraten aus der Tabelle in ihrer Reihenfolge (Grundlagen: Wahrscheinlichkeit). Zwei Schritte fallen auf. Nur 22 % derer, die das Formular begonnen haben, haben es auch abgeschickt, und die Hälfte von denen hat nie einen Termin vereinbart.

Dann fragt Amara nach. Die Dankeseite bekommt eine optionale Frage, "Was hätte dich heute fast vom Buchen abgehalten?", und sie fragt die nächsten zehn Praxismanagerinnen und Praxismanager direkt im Demotermin. Die Antworten wiederholen sich: "Ich wusste nicht, wie lange die Demo dauert", "Warum wollt ihr mein Budget, bevor ich überhaupt etwas gesehen habe?" und "Ich habe vergessen, auf die Mail zu antworten". Das erste ist ein Textproblem, die anderen beiden sind Ablaufprobleme. Die Zahlen haben gezeigt, wo. Die Menschen haben gesagt, warum.

Die Änderung testen, wenn der Traffic reicht

Ein Vorher Nachher Vergleich zweier Monate kann in die Irre führen, denn Monate sind verschieden. Wenn der Traffic da ist, sagt dir ein A/B Test ehrlich, ob eine Änderung wirkt: Die Hälfte der Besucher sieht die alte Version, die andere Hälfte gleichzeitig die neue, und der Unterschied wird darauf geprüft, ob er Zufall sein könnte.

Wie viel Traffic du brauchst, legst du vor dem Test fest, nicht danach. Für einen Test zweier Raten brauchst du pro Version ungefähr so viele Personen:

$$n = \frac{(z_{\alpha/2} + z_{\beta})^2 \left[p_1(1-p_1) + p_2(1-p_2)\right]}{(p_1 - p_2)^2}$$

Dabei ist $n$ die Zahl der Personen, die du pro Version brauchst, $z_{\alpha/2}$ ist 1,96 für ein Signifikanzniveau von 5 %, $z_{\beta}$ ist 0,84 für eine Teststärke von 80 %, $p_1$ ist die aktuelle Rate und $p_2$ die kleinste verbesserte Rate, die sich zu erkennen lohnt (Grundlagen: Stichprobengröße). Wähle $p_2$ als die kleinste Änderung, die dir wichtig wäre, nicht als die, auf die du hoffst. Hoffnung macht Tests zu kurz. Wie viele Daten welche Frage braucht, erkläre ich in Wie viele Daten brauchst du wirklich?

Rechenbeispiel: das kurze Formular im Test

Amara testet das Formular mit vier Feldern gegen das mit 11 Feldern, und zwar bei den Leuten, die das Formular beginnen. Die aktuelle Abschlussrate liegt bei 22 %. Sie legt fest, dass 28 % die kleinste Verbesserung ist, für die sich die Änderung lohnt. Eingesetzt:

$$n = \frac{(1{,}96 + 0{,}84)^2 \left[0{,}22 \times 0{,}78 + 0{,}28 \times 0{,}72\right]}{(0{,}28 - 0{,}22)^2} = \frac{7{,}84 \times 0{,}3732}{0{,}0036} \approx 813$$

Dabei ist $n$ die Zahl der Formularstarts, die pro Version nötig sind, $1{,}96$ und $0{,}84$ sind die Werte für 5 % Signifikanz und 80 % Teststärke, $0{,}22$ ist die aktuelle Abschlussrate, $0{,}28$ die kleinste verbesserte Rate, die sich zu erkennen lohnt, und $0{,}78$ und $0{,}72$ sind jeweils eins minus die Rate (Grundlagen: Stichprobengröße). Bei rund 600 Formularstarts im Monat, auf zwei Versionen verteilt, braucht sie knapp drei Monate. Sie schreibt das Enddatum auf und schaut vorher nicht auf das Ergebnis.

Am Ende hat jede Version 820 Formularstarts. Das alte Formular haben 180 abgeschickt (21,95 %), das neue 330 (40,24 %). Den Unterschied prüft sie mit einem Test für zwei Anteile:

$$z = \frac{p_2 - p_1}{\sqrt{p(1-p)\left(\frac{1}{n_1} + \frac{1}{n_2}\right)}} = \frac{0{,}4024 - 0{,}2195}{\sqrt{0{,}3110 \times 0{,}6890 \times \left(\frac{1}{820} + \frac{1}{820}\right)}} \approx \frac{0{,}1829}{0{,}0229} \approx 8{,}0$$

Dabei ist $z$ die Teststatistik, $p_1$ und $p_2$ sind die Abschlussraten des alten und des neuen Formulars, $n_1$ und $n_2$ die Formularstarts pro Version und $p$ die gepoolte Rate, $510 / 1.640 \approx 0{,}311$, also die Abschlussrate beider Gruppen zusammen (Grundlagen: Hypothesentests). Ein $z$ von 8,0 liegt weit jenseits der 1,96, die auf dem 5 % Niveau nötig sind. Das kurze Formular ist besser, und das ist kein Zufall.

Kleine Websites können nicht immer testen: Bei 50 Formularstarts im Monat würde das Jahre dauern. Dann setze ich die Änderung um, nenne das Ergebnis ehrlich einen Vorher Nachher Vergleich und beobachte die Schrittrate über einige Monate statt über ein paar Tage.

Der Kölner Ablauf, vorher und nachher

Nach dem Test setzt Amara alles um: die neuen Worte, das Formular mit vier Feldern, den Kalender auf dem nächsten Bildschirm, das Standbild und den reservierten Platz. Hier ein vergleichbarer Monat danach, wieder mit 2.400 Besuchern mit Einwilligung auf der Demoseite, neben dem Oktober.

Schritt	Oktober	Nach den Änderungen
Formular begonnen	600 (25,0 %)	720 (30,0 %)
Formular abgeschickt	132 (22,0 %)	288 (40,0 %)
Termin gebucht	66 (50,0 %)	179 (62,2 %)
An der Demo teilgenommen	40 (60,6 %)	108 (60,3 %)

Die waagerechte Achse zeigt die vier Schritte des Ablaufs, jeweils als Paar: Der erste Balken eines Paars ist der Oktober, der zweite, hervorgehobene, der Monat nach den Änderungen. Die senkrechte Achse ist die Schrittrate, also der Anteil derer, die den Schritt davor erreicht und diesen hier abgeschlossen haben. Die Erkenntnis liegt darin, wo sich etwas bewegt hat. Der größte Sprung ist beim Abschicken des Formulars, von 22 % auf 40 %, genau die Formularänderung, die der Test schon bestätigt hatte. Das Buchen stieg von 50 % auf 62,2 %, weil der Kalender den Mailwechsel ersetzt hat. Der Formularstart stieg mit den neuen Worten ein wenig. Die Teilnahme hat sich gar nicht bewegt, und auch das ist nützlich: Nichts, was Amara geändert hat, hat sie berührt. Wenn sie mehr Leute in die Demos bringen will, ist das ein anderes Problem, eines für Erinnerungen, nicht für die Klarheit der Seite.

Multipliziert man die neuen Schrittraten, ergibt das $0{,}300 \times 0{,}400 \times 0{,}622 \times 0{,}603 \approx 0{,}045$. Jetzt nehmen also 4,5 % der Besucher der Demoseite an einer Demo teil, gegenüber 1,67 % vorher: 108 Demos im Monat statt 40. Die Zahlen sind erfunden, und ein echter Ablauf bewegt sich selten so stark auf einmal. Die Lehre steckt in der Form: Ein oder zwei Schritte tragen den Großteil des Gewinns.

Die Prüfung, Schritt für Schritt

So läuft die ganze Prüfung bei mir ab, von der ersten Frage bis zur Entscheidung. Die vier Ebenen stehen in der Mitte, die Messung legt sich darum.

Die Messung kommt vor den Ebenen, damit ich den Schritt repariere, der am meisten verliert, und nicht den, den ich am spannendsten finde. Die Frage an echte Menschen kommt vor der Prüfung, damit sie bei deren Worten anfängt und nicht bei meinen. Und die Schleife endet nie: Sobald der schwächste Schritt repariert ist, ist ein anderer der schwächste.

Was Klarheit nicht ist

Klarheit ist kein Trick. Kein Countdown, keine vorgetäuschte Knappheit, kein vorab angekreuztes Häkchen. Wenn eine "Verbesserung" nur funktioniert, weil das Neinsagen schwerer wird, ist das keine Klarheit, sondern ein Dark Pattern, und in Deutschland und der EU kann das ein rechtliches Problem sein, nicht nur ein moralisches. Über diese Grenze habe ich in DSGVO Dark Patterns geschrieben.

Klarheit ist auch kein Redesign. Amaras Seite hat ihre Farben, ihr Layout und ihr Logo behalten. Das meiste war in Tagen erledigt. Nach meiner Erfahrung ist das typisch: Teuer an einem Conversion Problem ist nicht die Lösung, sondern die Zeit, in der niemand weiß, wo das Problem eigentlich steckt.

Die Methode passt auf eine Postkarte. Wissen, was der Besucher vorhat. Jeden Schritt zählen, mit Einwilligung. Ein paar echte Menschen nach dem Warum fragen. Dann Worte, Reihenfolge, Gestaltung und Tempo durchgehen und das ändern, was im Weg steht.

Footnotes

1. Jakob Nielsen, How Users Read on the Web, Nielsen Norman Group, 1997, https://www.nngroup.com/articles/how-users-read-on-the-web/

2. Jakob Nielsen, How Little Do Users Read?, Nielsen Norman Group, 2008, https://www.nngroup.com/articles/how-little-do-users-read/

3. Kathryn Whitenton, Website Forms Usability: Top 10 Recommendations, Nielsen Norman Group, 2016, https://www.nngroup.com/articles/web-form-design/

4. Katie Sherwin, Placeholders in Form Fields Are Harmful, Nielsen Norman Group, 2014, https://www.nngroup.com/articles/form-design-placeholders/

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

6. Jakob Nielsen, Progressive Disclosure, Nielsen Norman Group, 2006, https://www.nngroup.com/articles/progressive-disclosure/

7. W3C, Understanding Success Criterion 3.3.2: Labels or Instructions, Web Content Accessibility Guidelines 2.1 (englisches Original, eine autorisierte deutsche Übersetzung von WCAG 2.1 gibt es nicht), 2018, https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html

8. W3C, Understanding Success Criterion 1.3.5: Identify Input Purpose, Web Content Accessibility Guidelines 2.1, 2018, https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html

9. W3C, Understanding Success Criterion 1.4.3: Contrast (Minimum), Web Content Accessibility Guidelines 2.1, 2018, https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html

10. W3C, Web Content Accessibility Guidelines (WCAG) 2.1, Glossareinträge contrast ratio und relative luminance, W3C Recommendation, 2018, https://www.w3.org/TR/WCAG21/

11. Philip Walton, Web Vitals, web.dev, Google, deutsche Fassung, 2024, https://web.dev/articles/vitals?hl=de

12. Philip Walton und Barry Pollard, Largest Contentful Paint (LCP), web.dev, Google, deutsche Fassung, 2025, https://web.dev/articles/lcp?hl=de

13. Jeremy Wagner und Barry Pollard, Interaction to Next Paint (INP), web.dev, Google, deutsche Fassung, 2025, https://web.dev/articles/inp?hl=de

14. Philip Walton und Milica Mihajlija, Cumulative Layout Shift (CLS), web.dev, Google, deutsche Fassung, 2023, https://web.dev/articles/cls?hl=de

15. Bundesministerium der Justiz, § 25 TDDDG, Schutz der Privatsphäre bei Endeinrichtungen, gesetze-im-internet.de, 2024, https://www.gesetze-im-internet.de/ttdsg/__25.html

16. Europäische Union, Verordnung (EU) 2016/679 (DSGVO), Art. 4 Nr. 1 und Art. 6, Amtsblatt der Europäischen Union, 2016, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679