Eine Benutzeroberfläche kann technisch vollständig korrekt sein und trotzdem nicht besonders gut funktionieren. Alle Daten sind vorhanden, jede Schaltfläche löst den richtigen Vorgang aus und die Komponenten sind sauber aufgebaut, während ein Benutzer trotzdem erst überlegen muss, wo er anfangen soll, welche Information wichtig ist oder warum eine Funktion an genau dieser Stelle auftaucht.
Gerade als Entwickler ist diese Art von Problem leicht zu übersehen, weil ich die innere Struktur der Anwendung kenne. Ich weiß, welche Daten zusammengehören, welche Funktionen technisch miteinander verbunden sind und warum bestimmte Abläufe existieren. Daraus entsteht sehr schnell eine Oberfläche, die für mich logisch wirkt, weil sie die Architektur widerspiegelt, obwohl ein Benutzer eine völlig andere Sicht auf dieselbe Aufgabe besitzt.
Mit KI-gestützter Entwicklung wird dieses Problem für mich sogar interessanter, denn Codex kann eine technisch vollständige Oberfläche sehr schnell erzeugen. Dadurch entfällt ein Teil der langsamen manuellen Arbeit, in der man früher beinahe automatisch immer wieder auf die eigene Oberfläche schauen musste. Genau deshalb möchte ich UI-Design inzwischen bewusster von der eigentlichen Implementierung trennen.
Technische Struktur und Benutzerstruktur sind nicht dasselbe
Eine Software besitzt intern bestimmte Modelle, Dienste und Abhängigkeiten. Diese technische Struktur ist für die Wartbarkeit wichtig, muss aber nicht zwangsläufig der Struktur entsprechen, die für einen Benutzer sinnvoll ist.
Ein einfaches Beispiel sind Daten, die technisch aus drei unterschiedlichen Quellen stammen, für den Benutzer aber zu einem einzigen Vorgang gehören. Wenn ich die Oberfläche zu stark nach der internen Architektur aufbaue, entstehen daraus möglicherweise drei getrennte Bereiche, obwohl der Benutzer eigentlich nur eine zusammenhängende Aufgabe erledigen möchte.
Umgekehrt können zwei Funktionen technisch eng miteinander verbunden sein und aus Benutzersicht trotzdem an vollkommen unterschiedlichen Stellen sinnvoll sein.
Meine Erfahrungen aus Helpdesk, Betrieb, Consulting und Vertrieb haben meinen Blick auf solche Unterschiede stark geprägt. Software wird nicht dadurch verständlich, dass ihre interne Logik sauber nach außen gespiegelt wird, sondern dadurch, dass sich die Oberfläche an der Aufgabe des Benutzers orientiert.
Genau deshalb möchte ich das Bedienkonzept zunehmend festlegen, bevor Codex die technische Struktur dafür erzeugt.
KI macht eine schlechte Oberfläche nur schneller fertig
Codex kann aus einer knappen Beschreibung in erstaunlich kurzer Zeit eine vollständige Blazor-Seite bauen. Gerade das ist verführerisch, weil eine funktionierende Oberfläche schnell den Eindruck vermittelt, ein Thema sei bereits weitgehend abgeschlossen.
Wenn ich aber erst nach der Umsetzung beginne, über Hierarchie, Bedienfluss und visuelle Struktur nachzudenken, muss ich anschließend möglicherweise große Teile wieder ändern. Technisch ist das dank KI zwar ebenfalls schneller als früher, sinnvoll ist es trotzdem nicht.
Der gleiche Grundsatz, der für meine fachliche Konzeptarbeit gilt, passt deshalb auch hier: Eine falsche Entscheidung korrigiere ich lieber möglichst früh, solange sie noch billig ist.
Bei einer Oberfläche bedeutet das, dass ich stärker zwischen drei Fragen unterscheide:
Was muss der Benutzer erreichen können?
Wie sollte sich dieser Ablauf auf der Oberfläche anfühlen und darstellen?
Wie wird dieses Design technisch in Blazor umgesetzt?
Wenn alle drei Fragen gleichzeitig im Codex-Chat gelöst werden, besteht die Gefahr, dass die erste technisch plausible Antwort auch gleich zum Design wird.
Ein Entwurf schafft einen verbindlicheren Bezugspunkt
Mit Penpot integriere ich deshalb inzwischen einen eigenen Designschritt in meinen KI-Workflow. Der wichtigste Vorteil ist für mich nicht, dass Penpot automatisch schöne Oberflächen erzeugt, sondern dass eine visuelle Entscheidung außerhalb des Codes sichtbar und diskutierbar wird.
Ein Entwurf schafft einen Bezugspunkt.
Wenn die Umsetzung später anders aussieht, kann ich direkt vergleichen, ob es dafür einen guten technischen Grund gibt oder ob Codex schlicht eine andere Interpretation gewählt hat. Ohne diesen Bezugspunkt basiert die Bewertung schnell auf einem vagen Gefühl, dass die Oberfläche „noch nicht richtig“ aussieht, und genau daraus entstehen die langen textbasierten Korrekturschleifen, die ich zunehmend vermeiden möchte.
Damit bekommt das UI-Design dieselbe Funktion, die eine gute fachliche Spezifikation an anderer Stelle besitzt: Es beschreibt das gewünschte Ergebnis, ohne die komplette technische Umsetzung vorwegzunehmen.
Blazor-Komponenten sollten aus dem Design entstehen, nicht umgekehrt
Gerade bei Blazor ist es einfach, eine Oberfläche stark aus vorhandenen Komponenten heraus zu denken. Wenn bereits Tabellen, Formulare, Dialoge und bestimmte Layout-Komponenten existieren, liegt es nahe, eine neue Funktion so aufzubauen, dass möglichst viel davon direkt wiederverwendet werden kann.
Wiederverwendung ist natürlich sinnvoll, darf aber aus meiner Sicht nicht dazu führen, dass sich jede neue Funktion zwangsläufig in dieselbe visuelle Form pressen muss.
Eine Komponente ist ein technisches Werkzeug und kein Argument dafür, dass der Benutzer genau diesen Ablauf bekommen sollte.
Wenn ein Design zeigt, dass eine Funktion anders strukturiert werden muss, ist für mich zunächst zu prüfen, ob eine neue oder angepasste Komponente sinnvoll ist. Erst danach sollte die Frage kommen, ob sich das gewünschte Verhalten möglichst bequem mit dem bestehenden Werkzeugkasten umsetzen lässt.
Diese Reihenfolge erscheint mir gerade mit Codex realistisch, weil die technische Mehrarbeit für neue Komponenten deutlich geringer geworden ist.
Ein gutes UI-Design ist keine Frage von Dekoration
Wenn Entwickler über Design sprechen, wird das Thema manchmal auf Farben, Abstände oder hübsche Komponenten reduziert. Für mich liegt der wichtigere Teil deutlich früher.
Welche Information steht zuerst?
Welche Handlung ist an dieser Stelle wahrscheinlich?
Welche Elemente gehören gedanklich zusammen?
Welche Entscheidung ist reversibel und welche braucht eine zusätzliche Bestätigung?
Welche Informationen müssen permanent sichtbar sein und welche dürfen erst bei Bedarf erscheinen?
Solche Entscheidungen bestimmen die Benutzbarkeit wesentlich stärker als die Frage nach einem einzelnen Farbton.
Der Oma-Test ist für mich ein bewusst einfaches Gegenmittel gegen die Entwicklerperspektive. Ein Mensch ohne Kenntnis meiner internen Architektur sollte zumindest erkennen können, worum es in einer Anwendung geht und welche Handlungsmöglichkeiten vorhanden sind.
Wenn ich diese Frage erst nach Fertigstellung der Oberfläche stelle, ist das unnötig spät.
Auch Fehlermeldungen und Zustände gehören ins Design
Ein UI-Entwurf darf für mich nicht nur den perfekten Normalzustand zeigen. Eine Anwendung besteht nicht ausschließlich aus vollständig geladenen Daten, erfolgreichen Aktionen und fehlerfreien Verbindungen.
Gerade Fehlermeldungen sind ein Teil der Benutzerführung, und deshalb müssen auch Zustände wie „wird geladen“, „keine Daten vorhanden“, „Aktion fehlgeschlagen“, „Zustand unbekannt“ oder „Freigabe erforderlich“ in das Bedienkonzept einfließen.
Das ist bei KI-generierten Oberflächen besonders wichtig, weil Codex sonst sehr leicht zuerst den Happy Path vollständig ausbaut und alle anderen Zustände später als kleine technische Ergänzungen behandelt.
Für den Benutzer sind diese Zustände aber nicht nebensächlich. Gerade dort entscheidet sich häufig, ob eine Anwendung verständlich bleibt oder plötzlich in einen Zustand kippt, in dem niemand mehr weiß, wie es weitergeht.
Ein gutes Design muss deshalb auch die unangenehmen Situationen zeigen.
Design und Umsetzung brauchen trotzdem einen Rückkanal
Die Trennung von UI-Design und Code bedeutet nicht, dass das Design unangreifbar wird. Ein visueller Entwurf kann technisch unpraktisch, unnötig teuer oder auf bestimmten Bildschirmgrößen schlecht umsetzbar sein. Gerade bei bestehenden Projekten können außerdem Komponenten oder technische Randbedingungen existieren, die in der Designphase nicht vollständig bekannt waren.
Deshalb brauche ich denselben Rückkopplungsmechanismus wie bei meinen fachlichen Konzepten.
Codex darf feststellen, dass eine bestimmte Umsetzung problematisch ist.
Was ich vermeiden möchte, ist lediglich, dass daraus stillschweigend eine andere Oberfläche entsteht.
Wenn ein Design technisch angepasst werden muss, sollte die Änderung bewusst zurück in die Designentscheidung fließen, damit nicht Penpot, Code und tatsächliche Anwendung langsam auseinanderlaufen.
Langfristig wird genau dieser Änderungsprozess für mich besonders interessant: Wie gut lässt sich ein bestehender Penpot-Entwurf später weiterentwickeln, während Codex gleichzeitig versteht, welche Teile im vorhandenen Blazor-Code bereits umgesetzt wurden?
Responsive Design macht diese Trennung noch wichtiger
Eine einzelne Desktop-Ansicht ist keine vollständige Benutzeroberfläche. Spätestens auf kleineren Bildschirmen verändern sich Platzverhältnisse, Prioritäten und teilweise sogar sinnvolle Abläufe.
Wenn ich eine Oberfläche ausschließlich direkt im Browser entwickle, neige ich dazu, zunächst den Bildschirm zu optimieren, vor dem ich gerade sitze. Responsive Verhalten wird dann später ergänzt.
Ein eigener Designschritt zwingt mich eher dazu, früh zu überlegen, welche Informationen wirklich wichtig sind und welche Elemente bei weniger Platz anders organisiert werden müssen.
Das passt wiederum gut zu komponentenbasierter Entwicklung mit Blazor. Wenn klar ist, welche Inhalte und Aktionen zusammengehören, kann Codex die technische Umsetzung so strukturieren, dass unterschiedliche Darstellungen dieselben fachlichen Komponenten verwenden, ohne dass die Benutzeroberfläche einfach nur zusammengeschoben wird.
Der zusätzliche Designschritt spart mir langfristig eher Arbeit
Ähnlich wie bei ausführlicheren Spezifikationen wirkt ein vorgelagertes UI-Design zunächst nach zusätzlichem Aufwand. Ich muss etwas entwerfen, bevor Codex programmieren darf, obwohl Codex theoretisch sofort eine erste Oberfläche erzeugen könnte.
Für kleine interne Werkzeuge werde ich diesen Aufwand auch künftig nicht immer betreiben. Wenn eine Seite nur von mir selbst verwendet wird und funktional sehr einfach ist, darf sie weiterhin direkt aus der Implementierung entstehen.
Bei größeren oder nutzerorientierten Anwendungen verändert sich die Rechnung aber.
Wenn das Design vorher geklärt ist, reduziert sich die Wahrscheinlichkeit, dass ich später dieselbe Oberfläche mehrfach strukturell umbauen lasse. Die Umsetzung wird zielgerichteter, die Rückfragen werden konkreter und die Tokenmenge für visuelle Korrekturen sinkt.
Dadurch wird der zusätzliche Schritt für mich nicht zum bürokratischen Overhead, sondern zu einer Investition in eine sauberere Übergabe.
Gute Oberfläche und guter Code bleiben zwei unterschiedliche Qualitätsmerkmale
Ein besonders wichtiger Gedanke dabei ist für mich, dass eine Anwendung technisch hervorragend und gleichzeitig schlecht bedienbar sein kann. Umgekehrt kann eine optisch angenehme Oberfläche auf einer Struktur basieren, die langfristig kaum wartbar ist.
Beides muss deshalb getrennt betrachtet werden.
Die Softwarearchitektur gibt Codex technische Grenzen und Entscheidungsräume vor, während das UI-Design beschreibt, wie ein Benutzer das Ergebnis erleben soll. Die beiden Ebenen beeinflussen sich, dürfen aber nicht miteinander verwechselt werden.
Gerade mit KI kann ich mir diese Trennung heute besser leisten, weil sowohl Designiteration als auch technische Anpassung schneller geworden sind.
Das Ziel ist also nicht, Oberfläche und Code voneinander zu isolieren.
Ich möchte lediglich verhindern, dass die jeweils einfachste technische Umsetzung automatisch zur Benutzeroberfläche wird.
UI-Design wird damit zu einem normalen Teil meines KI-Workflows
Für mich ist das wahrscheinlich die wichtigste Veränderung. Benutzeroberflächen waren bisher der Bereich, in dem meine ansonsten ziemlich strukturierte KI-Arbeitsweise am stärksten in improvisierte Rückkopplungsschleifen zurückfiel: Codex baut etwas, ich schaue es mir an, beschreibe Änderungen, Codex ändert es, und irgendwann nähert sich das Ergebnis meiner Vorstellung.
Mit Penpot und einer klareren Trennung der Phasen möchte ich diesen Prozess verändern.
Das fachliche Konzept beschreibt, was die Anwendung tun soll.
Der UI-Entwurf beschreibt, wie ein Mensch diese Funktionen erleben und bedienen soll.
Codex entscheidet anschließend, wie sich beides sauber in Blazor und die bestehende Architektur übersetzen lässt.
Damit wird die Oberfläche nicht weniger flexibel, sondern im Gegenteil besser diskutierbar und leichter überprüfbar.
Wenn dieser Prozess langfristig funktioniert, schließt sich für mich eine wichtige Lücke: Dann besteht mein KI-gestützter Entwicklungsworkflow nicht mehr nur aus guten Konzepten, schnellem Code und automatisierten Tests, sondern berücksichtigt endlich auch systematisch das, was der Benutzer am Ende tatsächlich sieht.