Verbundene Disziplinen

Und immer wieder stellt sich dieselbe Frage: Sollten Designer Code verstehen? Sollten Entwickler wie Designer denken? Es ist eines dieser Themen, die nicht deshalb bestehen bleiben, weil sie besonders hilfreich sind, sondern weil sie nie wirklich gelöst werden.

Und vielleicht liegt genau darin das Problem: Diese Diskussion basiert auf einer falschen Annahme – nämlich, dass bessere Zusammenarbeit durch gemeinsame Skillsets entsteht. Das ist eine verlockende Idee und wird meist von zwei Gruppen vertreten.

Zum einen von den Hybriden – jenen seltenen Menschen, die beides gut können und glauben, ihre Erfahrung ließe sich mit genug Bootcamps oder Tutorials reproduzieren.

Zum anderen von den Frustrierten, denen, die sich wünschen, „die andere Seite“ würde endlich verstehen, womit sie täglich zu kämpfen haben.

Beide meinen es gut. Aber sie lösen das falsche Problem.

Echte Expertise in Design und Entwicklung entsteht nicht in ein paar Wochen. Sie ist das Ergebnis jahrelanger Erfahrung im Umgang mit Ambiguität – im Erkennen von Mustern, die anderen entgehen. Vor allem, wenn es darum geht, Probleme zu identifizieren, nicht nur zu lösen: Erfahrung ist entscheidend.

Zusammenarbeit scheitert nicht daran, dass Menschen zu wenig vom jeweils anderen Bereich wissen. Sie scheitert daran, dass unsere Rollen auf Übergaben statt auf Verständnis ausgelegt sind.

Und genau das ist das eigentliche Problem.

Das Problem

Das Problem vieler Rollenbilder in Produktteams ist, dass sie auf Lieferung optimiert sind – nicht auf Verständnis. Verantwortung wird entlang von Übergaben organisiert, nicht entlang von Gesprächen. Stakeholder übergeben an „UX/UI“. UX/UI übergibt an Frontend. Frontend übergibt an Backend. Jede Rolle wird zu einer Station in einer Pipeline: linear, getrennt und voneinander entkoppelt.

Diese Struktur setzt voraus, dass Probleme zu Beginn klar definiert sind und jede Übergabe lediglich zusätzliche Präzision bringt. Doch so funktioniert Produktentwicklung nicht. Erkenntnisse entstehen mitten im Prozess. Prioritäten verschieben sich.

Was gebraucht wird, sind nicht reibungslosere Übergaben, sondern Rollen, die auf Interpretation ausgelegt sind, nicht nur auf Ausführung.

Und hier liegt das eigentliche Problem: Zwischen diesen Stationen fehlt etwas Entscheidendes. Spezialisierungen, die verbinden, statt nur weiterzureichen.

Die Trennlinien

Viele Teams kämpfen mit Lücken in Qualität, Klarheit oder Zusammenarbeit. Nicht, weil Menschen unqualifiziert sind, sondern weil ihre Rollen zu breit angelegt sind.

Stellenausschreibungen suchen nach „UX/UI“ und bekommen schwaches UX oder schwaches UI.

Sie suchen nach „Frontend“ und bekommen Entwickler, die APIs anbinden können, aber ein Designsystem nicht umsetzen, ohne es zu zerbrechen.

Das Problem ist nicht Talent. Es ist Struktur.

Was fehlt, ist eine klarere Aufteilung von Verantwortlichkeiten. Die meisten Teams übersehen zwei zentrale Trennlinien, obwohl sie täglich mit ihnen arbeiten:
eine in der Entwicklung, zwischen Model/Controller und View,
und eine im Design, zwischen UX und UI.

Das sind keine theoretischen Kategorien. Es sind unterschiedliche Denkweisen.

Wenn wir diese Unterschiede nicht explizit machen, erwarten wir weiterhin, dass Menschen Lücken schließen, für die sie nie ausgebildet wurden.

Früher war diese Trennung offensichtlich. Als PHP die Logik übernahm und HTML/CSS das Layout, war die Aufteilung im Stack verankert. Heute laufen moderne Frameworks vollständig im Browser. Die Grenzen sind in einer Rolle namens „Frontend“ verschwunden.

Doch das Denken hat sich nicht angepasst.

Wir schreiben View-Code mit einem Model-Denken.

Das ist eine Rückkehr zu etwas, von dem wir dachten, wir hätten es längst hinter uns gelassen: Full Stack.

Zwei Arten von Frontend

Moderne Frontend-Entwicklung bewegt sich in zwei Welten. Aber wir haben nur eine Rollenbezeichnung dafür.

Auf der einen Seite steht die Welt der Logik: Datenmodelle, State Management, APIs, Architektur, Performance.
Auf der anderen Seite die Welt der visuellen Systeme: Layout, Abstände, Interaktion, Barrierefreiheit, Hierarchie.

Beides findet in denselben Dateien statt, verlangt aber völlig unterschiedliche Denkweisen.

Die eine denkt in Abläufen, die andere in Bildern.
Diese Perspektiven unterscheiden sich grundlegend.

Für Entwickler ist eine Basiskomponente ein abstrakter Typ, der viele Varianten unterstützt.
Für Designer ist die Basis der zentrale Anwendungsfall, der sichtbare.

Dieser Unterschied prägt, wie Komponenten aufgebaut werden, wie Tokens benannt sind und wie Defaults gesetzt werden. Fehlende Abstimmung führt zu Reibung. Reibung zu Workarounds. Und Workarounds zu Verschwendung.

Wenn Teams diese Trennung nicht erkennen, versuchen sie, sie mit Tools zu überbrücken: vorgefertigte UI-Kits, Designsysteme „out of the box“, Component Frameworks.

Diese Werkzeuge sind nicht schlecht, werden aber oft genutzt, um Kompetenzlücken zu kaschieren, statt eine Designstrategie zu unterstützen.

Das Ergebnis ist Abhängigkeit statt Klarheit. Komponenten stapeln sich, überschreiben sich gegenseitig, entfernen sich schrittweise von der Marke. Designsysteme werden zu Implementierungshüllen, nicht zu kohärenten, lebendigen Werkzeugen.

Wir brauchen keine Menschen, die beide Welten vollständig beherrschen.
Wir brauchen Rollen, die der tatsächlichen Arbeit entsprechen.

Application Developer sollten sich auf Logik konzentrieren: Modelle, Orchestrierung, Verhalten.
UI Developer auf die Darstellung: Abstände, Tokens, Motion, Systemdenken.

Beides ist Frontend.
Aber es ist nicht dasselbe.

Keine Disziplin, sondern zwei

Der Begriff „UX/UI“ ist so verbreitet, dass er wie ein einzelner Beruf klingt. In der Praxis ist er jedoch meist nur ein anderes Wort für UI.

Die meisten sogenannten UX/UI-Rollen beschäftigen sich mit Screens, Abständen und Interaktionen. Nutzerforschung, Flows und Produktlogik fehlen oft oder werden auf Stakeholder-Input reduziert.

Das Ergebnis: Design ohne Erkenntnis.
Malen nach Zahlen.

UX ist Teil von Design. Aber es funktioniert nicht wie UI.
Während UI sich auf visuelle Systeme konzentriert, arbeitet UX mit Methoden aus Forschung, Analyse und Produktstrategie. UX fragt nach dem eigentlichen Problem, nicht nur danach, wie man das vermeintliche löst.

In diesem Sinne ist UX das, was Design Thinking zu sein vorgibt: ein strukturierter Weg, Bedürfnisse zu verstehen, bevor Lösungen gestaltet werden.

UX bewegt sich näher an Business-Analyse, Requirements Engineering und Systemarchitektur als an visueller Gestaltung. Alle vier beschäftigen sich mit dem, was gebraucht wird.

Aber nur UX stellt die Frage, ob eine Anforderung auf Symptomen oder auf Ursachen basiert.

Das ist kein kreativer Akt.
Es ist ein diagnostischer.

UI dagegen ist expressiv und synthetisch. Es nimmt Rahmenbedingungen und bringt sie in Form. Es arbeitet mit visuellen Systemen, Konsistenz, Mustern und Erfahrung über Zeit.

UX und UI formen zusammen ein Produkt, aber aus entgegengesetzten Richtungen.
Das eine definiert den Problemraum.
Das andere gestaltet seine Oberfläche.

Manche Menschen beherrschen beides. Das macht die Trennung nicht weniger relevant, im Gegenteil. Wenn eine Person beide Seiten verantwortet, verschwinden Konflikte nicht. Sie werden nur unsichtbar.

Strategische Spannungen werden zu inneren Dilemmata.
Und Designentscheidungen entstehen ohne Dialog.

Verständnis statt Verschmelzung

Die Idee, dass Entwickler Design lernen sollten und Designer programmieren, hat nach wie vor ihren Wert.

Aber nicht, weil wir mehr Hybride brauchen.

Es geht nicht darum, Rollen zu wechseln. Es geht darum, gegenseitiges Verständnis aufzubauen.

Die Grundlagen einer anderen Disziplin zu kennen, hilft bei der Zusammenarbeit – nicht dabei, einander zu ersetzen.

Gute Zusammenarbeit entsteht nicht, indem man Rollen in einer Person zusammenführt.
Sie entsteht durch Klarheit.

Menschen brauchen Tiefe im eigenen Handwerk und ein funktionales Verständnis der angrenzenden Disziplin. So entsteht eine gemeinsame Sprache.

Nicht durch identische Fähigkeiten, sondern durch Kontextbewusstsein.

Wenn Teams verstehen, wie ihre Arbeit zusammenhängt, hören sie auf, Dinge über den Zaun zu werfen und beginnen, am selben Produkt zu bauen.

Rollen zu verschmelzen wirkt oft effizient.
In der Praxis erzeugt es Unsicherheit.

Niemand weiß mehr genau, was erwartet wird. Arbeit wird doppelt gemacht oder bleibt liegen. Lücken werden ad hoc gefüllt. Und am Ende fühlt sich niemand wirklich verantwortlich.

Verständnis macht Zusammenarbeit möglich.
Aber Klarheit macht sie produktiv.

Gegenseitiges Verständnis verbessert nicht nur Übergaben. Es verändert auch den Umgang mit schwierigen Aufgaben.

Wenn Entwickler wissen, dass Designer die Komplexität ihrer Anforderungen verstehen, sind sie eher bereit, sich darauf einzulassen.

Respekt macht Anforderungen anschlussfähig.
Was sich wie Reibung anfühlt, entsteht oft nicht aus Faulheit oder Ego, sondern aus fehlendem Kontext.

Von der Pipeline zum Netzwerk

Produktentwicklung verläuft nicht in eine Richtung.
Sie pulsiert, macht Schleifen, verdichtet sich und verzweigt sich wieder.

Die alte Vorstellung eines Prozesses, der von Research über Design zu Entwicklung und schließlich zur Auslieferung führt, passt nicht mehr zu der Art, wie Teams heute arbeiten sollten. Erkenntnisse entstehen spät. Abhängigkeiten verschieben sich.

Was wie eine gerade Linie aussieht, ist in Wirklichkeit ein Geflecht aus überlappenden Entscheidungen, Feedbackschleifen und Iterationen.

Rollen sollten sich nicht aneinanderreihen. Sie sollten miteinander in Beziehung stehen.

UX und Systemarchitektur prägen gleichermaßen, was gebaut wird – und warum.
UI-Design und UI-Entwicklung arbeiten Seite an Seite, um Produkte zum Leben zu bringen.
Application Developer und Backend Engineers stimmen sich über Datenstrukturen und Nutzerlogik ab.

Jede Rolle ist mit anderen verbunden.
Nicht als Schritt in einem Ablauf, sondern als Knoten in einem Netzwerk.

Das Ziel ist nicht länger die effiziente Übergabe, sondern ein gemeinsames Verständnis in einem vernetzten System.

Jede Rolle braucht Tiefe in ihrer eigenen Perspektive und ein Bewusstsein für die angrenzenden. So entsteht Qualität.

Nicht dadurch, dass alle alles machen.
Und nicht durch perfekte Dokumentation.
Sondern durch eine Struktur, in der Menschen in Netzwerken denken, nicht in Pipelines.

Verbundene Rollen, bessere Produkte

Die Spannung zwischen Design und Entwicklung war nie das eigentliche Problem.

Das Problem ist strukturell.

Rollen wurden verwischt, überdehnt oder zusammengelegt. Auf eine Weise, die Kommunikation erschwert und Verantwortung verwässert.

Teams brauchen keine zusätzlichen Hybrid-Skills.
Sie brauchen klarere Rollen und bessere Verbindungen zwischen ihnen.

Das ist kein Rückschritt.
Es ist ein Schritt hin zu der Art, wie moderne Produktteams tatsächlich arbeiten.

Agile Methoden zielten nie darauf ab, alle zu Generalisten zu machen. Es ging um Zusammenarbeit, Iteration und gemeinsame Verantwortung.

All das wird einfacher, wenn Rollen so gestaltet sind, dass sie miteinander interagieren – nicht, dass sie einander ersetzen.

Das fehlende Bindeglied in vielen Teams ist der UI Developer.

Kein Unicorn.
Kein Luxus.

Sondern ein Spezialist, der visuelle Systeme und Code gleichermaßen versteht.

Jemand, der Designentscheidungen in Produktrealität übersetzt.

Fehlt diese Rolle, beginnen Designsysteme zu driften, Component Libraries zu fragmentieren – und Teams lösen Probleme, die sich mit der richtigen Verbindung von Anfang an hätten vermeiden lassen.

Auf den ersten Blick wirkt eine stärkere Rollentrennung teuer: mehr Menschen, mehr Titel, mehr Abstimmung.
Doch der Gewinn ist real.

Weniger Nacharbeit. Schnellere Umsetzung. Weniger Übergaben, die auf dem Weg verloren gehen.

Klare Rollen schaffen Geschwindigkeit durch Fokus und Qualität durch Abstimmung.

Das ist kein Overhead.
Das ist ein Hebel.