Ich arbeite täglich mit KI. Nicht in einem Pilotprojekt, nicht als Experiment – als Arbeitsweise, die sich über die letzte Zeit herausgebildet hat. Dabei habe ich gelernt, wo mich KI wirklich weiterbringt und wo sie mich bremst. Das hier ist keine Studie und kein Vergleichstest. Es ist reflektierte Praxis. Und ab und zu reitet es mich, wieder direkt mit Figma Make loszulegen – um jedes Mal festzustellen: Das ist es nicht.
Es gibt für mich zwei grundverschiedene Arten, mit KI zu arbeiten.
Die erste ist die textuelle Auseinandersetzung. Ich diskutiere Konzepte, Abläufe, Varianten – mit der KI als Gegenüber, das kritisiert, nachfragt, Optionen durchspielt. Jede Runde produziert ein Argument. Argumente sind billig zu revidieren. Ich nenne das Hochleveln: Wir steigen gemeinsam in ein kompliziertes Thema ein, und nach einer Stunde verstehe ich es besser als vorher. Nicht weil die KI die Antwort wüsste – sondern weil sie Muster aufzeigt, weil sie mich zwingt, meine Position zu schärfen. Selbst ihre Fehlinterpretationen sind produktiv: Wer korrigieren muss, muss nochmals durchdenken.
Dabei hilft mir UFMn, eine Notation, die Abläufe auf Mockup-Ebene beschreibt – nicht abstrakt wie ein Flussdiagramm, sondern dort, wo der Nutzer tatsächlich unterwegs ist. Sie zwingt mich, den Prozess vollständig zu denken – und sie transportiert diese Logik so, dass auch die KI versteht, wie die Story abläuft.
Die zweite Art ist das KI-gestützte visuelle Erzeugen. Prompt rein, Screen raus. Der erste Wurf beeindruckt – und genau das ist das Problem. Er wird zur Referenz, an der ich fortan herumschraube. Ich bin geblendet vom Visuellen, vom Gelungenen wie vom Unschönen. Dabei geht es in diesem Moment gar nicht um Optik. Es geht um Prozesse, Struktur, Abhängigkeiten – und die stelle ich erst beim Durchdenken und Ausprobieren fest. Nur: Der grosse Wurf steht dann schon da. Jede grundsätzliche Änderung muss ich gegen diese erste Lösung durchsetzen, jede Korrektur arbeitet gegen ein fertiges Bild an und bringt unerwünschte Nebeneffekte mit. Die eigentliche Diskussion – was soll das Ding überhaupt tun? – muss ich ausserhalb des Werkzeugs führen. Denn ein visuelles Ergebnis ist immer schon eine Antwort. Auch dann, wenn die Frage noch offen ist. Es gibt im Werkzeug keinen Ort für den Zustand «darüber sind wir uns noch nicht einig».
Der Aufwand verschwindet also nicht. Er verschiebt sich – vom Konzipieren ins Nachkorrigieren. Und dort ist er teurer.
Ich überspringe die KI nicht. Ich orchestriere sie.
Bevor etwas visuell wird, schaffe ich Struktur: Abläufe klären, Fokus setzen, Testdaten strukturiert aufbereiten. Erst dann übergebe ich an das Werkzeug – Screen für Screen, mit präzisem Auftrag. So iteriere ich selbst innert Stunden: umdesignen, prüfen, nachschärfen. Nach vier solchen Runden stand zuletzt eine Lösung auf Wireframe-Ebene, mit der ich ins Nutzertesting eingestiegen bin – und mit Nutzern brauchte es dann noch eine, vielleicht zwei Runden. Die Feinabstimmung – was wird grösser, was kleiner, was wohin – mache ich weiterhin von Hand. Von Hand bin ich da schneller. Und ehrlicherweise: Kein Entwurf, den ich einfach dahin gepromptet habe, war je gut genug.
Dieses Durcharbeiten ist anstrengend. Es ist aber kein Umweg, sondern Teil des Ergebnisses – nur nicht, weil Handarbeit eine Tugend wäre. Sondern weil ein Teil der Qualität beim Durchlaufen der Entscheidungen entsteht: Ich kenne danach nicht nur den Entwurf, sondern auch die verworfenen Varianten und ihre Gründe. Erfahren, nicht gelesen. Das zeigt sich später im Nutzertest: Wer seinen Entwurf so kennt, erfasst Abweichungen schneller und führt ein anderes Gespräch mit den Testnutzern.
Ich baue keine Consumer-Apps, die man am lebenden Nutzer nachiteriert. Ich baue Fachapplikationen in gewachsenen Ökosystemen. Brownfield: Da hängen Schnittstellen dran, andere Systeme, Restriktionen. Herumprobieren nach dem Rollout ist nicht unmöglich – aber teuer und langsam. Das verschiebt die Iteration zwingend nach vorne: in Research, in detaillierte Analyse, in ein sauberes Problemverständnis, in Prototypen, die auch Edge-Cases und mehrere Varianten abdecken.
Ist das gegen die Agilität? Ich denke nicht. Ich iteriere mehr als manches Team – nur früher und im billigeren Medium. Vier Iterationen auf Wireframe-Ebene kosten Stunden bis Tage. Vier Iterationen am produktiven System kosten Releases. Agil heisst für mich nicht, im Code zu iterieren. Es heisst, in kurzen Schleifen zu lernen – und die kürzeste Schleife liegt vor der Entwicklung.
Für mich funktioniert diese Arbeitsweise sehr gut: Im Text werde ich mit der KI besser – schneller im Denken, vollständiger im Konzept, schärfer in den Optionen. Im Visuellen werde ich mit ihr nur schneller, und auch das nur, wenn ich vorher die Struktur geschaffen habe. Der grösste Gewinn liegt am Ende in der Gesprächsfähigkeit – mit Nutzern, Stakeholdern, Entwicklern, Management. Wer die Entscheidungen durchlaufen hat, kann sie vertreten. Wer nur das Ergebnis kennt, kann es nur zeigen.