Fünf Designer, ein Produkt – warum guter Wille allein kein gemeinsames Konzept ergibt
Über das stille Scheitern von Syncs und Design-Reviews in verteilten UX-Teams – und wie echter Kollaboration aussehen könnte.
Transparenzhinweis: Dieser Artikel wurde auf Basis meiner eigenen Erfahrungen und einer strategischen Analyse unserer Teamarbeit mit Unterstützung von Claude (Anthropic) verfasst. Die Inhalte, Bewertungen und Einschätzungen stammen von mir – die Formulierung hat die KI übernommen.
Stell dir fünf UX-Designer vor, die am selben Produkt arbeiten. Jeder engagiert, jeder kompetent, jeder mit gutem Willen. Und trotzdem: Für dasselbe Nutzerproblem entstehen fünf verschiedene Lösungen. Nicht weil jemand schlechte Arbeit leistet – sondern weil alle an verschiedenen Orten sitzen, in verschiedene Scrum-Teams eingebettet sind, und kaum echten Einblick in die Arbeitswelt der anderen haben.
Das ist kein Versagen einzelner Personen. Es ist ein strukturelles Muster, das ich in verteilten UX-Teams immer wieder beobachte.
In diesem Artikel beschreibe ich, was ich für richtig halte – einen Ansatz, den ich entwickelt habe, um dieses Muster aufzubrechen. Nicht als Universalrezept, sondern als Denkvorschlag aus der Praxis.
Das eigentliche Problem: Wir berichten übereinander, statt miteinander zu arbeiten
Die meisten verteilten UX-Teams haben Syncs. Manche haben Design-Reviews. Beide Formate helfen – aber sie lösen das eigentliche Problem nicht.
Im Sync berichtet jeder, womit er gerade beschäftigt ist. Die anderen hören zu, geben Kommentare. Das fühlt sich nach Austausch an. Es ist aber parallele Berichterstattung: Jeder bleibt in seiner Welt, zeigt einen Ausschnitt davon, und geht danach zurück zu seiner Arbeit.
Im Design-Review stellt jemand eine fertige oder fast fertige Lösung vor. Die anderen geben Feedback. Auch das ist wertvoll – aber es hat einen entscheidenden Haken: Wenn ein Konzept erst einmal ausgearbeitet vor uns liegt, sind die wesentlichen Entscheidungen schon gefallen. Was wir dann besprechen, sind Details. Nicht die Richtung.
Beide Formate produzieren Meinungen zu Arbeit, die jemand alleine gemacht hat. Keine gemeinsamen Konzepte.
Solange das so bleibt, wird sich an der Inkonsistenz nichts ändern – egal wie oft wir uns treffen.
Was echte Kollaboration bedeutet – und was sie nicht ist
Der Unterschied klingt klein, ist es aber nicht:
Beim klassischen Review zeigt einer, die anderen kommentieren. Feedback kommt nach der Arbeit, punktuell, und die Verantwortung bleibt beim Einzelnen.
Bei echter Kollaboration erarbeiten alle gemeinsam. Input kommt während der Arbeit. Entscheidungen werden geteilt. Und das Ergebnis gehört dem Team – nicht einer Person.
Das setzt voraus, dass man die Arbeitsrealität des anderen kennt. Wer noch nie erlebt hat, mit welchen Stakeholdern eine Kollegin arbeitet, welche Constraints ihr Scrum-Team hat, welche Fragen ihr täglich begegnen – der kann nicht wirklich kollaborativ denken. Er gibt Feedback aus dem Vakuum.
Was ich vorschlage: Drei konkrete Hebel
1. Hospitationen – einen Tag in der Welt des anderen
Die einfachste und wirkungsvollste Maßnahme, die ich kenne: Ein Designer verbringt einen Tag in der Arbeitsroutine einer Kollegin. Er nimmt an ihren Scrum-Events teil, lernt ihre Stakeholder kennen, versteht ihre Herausforderungen. Nachmittags arbeiten beide gemeinsam an einem konkreten Problem – Pair Design statt paralleles Entwerfen.
Das klingt aufwändig. Ist es aber nicht: Ein Tag, einmal pro Quartal mit jeder Person im Team. Keine große Infrastruktur, kein Workshop-Budget. Nur die bewusste Entscheidung, die Arbeitsrealität des anderen ernst zu nehmen.
Was dabei entsteht, ist mehr als Fachwissen: ein gemeinsames Verständnis dafür, warum jemand so entscheidet, wie er entscheidet. Das ist die Grundlage, auf der kollaboratives Arbeiten trägt.
2. Kollaborative Formate statt Review-Feedback
Statt "Zeig uns deine Lösung, wir kommentieren" ein anderes Grundprinzip: "Bringt ein Problem mit, wir lösen es gemeinsam."
Konkret könnte das so aussehen: Ein Designer stellt ein aktuelles, ungelöstes Problem vor. Das Team skizziert in kurzer Zeit mehrere Lösungsideen – jeder für sich, dann gemeinsam verglichen. Gute Elemente werden kombiniert. Am Ende entsteht ein gemeinsamer Entwurf, nicht ein kommentierter Einzelentwurf.
Das ist keine neue Methode. Design Studios, 6-3-5, Crazy 8s – die Werkzeuge existieren. Was fehlt, ist das Format, das sie regelmäßig und verbindlich einsetzt. Nicht als Ausnahme-Workshop, sondern als Standard.
3. Verbindlichkeit – Kollaboration, die nicht optional ist
Das ist der unbequeme Teil. Kollaboration, die im Kalender als optional markiert ist, verliert immer gegen den Sprint-Druck des Alltags. Das ist keine Frage der Motivation, sondern der Mechanik.
Was ich für notwendig halte: klare Erwartungen, dass übergreifende Zusammenarbeit Teil der Arbeit ist – nicht Bonus. Formate mit echten Ergebnissen, nicht nur Gesprächsrunden. Und die Bereitschaft, Verantwortung zu teilen: Nicht jeder entwirft alles alleine – manche Themen gehören dem Team.
Warum das auch Kompetenzentwicklung ist
Ein verteiltes UX-Team, das wirklich zusammenarbeitet, tut noch etwas anderes: Es nutzt die Stärken seiner Mitglieder besser. UX-Arbeit ist breit – Research, Konzeptarbeit, Prototyping, Usability-Tests, UI. Kein Einzelner ist in allem gleich stark. Im isolierten Modell muss trotzdem jeder alles alleine leisten.
Wer gemeinsam an Features arbeitet, kann einbringen, worin er wirklich gut ist. Und er lernt von denen, die in anderen Bereichen stärker sind – nicht durch Feedback auf Ergebnisse, sondern durch gemeinsames Tun. Das stärkt das gesamte Team langfristig.
Ein Vorschlag, kein Abschluss
Was ich hier beschreibe, ist ein Konzept, das ich auf Basis meiner Erfahrung entwickelt habe – noch nicht vollständig erprobt, aber durchdacht. Ich bin überzeugt, dass der Weg aus dem "Jeder-macht-alles-alleine"-Muster über genau diese drei Hebel führt: ein gemeinsames Verständnis der Arbeitsrealität, Formate die gemeinsames Lösen statt Feedback ermöglichen, und die strukturelle Verbindlichkeit, die beides absichert.
Die übergeordnete Frage – warum UX-Designer in skalierten agilen Umgebungen überhaupt in diese Situation geraten – beschreibe ich in einem anderen Artikel.
Du arbeitest in einem ähnlichen Kontext – oder hast andere Erfahrungen gemacht? Ich freue mich über den Austausch. Schreib mir einfach an.
Dieser Artikel wurde mit Unterstützung von Claude (Anthropic) verfasst. Grundlage war eine strategische Analyse zur Verbesserung der Zusammenarbeit in verteilten UX-Teams, die ich Anfang 2026 ausgearbeitet habe.