Manchmal schließen sich Kreise auf eine Weise, die man erst Jahre später erkennt. Letzte Woche saß ich vor meinem Rechner, machte Screenshots von einer Webseite, kommentierte sie und schickte sie an Claude. Plötzlich wurde mir bewusst: Das hier ist exakt das Verfahren, das ich 1998 in meiner Diplomarbeit beschrieben habe. Nur dass damals ein Mensch am anderen Ende saß, und heute eine KI.

Damals: Ad-hoc-Usability-Tests als Notlösung

Ende der 90er war Usability-Engineering noch ein junges Feld, zumindest in der Praxis. Die etablierten Methoden (Labor-Tests mit Eyetracking, formale Heuristik-Evaluationen, mehrwöchige User-Studies) waren teuer, langsam und für die meisten Webprojekte schlicht nicht finanzierbar. Gleichzeitig wuchs das Web rasant, und die Qualität der Interfaces hielt damit oft nicht Schritt.

Meine Diplomarbeit beschäftigte sich mit einer pragmatischen Alternative: Ad-hoc-Usability-Tests. Die Idee war einfach. Ein User benutzt die Webseite oder das Programm. Die Interaktion ist für alle sichtbar. Ein Auditor, also jemand mit geschultem Blick für Usability-Probleme, beobachtet den User, identifiziert Issues, macht Screenshots, annotiert sie direkt und reicht sie ohne Umweg an einen Entwickler weiter, der als Dritter ebenfalls live in der Session sitzt. Der Entwickler sammelt die Issues, priorisiert sie und implementiert sie.

Der entscheidende Punkt war die radikale Verkürzung des Feedback-Loops. Keine Reports, die wochenlang geschrieben werden. Keine Übergaben über drei Abteilungen. Kein „Wir schauen uns das im nächsten Sprint an.“ Stattdessen: sehen, kommentieren, weitergeben, umsetzen. Die Methode war keine Konkurrenz zu seriösen Usability-Studies, sie war eine Antwort auf die Frage, was man tun kann, wenn man keine drei Monate und keine 50.000 Mark hat.

Heute: Derselbe Loop, neuer Empfänger

Was ich aktuell in meinem KI-gestützten Entwicklungsworkflow mache, ist strukturell dieselbe Methode. Nur dass der Entwickler am anderen Ende kein Kollege mehr ist, sondern Claude.

Der Ablauf sieht so aus: Ich öffne die Webseite, an der ich gerade arbeite. Ich gehe sie durch wie ein Auditor und achte auf das, was nicht stimmt. Inkonsistente Abstände, ein Button, der nicht als solcher erkennbar ist, eine Formular-Validierung, die zur falschen Zeit feuert, eine Fehlermeldung, die niemand versteht. Sobald ich etwas finde, mache ich einen Screenshot, gehe zu Claude, teile den Screenshot, kommentiere kurz, was mich stört. Claude formuliert daraus ein sauberes Issue mit Kontext, mit Reproduktionsschritten, mit Vorschlag zur Behebung.

Das mache ich ein, zwei Stunden am Stück. Am Ende habe ich 20 bis 30 Issues. Und dann kommt der zweite Teil: Ich bitte Claude, diese Issues zu implementieren. Entweder Stück für Stück, wenn ich mitschauen und gegensteuern möchte. Oder alle auf einmal, wenn die Issues klar genug sind und ich danach nur noch reviewen will. Je nachdem, wie es mir passt.

Was sich verändert hat, und was nicht

Was gleich geblieben ist: die Rolle des Menschen als Auditor. Der geschulte Blick, das Erkennen von Reibung, das Einordnen in Schwere und Priorität, das macht weiterhin der Mensch. Eine KI kann durchaus selbst Heuristik-Evaluationen durchführen, aber sie sieht eine Webseite anders als ein Nutzer, der drei Sekunden lang Verwirrung empfindet. Diese Sekunde Verwirrung ist nach wie vor menschliches Terrain.

Was sich verändert hat: die Asymmetrie zwischen Finden und Beheben. 1998 war Finden schnell, Beheben langsam. Ein guter Auditor konnte 30 Issues an einem Vormittag identifizieren, aber sie dann zu beschreiben, zu kommunizieren, zu priorisieren und zu implementieren, hat oft Wochen gedauert. Heute kippt das Verhältnis. Das Finden bleibt menschliche Arbeit in menschlicher Geschwindigkeit. Aber Beschreiben, Strukturieren und Implementieren beschleunigen sich um Größenordnungen. Was früher ein Sprint war, ist heute ein Nachmittag.

Und etwas Drittes hat sich verändert, das ich vor 1998 so nie beschrieben hätte: Die KI ist nicht nur Entwickler, sondern auch Übersetzerin. Mein Screenshot-Kommentar ist oft halbgar („der Abstand hier wirkt komisch“, „das hier ist verwirrend, weil…“). Claude macht daraus eine präzise Beschreibung: welcher Abstand, im Verhältnis zu welchem anderen Element, mit welcher CSS-Property, in welchem Breakpoint. Diese Übersetzungsleistung war in meiner Diplomarbeit nicht vorgesehen. Sie war damals Aufgabe des Auditors, und sie hat einen guten Auditor von einem mittelmäßigen unterschieden.

Was ich daraus mitnehme

Drei Dinge fallen mir auf, wenn ich die beiden Welten nebeneinanderlege.

Erstens: Die guten Methoden waren oft schon da. Was sich durch KI verändert, ist seltener die Methode selbst und häufiger das, was an ihr unbequem oder teuer war. Ad-hoc-Usability-Tests funktionieren 2026 genauso wie 1998. Sie sind nur nicht mehr durch die Geschwindigkeit der Implementierung gebremst.

Zweitens: Der Mensch wird nicht ersetzt, er wird verschoben. Ich verbringe heute mehr Zeit damit, kritisch durch eigene Produkte zu klicken, als ich es noch vor zwei Jahren getan habe. Nicht weniger. Die Arbeit, die früher in Tickets-Tippen, Slack-Diskussionen und Sprint-Planning floss, fließt heute in das, was eigentlich das Wertvolle ist: Probleme erkennen und einordnen.

Drittens: Workflows, die früher nur in großen Teams funktioniert haben, sind heute für Einzelne realisierbar. User, Auditor und Entwicklerin in derselben Session, das war 1998 ein Luxus, den man sich für wichtige Projekte geleistet hat. Und es war technisch anspruchsvoll. Heute bin ich beides, im Wechsel, mit Claude als ausführendem Arm. Ein Workflow, der vorher mindestens zwei Menschen brauchte, läuft jetzt auf einem Schreibtisch.

Wenn ich mir meine Diplomarbeit von damals nochmal anschaue, denke ich: Die Methode war richtig. Sie war nur ihrer Zeit voraus, weil die zweite Hälfte, das schnelle Implementieren, fehlte. Jetzt ist sie da.

Wer Lust auf die Diplomarbeit hat: Download der Arbeit.