Portfolio

Aura — ein UX-Agent für ein Prompt-First-Team

Jahr
2026
Dauer
Laufend
Kunde
Digital-Produkt-Unternehmen (vertraulich)
Rolle
Process Design · AI Agent Design · UX Systems · Team Enablement
  • Process Design
  • AI Agent Design
  • UX Systems
  • Team Enablement
12 Disziplin-Skills
10 Agenten
6 Einstiegsbefehle
0 Zeilen Laufzeit-Code

Der Wandel kam erst schleichend, dann abrupt. Product Manager bauten ihre eigenen Prototypen und zeigten den Funktionsumfang ihrer Vision, statt ihn zu beschreiben. Entwickler implementierten neue Features schneller, als klassische Designzyklen mithalten konnten. Parallel startete eine 2.0 des Produkts: neue Programmiersprache, kein handgeschriebener Code, eine breite und mutige Produktvision – dazwischen nur Prompts und Agenten.

Für UX stellte das eine unbequeme Frage: Wo findet Designqualität statt, wenn niemand mehr auf ein Design wartet? Meine Antwort war nicht, den alten Prozess zu verteidigen, sondern ihn zu übersetzen. Ich habe einen UX-Agenten gebaut, der nicht nur für eine KI-getriebene Welt taugt, sondern für eine Welt, in der es keine UX-Designer:innen mehr gibt.

Phase 01

Den Stack lesen, bevor man urteilt

Ein Agent, der Interfaces bewertet, muss wissen, woraus sie entstehen. Der erste Schritt war deshalb kein Review, sondern eine Analyse: Tech-Stack, Routing, Template- und Style-Idiom, dazu Design System und Marke. Erst aus dieser Grundlage lässt sich beurteilen, was ein Interface tatsächlich tut – und in welchem Idiom ein Fix geschrieben sein muss.

Phase 02

Eine Verfassung statt einer Feature-Liste

Vor den Fähigkeiten standen die Prinzipien – und der Agent musste sie auf sich selbst anwenden. Human-Centered und Ethics First: keine kritische Entscheidung, keine Annahme ohne Rückfrage beim Menschen. Kein stilles Scheitern, keine Änderung ohne Ankündigung. Bei unsicherer Datenlage eskalieren statt raten. Sich selbst reviewen. Effizient arbeiten, also leichtere Arbeit an günstigere Modelle delegieren. Und wenn er mit einem Menschen spricht: strukturiert, mit Optionen, Empfehlung und Begründung.

Phase 03

Erste Iteration trifft erste Nutzung

Die erste Version prüfte, wofür sie gebaut war: ein Dokument, ein Feature, eine Seite. Der erste Entwickler, der sie benutzte, wollte etwas anderes – ein Review der gesamten App. Aus einer klar begrenzten Aufgabe wurde eine ungleich komplexere: Oberflächen überhaupt erst finden, Risiko einschätzen, Prüftiefe gemeinsam festlegen und am Ende belegen können, was geprüft wurde und was nicht.

Phase 04

Befunde konsolidieren statt stapeln

Geprüft wird gegen viele Kriterien gleichzeitig: Heuristiken, WCAG, Dark Patterns, Motion, Content. Dasselbe Problem wird dabei regelmäßig von mehreren Kriterien markiert – und landete anfangs mehrfach im Bericht. Statt Duplikate weiterzureichen, kam ein gestuftes System: Ein Befund, den drei unabhängige Prüfungen treffen, steigt eine Schwerestufe. Korroboration wird zum Signal statt zum Rauschen.

Phase 05

Der Fehler: Kommandos um Agenten gebaut, nicht um Menschen

Die Befehlsstruktur folgte anfangs der Architektur. Man tippte /ux, und irgendetwas passierte – ohne dass klar war, was. Für einen Agenten, dessen Kernprinzip Transparenz ist, war das ein Widerspruch in sich. Es brauchte spezialisierte Einstiegspunkte für die tatsächlichen Anlässe – ein Feature, ein Merge Request, die ganze App, etwas Neues bauen – und eine Rückmeldung, was der Agent verstanden hat und was er als Nächstes tut.

Phase 06

Vom Prüfen zum Bauen

Jeder Agent war zunächst kritik-förmig: Er fuhr eine Disziplin rückwärts und suchte Verstöße an etwas, das es schon gab. Für Prototypen aus dem Produktmanagement war das zu spät. Also bekam der Agent die Umkehrung: aus einem Interview über die Absicht eine vollständige UX-Spezifikation erzeugen, sie durch die eigene Prüfkaskade schicken, bis nichts Kritisches mehr übrig ist, und sie an die Coding-Fähigkeiten der Entwickler übergeben. Spezifikation, kein Produktionscode.

Phase 07

Wissen, das nicht veraltet

Dann änderte sich etwas an WCAG – und es wurde offensichtlich, dass das Wissen in den Skills gepflegt werden muss, irgendwann auch von jemandem ohne UX-Hintergrund. Der Agent bekam eine Routine, die die zitierten Standards gegen ihre Quellen prüft und Abweichungen als nachvollziehbaren Änderungsvorschlag vorlegt. Sein eigenes Wissen ändert er nie still; ein Mensch gibt frei.

Wissen und Ablauf getrennt

Skills sind reines Wissen ohne Kontrollfluss, Agenten sind Abläufe ohne Wissen. Diese Trennung von Anfang an war die Entscheidung, die jede spätere Erweiterung billig gemacht hat.

Human-in-the-Loop by Design

Der Agent schlägt vor, der Mensch entscheidet. Ethikbefunde brauchen immer eine Freigabe pro Befund – auch wenn jemand „alles beheben" gewählt hat.

Eine Schwere-Systematik für alles

Drei Stufen, in einer einzigen Rubrik definiert und überall identisch verwendet. Kein Kriterium darf eine vierte erfinden – sonst wird aus Priorisierung Geschmackssache.

Portabel statt projektspezifisch

Jede sehr konkrete Anforderung aus dem Team wurde so gelöst, dass sie in jeder Umgebung, mit jedem Produkt und jeder Technologie funktioniert. Firmenspezifisches lebt in einem austauschbaren Overlay.

Am Ende bekam der Agent einen Namen und ein Gesicht: Aura – und ein Entscheidungsmenü, in dem Verstehen vor Handeln kommt und die Massenaktion nie voreingestellt ist.

Am Ende bekam der Agent einen Namen und ein Gesicht: Aura – und ein Entscheidungsmenü, in dem Verstehen vor Handeln kommt und die Massenaktion nie voreingestellt ist.

Manipulative Countdowns, unehrliche Button-Labels, Kontrastfehler: die Befunde, die ohne UX im Team niemand mehr auffangen würde.

Manipulative Countdowns, unehrliche Button-Labels, Kontrastfehler: die Befunde, die ohne UX im Team niemand mehr auffangen würde.

Prozess ist eine Designaufgabe

Als sich die Arbeitsweise des Teams änderte, war die eigentliche Designaufgabe nicht das nächste Interface, sondern der Prozess selbst.

Prinzipien vor Fähigkeiten

Was ein Agent nicht tun darf, ist wichtiger als das, was er kann. Ein System, das ungefragt handelt, verspielt Vertrauen schneller, als es Nutzen stiftet.

Auch ein Agent braucht UX

Die Kommandostruktur war der erste Punkt, an dem ich meinen eigenen Standards nicht genügt habe: gebaut um die Architektur, nicht um den Anlass der Nutzer:innen.

Wissen hat ein Haltbarkeitsdatum

Standards ändern sich. Wenn Wissen nicht gepflegt werden kann, ohne Expert:in zu sein, veraltet das System genau dann, wenn niemand mehr hinschaut.

Aura ist im Team im Einsatz und wächst weiter – aktuell an der Frage, wie sich Befunde über viele Reviews hinweg zu einem Bild verdichten und wie der Agent aus abgelehnten Befunden lernt, ohne je etwas zu verstecken. Der Kern bleibt: Aura ist vollständig in Markdown geschrieben, ohne Dienst und ohne Blackbox. Jede Regel, nach der geurteilt wird, ist in einem Diff nachlesbar – und damit auch von einem Team veränderbar, das keine UX-Designer:innen mehr hat.