Es war ein Mittwoch Nachmittag im März, als Sarah, eine Senior Designerin bei einem skandinavischen Fintech-Unternehmen, in einer Besprechung saß und etwas Seltsames beobachtete. Auf dem Bildschirm vor ihr kämpfte ein 34-jähriger Benutzer – eine Person, die perfekt zu ihrer Zielgruppe passte – mit etwas, das fünf Sekunden hätte dauern sollen. Nach drei Minuten gab er auf.

Das Problem? Ein Button.

Nicht irgendein Button. Ein Button, über den das Designteam wochenlang diskutiert hatte, in Figma verfeinert, in zwei Varianten A/B getestet und schließlich nach sorgfältiger Überlegung implementiert. Ein Button, der professionell aussah. Modern. Sauber.

Aber für den Benutzer sah er aus wie nichts. Grau auf Grau. Wie ein Platzhalter. Wie etwas, das man nicht anklicken konnte.

Sechs von acht Testpersonen gaben genau an derselben Stelle auf. Das Unternehmen hatte vier Monate damit verbracht, einen Onboarding-Prozess zu entwickeln, den 75 % der Benutzer nie abschlossen. Und niemand hatte davon gewusst – bis Sarah acht Benutzer für einen Nachmittag buchte.

Die Kosten für die Änderung der Farbe des Buttons? Ein paar Stunden Entwicklungszeit. Der Wert der Änderung? Ein Anstieg der abgeschlossenen Anmeldungen um 34 %. Das entspricht für dieses Unternehmen etwa drei Millionen Kronen an jährlich wiederkehrenden Einnahmen.

Dies ist die Geschichte, warum die meisten Unternehmen kein Designproblem haben. Sie haben ein Timingproblem.

Das Paradoxon des perfekten Designs

Als Frank Gehry das Guggenheim-Museum in Bilbao entwarf, baute er zuerst Hunderte von physischen Modellen. Kleine, primitive, hässliche Modelle aus Pappe und Klebeband. Er testete Lichtzufuhr. Wege. Blickwinkel. Lange bevor die erste Schaufel den Boden berührte, waren bereits Tausende kleiner Entscheidungen getroffen und verworfen worden.

Wir verstehen intuitiv, dass dies bei Gebäuden der Fall ist. Ein Architekt, der ohne Modelle zu bauen beginnt, ist entweder ein Genie oder ein Idiot, und die Chancen stehen, dass er letzteres ist.

Aber wenn es um digitales Design geht, passiert etwas Seltsames. Smarte Menschen – Menschen, die niemals ein Sofa kaufen würden, ohne vorher darauf zu sitzen – bauen ganze Produkte basierend auf Annahmen. Sie diskutieren in Konferenzräumen. Sie überprüfen Benchmarks. Sie folgen Best Practices. Und dann starten sie.

Und wenn es nicht funktioniert? “Die Benutzer verstehen nicht, wie man es benutzt.”

Es ist, als würde Frank Gehry die Besucher dafür verantwortlich machen, dass sie sich in seinem Museum verlaufen.

Die seltsame Mathematik hinter fünf Benutzern

In den frühen 90er Jahren tat ein Mann namens Jakob Nielsen etwas, das unsere Denkweise über Benutzertests verändern würde. Er stellte eine einfache Frage: Wie viele Benutzer müssen Sie testen, um Usability-Probleme zu finden?

Die Antwort stellte sich als eine Kurve heraus, die die meisten nicht erwarten. Der erste Benutzer deckt etwa ein Drittel aller Probleme auf. Der zweite Benutzer findet viele der gleichen Probleme – aber auch einige neue. Der dritte, vierte und fünfte finden weiterhin neue Dinge, aber in abnehmendem Maße.

Bei fünf Benutzern haben Sie etwa 85 % der Hauptprobleme gefunden.

Das ist kontraintuitiv. Wir sind es gewohnt, dass größer immer besser ist. Mehr Datenpunkte. Mehr statistische Signifikanz. Mehr Sicherheit.

Aber Usability-Probleme sind nicht normal verteilt. Sie sind binär. Entweder kann der Benutzer die Aufgabe abschließen oder nicht. Und wenn fünf Personen genau an derselben Stelle stecken bleiben – brauchen Sie nicht Nummer sechs, um zu wissen, dass etwas nicht stimmt.

Der faszinierende Teil ist nicht die Mathematik. Es ist das, was sie offenbart: Die meisten Unternehmen testen nicht zu wenig, sie testen zu spät.

Fünf Benutzer, ein Nachmittag, ein Prototyp. Das ist alles, was nötig ist, um Monate des falschen Bauens zu vermeiden.

Aber die meisten warten, bis das Produkt fertig ist.

Ein Button ist nie nur ein Button

Lassen Sie uns zu Sarah und ihrem Finanzunternehmen zurückkehren. Nach Benutzertests taten sie etwas, das viele Unternehmen nicht tun: Sie fragten “Warum?”

Warum sah der Button aus wie ein Platzhalter?

Das Designteam hatte dem Designsystem des Unternehmens gefolgt. Grau war ihre Sekundärfarbe. Der Button sollte neutral sein und nicht zu viel Aufmerksamkeit auf sich ziehen.

Aber für den Benutzer existiert das Designsystem nicht. Sie sehen nicht “Sekundärfarbe gemäß den Markenrichtlinien aus Q2 2023”. Sie sehen ein graues Feld, das nicht klickbar aussieht.

Dies ist die Kluft zwischen Absicht und Wahrnehmung. Und sie zeigt sich nur, wenn echte Menschen mit Ihrem Produkt interagieren.

Malcolm Gladwell schrieb einmal darüber, wie Expertise uns manchmal blenden kann. Ein Sommelier kann Hunderte von Nuancen in einem Wein schmecken, die eine durchschnittliche Person nicht einmal bemerkt. Aber das bedeutet auch, dass der Sommelier den Kontakt dazu verloren hat, wie ein Wein für jemanden schmeckt, der nicht Tausende von Flaschen getrunken hat.

Designer sind wie Sommeliers. Sie sehen die Benutzeroberfläche durch die Linse von Hunderten anderer Benutzeroberflächen. Sie kennen Konventionen. Sie verstehen Metaphern. Sie wissen, dass ein Hamburger-Icon ein Menü bedeutet.

Aber die Großmutter des Benutzers? Sie sieht drei horizontale Linien.

Benutzertests sind keine Qualitätskontrolle. Es ist eine Realitätserklärung.

Die Geschichte des Buttons, der kein Button war

Im Jahr 2009 nahm Amazon eine so kleine Änderung vor, dass die meisten sie nie bemerkten. Aber diese Änderung erhöhte ihren Umsatz im ersten Jahr um schätzungsweise 300 Millionen Dollar.

Sie entfernten einen Button.

Genauer gesagt: Sie entfernten die Anforderung, ein Konto vor dem Kauf zu erstellen. Stattdessen fügten sie einen Gast-Checkout hinzu. Eine einzige Änderung. Ein wenigeres Hindernis.

Wie haben sie es herausgefunden? Durch Benutzertests.

Sie sahen, wie Menschen ihren Warenkorb füllten, zum Checkout klickten, das Kontoerstellungsformular sahen – und den Tab schlossen. Immer wieder. Nicht, weil sie das Produkt nicht kaufen wollten. Sondern weil sie nicht noch ein weiteres Konto erstellen wollten.

Das ist es, was Benutzertests offenbaren: Menschen tun nicht, was sie sagen. Sie tun nicht einmal unbedingt, was sie denken. Sie tun, was sich im Moment am einfachsten anfühlt.

Die unbequeme Wahrheit über Experten

Es gibt ein Paradoxon im Herzen der Produktentwicklung: Je mehr Sie über Ihr Produkt wissen, desto weniger verstehen Sie, wie ein neuer Benutzer es erlebt.

Es wird “der Fluch des Wissens” genannt, und es ist der Grund, warum Steve Krug – der Mann, der buchstäblich das Buch über Usability geschrieben hat – darauf besteht, mit echten Benutzern anstelle von Kollegen zu testen.

Als Dropbox zuerst gestartet wurde, hatten sie ein Problem. Die Leute verstanden nicht, was das Produkt tat. “Dateien zwischen Geräten synchronisieren” – das machte für den durchschnittlichen Benutzer im Jahr 2008 keinen Sinn. Techniker verstanden es sofort. Aber die Öffentlichkeit? Sie fragten: “Warum sollte ich meine Dateien im Internet haben wollen?”

Die Lösung von Dropbox war genial: Sie hörten auf zu erklären. Stattdessen zeigten sie ein Video. Ein kurzes, einfaches, lustiges Video, das genau zeigte, was passiert, wenn Sie etwas in Ihren Dropbox-Ordner legen.

Kein technisches Fachjargon. Keine Erklärung der Backend-Architektur. Nur: Legen Sie etwas hierhin, bekommen Sie es dort.

Wie wussten sie, dass es der richtige Ansatz war? Sie testeten es. Sie sahen, dass die Benutzer das Video ansahen und es verstanden. Ohne das Video – Verwirrung.

Das ist der Unterschied zwischen dem Denken wie ein Experte und dem Verstehen eines Anfängers. Und der einzige Weg dorthin ist, echte Anfänger zu beobachten, während sie versuchen, das zu benutzen, was Sie gebaut haben.

Was passiert wirklich, wenn Sie jemanden beobachten?

Das Seltsame an Benutzertests sind nicht die Daten, die Sie sammeln. Es ist das, was im Raum passiert, wenn Sie zuschauen.

Sarah von dem Fintech-Unternehmen beschrieb es so: “Nach zehn Minuten hören Sie auf, das Design zu verteidigen. Sie hören auf zu denken: ‘Aber sie machen es falsch’. Sie beginnen zu sehen, was sie tatsächlich sehen.”

Es ist eine Form von Empathie, die nicht gefälscht werden kann. Wenn Sie neben jemandem sitzen, der klickt, sucht, scrollt, zurückgeht, es erneut versucht, aufgibt – sehen Sie nicht nur, was falsch ist. Sie fühlen es.

Designer sprechen oft von “Benutzerempathie” als abstraktem Prinzip. Personas. Journey Maps. Empathy Maps. All diese Werkzeuge sind nützlich. Aber sie sind wie das Lesen über Radfahren. Sie verstehen das Konzept. Aber Sie lernen das Gleichgewicht nicht, bis Sie tatsächlich auf dem Fahrrad sitzen.

Benutzertests sind, wenn Sie auf dem Fahrrad sitzen.

Die Kunst, dumme Fragen zu stellen

Es gibt eine Technik, die erfahrene Moderatoren verwenden, die sich beim ersten Mal völlig falsch anfühlt. Wenn ein Benutzer fragt: “Soll ich hier klicken?” – antworten Sie nicht.

Stattdessen fragen Sie: “Was denken Sie?”

Es fühlt sich unhöflich an. Als würden Sie sich weigern zu helfen. Aber es ist der einzige Weg, um zu verstehen, was tatsächlich im Kopf des Benutzers vor sich geht.

Denn wenn Sie sagen: “Ja, klicken Sie dort” – haben Sie gerade den Test ruiniert. Jetzt wissen Sie, dass der Button funktioniert, wenn jemand Ihnen sagt, dass er klicken soll. Aber es sagt nichts darüber aus, ob ein echter Benutzer, allein an seinem Computer, ohne Sie als Führer, verstehen würde, dass er dort klicken soll.

Die besten Moderatoren haben eine Reihe von Phrasen entwickelt, die sich anfühlen, als würden sie helfen – aber tatsächlich die Verantwortung zurückwerfen:

“Was würden Sie tun, wenn ich nicht hier wäre?” “Erzählen Sie mir, was Sie denken.” “Interessant – warum denken Sie das?”

Das erfordert eine besondere Art von Komfort mit Stille. Die meisten Menschen hassen Stille im Gespräch. Wir wollen sie füllen. Erklären. Helfen.

Aber Stille ist der Ort, an dem Einsichten leben. Wenn ein Benutzer 30 Sekunden lang still sitzt, frustriert, herumklickt – ist es keine unangenehme Situation, sie zu unterbrechen. Es sind genau die Daten, die Sie benötigen.

Warum kleine Unternehmen besser testen als große

Es gibt ein Muster, das immer wieder auftritt: Startups mit drei Designern testen mehr als Unternehmen mit 50.

Warum?

Große Organisationen haben zu viel zu verlieren. Wenn Sie sechs Monate und zehn Millionen damit verbracht haben, etwas zu bauen – sind die psychologischen Kosten, zu hören “das funktioniert nicht”, enorm.

Also testen Sie nicht früh, wenn Sie noch nur einen Prototyp haben und nichts festgelegt ist – Sie testen spät. Wenn es zu schwer ist, Änderungen vorzunehmen. Wenn Sie insgeheim hoffen, dass der Test einfach bestätigt, dass alles in Ordnung ist.

Das ist Bestätigungsfehler in seiner teuersten Form.

Kleine Unternehmen haben einen anderen Druck. Sie haben keine Zeit. Sie müssen schnell bauen. Und paradoxerweise wird das zu ihrem Vorteil. Denn wenn Sie keine Zeit haben, um falsch zu bauen, müssen Sie wissen, dass Sie richtig bauen.

Airbnb testete zu Beginn den Buchungsablauf mit Papierprototypen. Nicht, weil sie hipster-cool waren. Sondern weil sie es sich nicht leisten konnten, etwas zu entwickeln, das nicht funktionierte.

Große Unternehmen sagen: “Wir können es uns nicht leisten zu testen”. Kleine Unternehmen erkennen: “Wir können es uns nicht leisten, NICHT zu testen”.

Die unangenehme Wahrheit über A/B-Tests

Etwa um 2010 wurde A/B-Testing zu einer Religion in der Tech-Welt. Google testete 41 Schattierungen von Blau. Amazon testete alles. Daten waren König.

Und Daten sind König. Aber Daten ohne Kontext sind nur Zahlen.

Ein A/B-Test kann Ihnen sagen, dass ein blauer Button 2,3 % besser konvertiert als ein grüner Button. Aber er kann Ihnen nicht sagen, warum. Und noch kritischer – er kann Ihnen nicht sagen, was Sie nicht wissen, dass Sie testen sollten.

Hier ist der Unterschied:

A/B-Test: “Welcher dieser beiden Buttons funktioniert besser?” Benutzertest: “Warum sieht niemand den Button überhaupt?”

Der erste optimiert. Der zweite offenbart.

Netflix ist ein Meister des A/B-Testings. Aber wissen Sie, was sie sonst noch tun? Benutzertests. Viele Benutzertests. Denn bevor Sie A/B testen können, welcher Thumbnail die meisten Klicks erhält, müssen Sie verstehen, wie Benutzer tatsächlich durch die Benutzeroberfläche browsen.

Die besten Produktteams nutzen beides. Benutzertests, um das Problem zu verstehen. A/B-Tests, um die Lösung im großen Maßstab zu validieren.

Was passiert, wenn Sie mit den “falschen” Personen testen

Es gibt einen Mythos über Benutzertests, der sich weigert zu sterben: dass Sie “perfekte” Teilnehmer finden müssen. Genau die richtigen demografischen Daten. Genau die richtigen Verhaltensmuster.

Aber die Realität ist nuancierter.

Steve Krug erzählt die Geschichte eines Tests, den er für eine Reisebuchungsseite durchgeführt hat. Sie hatten geplant, mit “häufigen Reisenden, die mindestens sechs Flüge pro Jahr buchen” zu testen.

Erster Testteilnehmer: eine 68-jährige Frau, die noch nie online einen Flug gebucht hatte.

Die erste Reaktion des Teams? “Sie ist die falsche Person für den Test.”

Aber nach zehn Minuten erkannten sie etwas. Jedes Mal, wenn sie stecken blieb – war es an denselben Stellen, an denen die “richtigen” Benutzer später stecken bleiben würden. Sie drückte nur ihre Verwirrung lauter aus. Klarer.

Sie war nicht die falsche Teilnehmerin. Sie war eine verstärkte Version der Probleme, die jeder hatte.

Das bedeutet nicht, dass Rekrutierung nicht wichtig ist. Wenn Sie eine App für Kardiologen entwickeln, müssen Sie mit Kardiologen testen. Aber es bedeutet, dass perfekte Rekrutierung oft eine Ausrede ist, um überhaupt nicht zu testen.

Besser, heute mit 80 % richtigen Teilnehmern zu testen, als drei Wochen auf 100 % perfekte Teilnehmer zu warten.

Die letzte Theorie: Warum wir nicht testen

Nach Tausenden von Gesprächen mit Designern und Produktteams gibt es ein Muster, das sich wiederholt. Wenn Menschen sagen: “Wir haben keine Zeit zu testen” – ist es fast nie die ganze Wahrheit.

Der wahre Grund ist unangenehmer: Wir haben Angst vor dem, was wir hören werden.

Es ist beängstigend, jemandem zuzusehen, der mit etwas kämpft, das Sie gebaut haben. Es ist entblößend. Wie jemanden zu bitten, Ihr Tagebuch zu lesen.

Aber genau das macht es so wertvoll. Denn entweder kämpfen die Benutzer, während Sie zuschauen – und dann können Sie es beheben. Oder sie kämpfen, wenn Sie nicht zuschauen – und dann verlieren Sie sie für immer.

Sarah und ihr Team führten nach dieser ersten Sitzung alle sechs Wochen Benutzertests durch. Nicht, weil es glamourös war. Sondern weil sie diese Erfahrung nie wieder machen wollten – vier Monate zu bauen und zu erkennen, dass 75 % der Benutzer aufgeben.

Die Kosten für das Testen: ein Nachmittag, ein paar Geschenkkarten. Die Kosten für das Nicht-Testen: vier Monate, ein ganzes Feature, Millionen an verlorenen Einnahmen.

Epilog: Ein Nachmittag, der alles verändert

Was an Benutzertests fasziniert, ist nicht die Komplexität. Es ist die Einfachheit.

Sie benötigen kein fortschrittliches Labor. Keine Augenverfolgungsausrüstung. Keine statistische Signifikanz.

Sie benötigen fünf Personen, ein paar Aufgaben und die Bereitschaft zu beobachten.

Was Sarah an diesem Mittwoch im März lernte, war nicht, wie man einen Button repariert. Es war etwas Grundlegenderes: dass Sie nicht wissen, was Sie nicht wissen, bis Sie hinschauen.

Ihr Team hatte wochenlang über den Button diskutiert. Sie hatten iteriert. Debattiert. Optimiert. Und doch hatten sie das Offensichtliche übersehen.

Aber sie hatten nicht versagt. Sie hatten einfach zu spät getestet.

Jetzt testen sie früh. Oft. Mit Prototypen, die noch unordentlich sind. Mit Ideen, die kaum fertig sind.

Und jedes Mal, wenn sie beobachten, dass ein Benutzer irgendwo stecken bleibt – sind sie nicht mehr enttäuscht.

Sie sind dankbar.

Denn jedes Problem, das sie im Test finden, ist ein Problem, das sie in der Realität vermeiden.

Das ist der Unterschied zwischen dem, was Sie denken, dass es funktioniert, und dem, was tatsächlich funktioniert.

Und dieser Unterschied ist, wie sich herausstellt, etwa einen Button wert.