Eine bekannte Faustregel der Usability-Forschung besagt, dass fünf Testpersonen rund 85 Prozent der Bedienprobleme einer Oberfläche aufdecken. Fünf. Nicht fünfzig. Der Betreiber selbst findet dagegen fast keines, und zwar aus einem strukturellen Grund: Er kennt die Antworten bereits. Er weiß, wo das Menü aufklappt, wie die Kategorien heißen und welches Wort im Suchfeld funktioniert. Sustainable Web Design bewertet die Umweltwirkung dieser Guideline in allen vier Kategorien als hoch, und das wirkt zunächst übertrieben für eine Regel über Testprozesse. Es ergibt aber Sinn, sobald man versteht, was ein nicht getesteter Entwurf kostet: seinen Nachbau.
Das einzige Erfolgskriterium von Guideline 2.14
Frühe Nutzertests: Lege festgelegte Abläufe für das Prototyping und das Testen neuer Funktionen und Interface-Komponenten fest. Validiere sie mit repräsentativen Nutzern, um sicherzustellen, dass sie unter realen Bedingungen und bei unterschiedlichen Bedürfnissen funktionieren.
Meine Einordnung
Zwei Formulierungen tragen dieses knappe Kriterium: „repräsentative Nutzer“ und „reale Bedingungen“.
Repräsentativ heißt nicht: Kollegen aus demselben Projekt. Es heißt: Menschen, die die Struktur nicht kennen, die andere Wörter benutzen als Du, die mit der Tastatur navigieren oder einen Screenreader verwenden. Genau diese Gruppen finden die Probleme, die im Team niemandem auffallen, weil das Team die Lösung mitgebaut hat.
Reale Bedingungen heißt nicht: neues Gerät, schnelles WLAN, ruhiger Schreibtisch. Es heißt: drei Jahre altes Telefon, mäßiger Empfang, Sonnenlicht auf dem Display, wenig Geduld. Der Unterschied ist erheblich, und er erklärt einen guten Teil der Kluft zwischen dem, was in Abnahmen gut aussieht, und dem, was in der Statistik als Absprung erscheint.
Der Nachhaltigkeitszusammenhang läuft über die Nacharbeit. Eine klassische Faustregel des Software-Engineerings besagt, dass die Kosten einer Korrektur mit jeder Projektphase um ein Vielfaches steigen. Was im Papierprototyp fünf Minuten kostet, kostet nach dem Launch Entwicklungszeit, Tests, ein Deployment und häufig einen Kompromiss. Jeder dieser Schritte verbraucht Rechenzeit und Arbeitszeit, und die Version, die verworfen wird, wurde trotzdem gebaut. Testen ist damit keine Qualitätsmaßnahme mit Nachhaltigkeitsnebeneffekt, sondern Vermeidung von Doppelarbeit.
Wo ich weiter gehe
Die Guideline setzt ein Team voraus. Ich betreibe datensm.art allein, und ich vermute, das gilt für viele, die diesen Text lesen.
Ich teste alles selbst aus Nutzersicht und gehe jedem Hinweis nach, der mich erreicht. Das ist besser als nichts, aber ich mache mir keine Illusionen über die Grenze dieses Vorgehens.
Meine drei Ersatzquellen sehen so aus.
Erstens die ungefragten Hinweise. Wer sich die Mühe macht, mir eine Mail über einen kaputten Link zu schreiben, steht stellvertretend für viele, die einfach gegangen sind. In der Kundenforschung kursiert die Faustzahl, dass nur ein kleiner Bruchteil der Unzufriedenen sich überhaupt meldet. Deshalb behandle ich jeden Hinweis als Stichprobe, nicht als Einzelfall.
Zweitens die passiven Signale. Suchanfragen ohne Treffer, häufige 404-Fehler, Seiten mit auffällig hoher Absprungrate: Das sind Nutzertests, die ohne mein Zutun stattfinden und protokolliert werden. Sie sagen nicht, warum etwas schiefging, aber sehr präzise, wo.
Drittens die Bedingungssimulation. Einmal im Quartal rufe ich die Seite mit gedrosselter Verbindung auf einem alten Telefon auf, bediene sie ausschließlich mit der Tastatur und lasse mir eine Seite vom Screenreader vorlesen. Das ersetzt keinen echten Nutzer, deckt aber die Klasse von Problemen ab, die an Technik und nicht an Verständnis hängen.
Und dann gibt es noch die einfachste Variante, die ich zu selten nutze: jemanden fragen, der nichts mit dem Projekt zu tun hat.
Dein erster Schritt heute
Du brauchst kein Testlabor. Du brauchst zehn Minuten und einen Menschen.
Wiederhole das mit vier weiteren Personen über die nächsten Wochen, dann hast Du die fünf aus dem Einstieg zusammen. Mehr braucht es für den Anfang nicht.
Wer nur sich selbst testet, prüft die Bedienbarkeit der eigenen Erinnerung.
Quelle: W3C-Fassung von Guideline 2.14