Portfolio
Aura — UX-Qualität in der agentischen Produktentwicklung
Product Manager entwickelten eigene Prototypen, Anforderungen wanderten zunehmend direkt in die Entwicklung, und parallel begann der Aufbau einer neuen Produktversion mithilfe von Coding-Agenten. Der gewohnte UX-Prozess passte immer weniger zu dieser Arbeitsweise. Damit stand eine organisatorische Frage im Raum: Wie bleiben Nutzerperspektive, Zugänglichkeit und gestalterische Konsistenz Teil der Entscheidungen, wenn die klassische Übergabe von Design an Entwicklung entfällt?
Ich konzipierte und baute Aura als Unterstützung für dieses Team. Die wesentlichen Entscheidungen betrafen die Trennung von Fachwissen und Abläufen, gemeinsame Regeln zur Gewichtung von Befunden und die Stellen, an denen ein Mensch entscheiden muss. Entwickler konnten ihre Umsetzung prüfen lassen; Product Manager bekamen einen Einstieg, um ihre Absicht in eine UX-Spezifikation zu überführen. Mein Beitrag lag in der Architektur dieses Arbeitsprozesses und seiner fachlichen Regeln.
Prozess
Phase 01
Den Kontext vor der Prüfung klären
Ich legte fest, dass Aura zunächst Tech-Stack, Routing, Templates, Styles und das vorhandene Design System erfasst. So können Empfehlungen auf die konkrete Implementierung Bezug nehmen. Diese Bestandsaufnahme liefert Kontext; sie ersetzt keine Prüfung der tatsächlich gerenderten Oberfläche.
Phase 02
Entscheidungsrechte festlegen
Vor den einzelnen Prüffähigkeiten formulierte ich Regeln für Transparenz und menschliche Freigabe: kritische Fragen eskalieren, Änderungen ankündigen, Annahmen offenlegen. Empfehlungen sollten Optionen und Begründungen enthalten. Damit wurde die Zusammenarbeit zwischen Mensch und Agent selbst zum Gegenstand der Konzeption.
Phase 03
Den Prüfumfang verhandelbar machen
Die erste Nutzung brachte sofort eine größere Anforderung: Statt eines einzelnen Features wollte ein Entwickler die ganze App prüfen lassen. Ich erweiterte den Ablauf um das Auffinden relevanter Oberflächen, eine Risikoeinschätzung und die gemeinsame Festlegung der Prüftiefe. Der Bericht sollte erkennen lassen, was innerhalb und außerhalb des gewählten Umfangs lag.
Phase 04
Befunde zusammenführen
Mehrere Prüfperspektiven meldeten anfangs dasselbe Problem mehrfach. Ich führte eine Konsolidierung mit gemeinsamer Gewichtung ein. Die damalige Regel erhöhte die Schwere bei Übereinstimmung mehrerer Prüfungen. Rückblickend würde ich diese Kopplung gezielter evaluieren: Wiederholung kann die Zuversicht erhöhen, macht die Auswirkung eines Problems aber nicht automatisch größer.
Phase 05
Einstiege an Arbeitsanlässen ausrichten
Die erste Befehlsstruktur folgte der Agentenarchitektur. Ein allgemeines Kommando verriet wenig darüber, was als Nächstes passieren würde. Ich ersetzte diesen Einstieg durch konkrete Anlässe wie Feature-Review, Merge Request, App-Prüfung oder neues Vorhaben. Aura bestätigt außerdem, wie es die Aufgabe verstanden hat. Ein UX-Agent darf sich schließlich auch selbst verständlich machen.
Phase 06
Produktabsicht vor Implementierung klären
Für frühe Produktideen ergänzte ich einen Ablauf, der zunächst die Absicht erfragt und daraus eine UX-Spezifikation erstellt. Diese durchläuft die eigene Prüfkaskade und wird an die Entwicklung übergeben. Der Agent kann damit früher zur Klärung beitragen; ein unauffälliges Selbstreview bleibt allerdings eine begrenzte Prüfung und keine Qualitätsgarantie.
Phase 07
Pflege des Fachwissens vorsehen
Ich ergänzte eine manuell angestoßene Routine, die referenzierte Standards mit ihren Quellen abgleicht und Änderungen zur Freigabe vorlegt. Damit bekam das Regelwerk einen vorgesehenen Pflegeweg, auch über meine eigene Beteiligung hinaus. Änderungen bleiben für das Team nachvollziehbar.
Methoden
Fachwissen und Abläufe trennen
Ich organisierte Prüfwissen in Skills und Abläufe in Agenten. So lassen sich fachliche Regeln und Prozessschritte gezielter ändern, ohne jede Erweiterung durch das gesamte System zu ziehen.
Menschliche Entscheidungen verankern
Freigaben und Eskalationen gehören zum Ablauf. Insbesondere Ethikbefunde benötigen eine einzelne Entscheidung, auch wenn zuvor eine Sammelaktion gewählt wurde.
Gemeinsame Gewichtung
Eine zentrale Rubrik mit drei Stufen hält die Bewertung über die Disziplinen hinweg vergleichbar. Ob die Zuordnung im Einzelfall trägt, muss weiterhin überprüfbar bleiben.
Anpassung an andere Kontexte
Unternehmensspezifische Vorgaben liegen in einer austauschbaren Schicht. Die Architektur ist auf Übertragbarkeit angelegt; ihre Eignung für andere Teams muss dort jeweils geprüft werden.
Visuals
Auras Entscheidungsmenü: Optionen und nächste Schritte werden sichtbar, Sammelaktionen sind nicht vorausgewählt.
Beispielbericht zu manipulativen Mustern und Kontrastproblemen. Die Befunde bilden eine Grundlage für die menschliche Prüfung.
Key Takeaways
Arbeitsweisen sind gestaltbar
Als sich die Produktion beschleunigte, verlagerte sich meine Arbeit auf die Frage, wie fachliches Urteil weiterhin in Entscheidungen einfließt.
Verantwortung braucht Regeln
Wer entscheidet, wann zurückgefragt wird und wie Unsicherheit erscheint, prägt die Qualität der Zusammenarbeit mit einem Agenten.
Nutzung korrigiert die Architektur
Das erste Feedback veränderte Prüfumfang und Einstiegspunkte. Die Nutzbarkeit des Agenten musste ebenso entwickelt werden wie seine Fachlichkeit.
Evaluation bleibt eine eigene Aufgabe
Ein nachvollziehbares Regelwerk und erste Nutzung sind ein Anfang. Für belastbares Vertrauen müssen auch Fehlalarme, übersehene Probleme und der Umgang mit Empfehlungen untersucht werden.
Aura wurde im Team eingesetzt. Das Regelwerk liegt in Markdown-Dateien und lässt sich versionieren und prüfen; ausgeführt wird es durch die zugrunde liegenden KI-Werkzeuge. Lesbare Regeln machen das System nachvollziehbarer, garantieren aber noch keine verlässlichen Befunde. Als weitere Entwicklung waren die Auswertung wiederkehrender Probleme und der Umgang mit abgelehnten Empfehlungen vorgesehen. Eine belastbare Messung von Fehlererkennung, Fehlalarmen und eingesparter Review-Zeit liegt für diesen Case noch nicht vor.