von Simone Pompe, Frontend-Entwicklerin und Lisa Reichart, Senior UX/UI-Designerin

Entgegen dem Vorurteil, Design „sorge nur dafür, dass es schön aussieht“ und Entwicklung „setze es irgendwie um“, ist es unser Anspruch bei meteocontrol, das nutzerfreundlichste Erlebnis zu schaffen – für unsere Kunden, die täglich hochkomplexe Energie- und Steuerungssysteme im Blick behalten müssen. Jede frustrierende Interaktion kostet wertvolle Zeit, jede intuitive Interaktion hingegen schafft Fokus. Damit das gelingt, braucht es eine Beziehung, die oft unterschätzt wird: die zwischen Designer:innen und Entwickler:innen.

In unserer Session „An underrated relationship: Wenn Designer und Developer Hand in Hand gehen“ auf der Hackerkiste 2025 haben wir gezeigt, wie enge Zusammenarbeit nicht nur Missverständnisse reduziert, sondern ein Produkt maßgeblich prägt.

Der Weg dahin ähnelt schnell einer schweißtreibenden Runde bei Overcooked – einem kooperativen Computerspiel, wenn klare Absprachen eher einem hektischen Schlagabtausch weichen. Doch klare Prinzipien helfen, den Weg gemeinsam ohne Hürden zu bestreiten.

Von Missverständnissen, Wasserfallprinzip und Frust – und wie es besser geht

Wir alle kennen Projekte, in denen folgende Situationen immer wieder auftauchen:

• Es werden Designs für Komponenten oder User Flows entworfen, bei welchen noch gar nicht klar ist, ob man sie später braucht
• Klar definierte Anforderungen fehlen bereits zum Beginn des Projekts, was spätestens während der Implementierung auf die Füße aller Beteiligten fällt.
• Das Wasserfallprinzip – ein Modell mit streng aufeinanderfolgenden und abgeschlossenen Projektphasen – schleicht sich ein.

Und am Ende fragen sich beide Seiten: „Was für eine Zusammenarbeit führen wir hier eigentlich?“

Damit man ein Fundament aufbauen kann, das beide Seiten einbezieht, statt nur Verantwortung abzugeben, folgen wir vier Grundprinzipien.

Unsere vier Prinzipien für eine starke Design-Entwicklungspartnerschaft

1. Kill the hand-off – Zusammenarbeit beginnt nicht erst nach dem Design

Klassische Übergaben („Hier hast du den Link zu Figma, viel Glück!“) haben schon zu so mancher Frustration geführt. Deshalb sind Übergaben überholt und für uns gilt: 

• Mit den ersten Prototypen eröffnet das Design erste Gespräche mit der Entwicklung, bei komplexen Themen sogar schon früher.
• Die technische Machbarkeit von Anforderungen kann auf diese Weise so früh wie möglich besprochen und im Designprozess beachtet werden.
• Ganz nach dem Stichwort Shared ownership schaffen wir eine Verantwortung für das Projekt auf beiden Seiten, ohne dabei aber Zuständigkeiten zu vermischen.

So vermeiden wir Überraschungen und schaffen Lösungen, die sowohl nutzerfreundlich als auch technisch robust sind.

2. Talk like a team – gemeinsame Terminologie bewahrt uns vor wildem Herumraten

Augenhöhe, reger Austausch und eine gemeinsame Sprache sind hier die Buzzwords. Was das bedeutet?

• Im Designsystem bzw. Styleguide werden gemeinsam geteilte Bezeichnungen für UI-Komponenten verwendet, sodass jede:r weiß, ob ein Modal oder ein Dialog eventuell für ein und dasselbe stehen.
• Es gibt noch offene Fragen? Wir fragen direkt im Team nach! Oft hat sich jemand anderes schon dieselben Gedanken gemacht.
  • Tipp: Wenn man seine Fragen direkt mit einem Lösungsvorschlag versieht, antwortet die befragte Person meistens schneller. Das ist hilfreich in Situationen, in denen wir selbst schon eine gute Idee haben und nur eine Bestätigung suchen.
• Reger Austausch in Form von Dailys, Weeklys – und ganz wichtig: möglichst mit dem „Hot-Potato“-Prozess als Vorbild. Das bedeutet, oft und überlappend miteinander am selben Thema zu arbeiten, weil das die Klärung offener Fragen beschleunigt und das gegenseitige Verständnis fördert.

Sichtbarkeit schaffen in Sprint-Reviews mit den Stakeholdern und auch in dedizierten Design-Reviews – ein Prozess, bei dem UX/UI-relevante Implementierungen von Designer:innen gegengeprüft werden, bevor sie live gehen.

Wenn wir alle dieselbe Kontextbrille teilen, bleibt das Projekt in Bewegung und steuert geradewegs auf das Ziel zu.

3. Single source of truth – Touchpoints der Spezifikationen

Damit Designs und Implementierungen auf Kurs bleiben, müssen wir uns darauf verständigen, wo wir welche Informationen dokumentieren wollen. Das beugt Missverständnissen vor und hilft dabei, dass alle Informationen up-to-date bleiben, weil sie nicht an fünf verschiedenen Stellen abgelegt sind.

Damit meinen wir konkret:

• Designanforderungen gehören nicht ins Ticket. Sie leben in unserem Designtool (Figma).
• Komponenten werden einheitlich gepflegt – in unserer bereits implementierten Komponentenbibliothek und sowie auch im Designsystem in Figma, das mit unserem Styleguide in Zeroheight synchronisiert ist.

Nur wenn sich beide Welten sich gegenseitig auf dieselben Quellen beziehen, entsteht Konsistenz – im Produkt und im Team.

4. Respect finished work – Kompromisse statt Blockern und Neuanfängen

Was passiert, wenn sich ein Ticket bereits in der Code-Review befindet und plötzlich die Nachricht eintrifft: „Mir ist da noch etwas aufgefallen ...”. Die Frustration gewinnt die Oberhand und die Sorge wächst, dass alles bisher Implementierte nun geändert werden muss. Deshalb achten wir darauf:

• Aufgaben in möglichst kleine Teilschritte aufteilen. Dadurch werden Refinements kürzer und Aufwandsschätzungen stabiler.
• Änderungen können jederzeit auftreten. In solchen Fällen sollte das Team gemeinsam entscheiden, ob ein Follow-up-Ticket zur Bearbeitung der neuen Anforderung sinnvoll ist oder ob das bestehende Ticket geblockt werden muss.
• Kompromissbereitschaft nicht nur fordern, sondern auch leben: In Streitfällen macht es Sinn, zuerst sachliche Argumente für beide Seiten zu sammeln und zu gewichten. Auf dieser Basis fällt es oft einfacher, sich als Team für einen neuen Weg zu entscheiden.
• Stillstand vermeiden – aber auch kein „Alles wird neu gemacht“, wenn es nicht nötig ist.

Respekt für geleistete Arbeit ist Wertschätzung und sorgt dafür, dass Teams motiviert bleiben, statt auszubrennen.

Was das in der Praxis verändert

Mit unserem Talk wollten wir zeigen, was passiert, wenn wir die Design-Dev-Gap weiter schließen. 
Plötzlich werden Ideen nicht nur diskutiert, sondern weitergedacht. Designs entstehen nicht im luftleeren Raum, sondern wachsen gemeinsam mit der Entwicklung. Ein Entwurf wird im Austausch zwischen Design und Entwicklung hinterfragt, angepasst und technisch mitgedacht – vom ersten Konzept bis zur Umsetzung. Und ganz nebenbei versteht das gesamte Team Hintergründe, sieht Zusammenhänge und entwickelt gemeinsam Lösungen, die tatsächlich funktionieren und Unklarheiten beseitigen.

Fazit: Gelebte Zusammenarbeit ist kein Nice-to-have – sie ist das Fundament

Design und Entwicklung bei meteocontrol verfolgen dasselbe Ziel: Produkte zu schaffen, die unsere Kund:innen in ihrem Arbeitsalltag unterstützen.
Wenn beide Seiten von Anfang an gemeinsam denken, sprechen und entscheiden, entsteht echte Partnerschaft. Das Ergebnis ist eine Software, die nicht nur funktioniert, sondern echten Mehrwert liefert.