Entwickler & Designer – Tipps für interdisziplinäre Zusammenarbeit

Innerhalb Softwareentwicklungsteams ist die Beziehung zwischen der Entwicklung und dem Design eine ganz besondere. Beide können nicht ohne einander funktionieren – die erfolgreiche Arbeit des anderen ist für ihr eigenes Werk essentiell. Arbeiten (UX/UI-)Designer und Programmierer eng zusammen, kann es so natürlich auch schnell zu Reibungen kommen, und das kann das gemeinsame Projekt gefährden. Das Zauberwort, um diese Probleme zu lösen, lautet interdisziplinäre Zusammenarbeit. Doch fangen wir erst mal von vorne an:

 

Ein Beispiel aus einem interdisziplinären Projekt, bedingt durch mangelnde Absprache:

Designer A ist stolz auf seinen kreativen Output und beharrt auf seinen gestalterischen Vorgaben, die er auch so im fertigen Produkt wiederfinden möchte. Entwickler B sieht in diesen Vorgaben allerdings zuerst einmal die mangelnde Umsetzbarkeit. Diese Beschränkungen wiederum waren Designer A nicht bekannt, und er meint, dass Entwickler B ihn davon hätte in Kenntnis setzen müssen. Entwickler B hingegen hält diese für selbstverständlich.

Wer im Endeffekt Recht hat, ist für das Projekt völlig irrelevant. Sicher ist nur, dass es einen Schaden davonträgt.

 

Diskrepanzen dieser Art kommen zwischen Developern und Designern leider recht häufig vor.

Aus diesem Grund widmet sich dieser Artikel einer Annäherung der zwei Disziplinen, um diese unwahrscheinlich wichtige Beziehung ein Stück weit zu verbessern.

 

Interdisziplinäre Kollaboration bei SEVEN PRINCIPLES

SEVEN PRINCIPLES arbeitet agil. Ein Kerngedanke dieses Arbeitsmodells: die interdisziplinäre Zusammenarbeit.

Bei 7P arbeiten wir mit vielen Kollegen aus unterschiedlichen Fachbereichen zusammen, die auch jederzeit bereit sind, mit ihrer Expertise einem anderen Kollegen zu helfen – sei es durch aktive Mitarbeit oder einfach durch einen Rat bei einem besonders schwerwiegenden Problem.

 

Bei der Softwareentwicklung kann das zum Beispiel so aussehen: Der Designer hat eine konzeptionelle Idee im Kopf und würde sie gerne testen. So sucht er sich zwei Entwickler innerhalb seines Projektteams und setzt sich mit ihnen ein paar Stunden zusammen, um einen benutzbaren Prototypen für seine Idee zu bauen. Wenn dieser dann die erhofften Ergebnisse bringt, ist das großartig. Wenn nicht, ist man zumindest um die Erkenntnis reicher, wie es nicht geht.

Eine gute Möglichkeit zum interdisziplinären Austausch können auch regelmäßige, offene Fachgruppenmeetings sein. Man kann hier sein Problem einigen Kollegen vorstellen, die mit einem ganz anderen Auge draufschauen und möglicherweise Lösungsansätze finden, auf die man selbst gar nicht kommen würde.

 

Ein echtes Fachgruppenmeeting sieht natürlich weniger nach einem Stockfoto aus, doch kommt der interdisziplinäre Zusammenarbeit sehr nahe.

 

Rollenverteilung im agilen Kontext

Die interdisziplinäre Zusammenarbeit ist bei uns essentieller Bestandteil aller Projekte. Kommunikation, Kollaboration und Ideenaustausch sind allerdings auch immer eine Herausforderung, wenn unterschiedliche Disziplinen aufeinandertreffen.

 

Wie sehen die möglichen Probleme nun aus? Und vor allem: Wie kann man sie vermeiden?

 

Wollen Designer und Entwickler erfolgreich zusammenarbeiten, müssen sie sich entgegenkommen. Jedem Mitarbeiter muss daran gelegen sein, die Arbeit seines Kollegen so leicht wie möglich zu machen und nicht zu behindern. Eben so, wie man es sich andersherum auch wünschen würde.

Dabei ist die althergebrachte Aufteilung aus dem Wasserfallmodell „erstens Design, zweitens Entwicklung“ bei einer agilen, adaptiven Arbeitsweise nicht mehr sinnvoll. Zwar bedarf es häufig einiger früher Designentscheidungen, um die Entwicklung voranzutreiben, der Designer sollte zur Optimierung seiner Arbeit aber weiterhin ins fortlaufende Projekt involviert sein.

 

Ein möglicher Lösungsweg: Vor der Umsetzung startet der Designer mit der Erstellung einer generellen „Experience“ (Flowchart, Navigationsstruktur, etc.). Die detaillierte, pixelgenaue Designarbeit wird daraufhin immer einen Sprint vor der Implementierung durch den Entwickler erstellt. Es wird also immer das designt, was im nächsten Sprint entwickelt werden soll. So ist zum einen eine Struktur und zum anderen die langfristige Verfügbarkeit des Designers für das Projekt gewährleistet, falls nachträglich Änderungen vollzogen werden müssen.

 

Wie auch immer man bei der Zusammenarbeit nun vorgeht: Bei alldem ist jederzeit ein gemeinsamer Informationsstand zu gewährleisten. Wenn alle Teammitglieder auf dem gleichen Wissensstand sind, können sie am besten voneinander profitieren.

 

Spielregeln für eine erfolgreiche interdisziplinäre Zusammenarbeit

Einer der ersten Fehler, die man in einem interdisziplinären Team machen kann, ist nicht früh genug zu kommunizieren.

Wer eng im Team zusammenarbeitet, muss einen gemeinsamen Weg finden. Deshalb sollte zu Beginn jedes Projekts eine Erwartungshaltung definiert werden. Strukturen und Prozesse sollten zudem aufeinander abgestimmt werden. Will man zum Beispiel inkrementell arbeiten oder fühlt man sich mit etwas mehr Vorarbeit wohler?

Des Weiteren sollte Klarheit über die Vorgehensweise beider Seiten herrschen und ein gemeinsamer Standard festgelegt werden.

  • Für welche Screengrößen braucht der Entwickler Designs?
  • Weiß der Designer, wie zum Beispiel Layout Constraints funktionieren?
  • Wurde über das Wording gesprochen?
  • Wie sieht es mit Margins, Paddings, Grids aus?
  • Wie sollen dynamische UI-Elemente agieren?
  • Wurde der Userflow von beiden Seiten durchdacht?

Wenn diese Dinge vorher geklärt wurden, spart man sich nachher viel Zeit und Mühe.

 

Einen großen Schritt in Richtung beiderseitigem Entgegenkommen kann der Designer mit einem einfachen Grundsatz machen: Genauigkeit. Bezüglich der User Experience heißt das beispielsweise, dass der Userflow lückenlos und ohne Sackgassen funktionieren sollte, um den Entwickler nicht mit offenen Fragen zurückzulassen. Beim User Interface Design ist damit die Pixelgenauigkeit gemeint, die Fehlinterpretationen bei der Implementierung so weit wie möglich einschränkt.

Regelmäßige „Pair Programming“-Sessions zwischen Programmierer und Designer können dabei letzte Zweifel beseitigen: Der Entwicklungsfortschritt wird regelmäßig gemeinsam begutachtet und eventuelle Designabweichungen werden direkt korrigiert. Dabei lernt man voneinander, und der Programmierer entwickelt so selbst ein Verständnis für Visualität und Gestaltung, während der Designer mit den Herausforderungen der Umsetzung konfrontiert wird.

 

Interdisziplinäre Zusammenarbeit - Pair Programmer

Zwei erfahrene Pair Programmer.

 

Umgang mit Kritik

Ein essentieller Bestandteil für gute interdisziplinäre und agile Zusammenarbeit ist erfahrungsgemäß eine funktionierende Feedbackkultur. Gerade beim Thema Design kann sowohl eine falsche Abgabe als auch Annahme von Kritik zu erheblichen Irritationen führen.

So sollte man sich immer bewusst sein, dass Design von Nicht-Designern immer leicht zu kritisieren ist, weil es greifbarer als z.B. Code ist. Zu einem Interface kann grundsätzlich jeder sagen, ob es ihn anspricht oder nicht. Designkritik (so wie das Design selbst) ist in den meisten Fällen subjektiv. Als Designer muss man lernen, andere Meinungen zu akzeptieren und daraus keinen Frust entstehen zu lassen.

Als Entwickler hingegen sollte man versuchen, in seiner Ansprache sachlich und respektvoll aufzutreten und seine Meinung auch immer zu begründen. Aussagen wie „Ich mag die Farbe von dem Element nicht, keine Ahnung wieso“ bieten dem Designer keine konkreten Anhaltspunkte, um etwas zu verbessern.

Bei besonders hartnäckigen Debatten kann es außerdem helfen, die Teamkollegen hinzuziehen. Oftmals ist hier ein Kompromiss die sinnvollste Lösung.

 

Was kann man noch tun?

Einen grundsätzlichen Gedanken kann man bei allen aufgelisteten Punkten wiederfinden: Designer und Entwickler müssen versuchen, sich in ihr Gegenüber hineinzuversetzen.

 

Zum Abschluss noch ein Tipp dazu: Generell kann jeder Designer in hohem Maße davon profitieren, wenn er (mit Hilfe eines Developers) einfach mal selber etwas programmiert, zum Beispiel eine Mobile App in Android Studio oder Xcode. Erst beim Selbermachen wird die Arbeitsweise von Entwicklern so richtig verstanden. Genauso kann der Entwickler einiges lernen, wenn er dem Designer beim Bauen eines Interfaces mit dem Grafiktool seiner Wahl über die Schulter schaut oder – noch viel besser – es selbst einmal versucht.

 

Die Möglichkeiten sind da, um Kenntnisse aus der anderen Disziplin zu erlangen. Also nutzen wir sie doch einfach auch!

Interdisziplinäre Zusammenarbeit - Am besten versetzt man sich in den Kollegen hinein

 

Kontakt

Wie sind Ihre Erfahrungen zu diesem Thema? Wir freuen uns über Ihre Kommentare.

Weitere Information zu unserem AMR Team finden Sie hier auf unserer Seite:
https://www.7p-group.com/leistungen/application-development-management/

Oder nehmen Sie direkt Kontakt zu unserem Team auf:
https://www.7p-group.com/kontakt-3/