Ich arbeite mittlerweile seit über 14 Jahren als Entwickler bei //SEIBERT/MEIDA. In dieser Zeit hat sich das Unternehmen (stark) verändert und ist mit seinen Anforderungen gewachsen. Während in vielen anderen Unternehmen Design/Konzeption und Entwicklung immer noch getrennte Prozesse sind, hat bei uns der Schritt weg von fachbezogenen und hin zu interdisziplinären Teams die Unternehmenskultur maßgeblich geprägt. Drei Jahre ist es nun her, dass sich unser "Design-Team" in die "Entwickler-Teams" hinein aufgelöst hat.
Dabei sind die flachen Hierarchien im Unternehmen und die Agile Organisation sehr von Vorteil gewesen. Denn egal ob Consultant, Designer, IT-ler, Entwickler, ProductOwner oder ScrumMaster - jeder kann Ideen einbringen oder vorantreiben, und das nicht nur innerhalb seines Teams oder Fachbereichs, sondern auch unternehmensstrategisch.
Als Mitglied des Marketing-Teams schätze ich die gute Zusammenarbeit mit meinen Kollegen und als Frontend-Entwickler vor allem die direkte Zusammenarbeit mit unserer Designerin Diana.
Hier besteht die Herausforderung darin, dass unterschiedliche Fachbereiche mit unterschiedlichen Anforderungen aufeinandertreffen. Bei der Umsetzung einer Webseite beispielsweise stelle ich mir ganz andere Fragen als ein Designer.
Als Entwickler liegt mein Fokus eher auf den funktional-technischen Aspekten:
- "Funktioniert" die Webseite? (Kann man alles anklicken/abschicken, ist das Tracking einwandfrei?)
- Ist die Seite fehlerfrei?
- Kann man die Seite in allen (bzw. definierten) Browsern (und Versionen) aufrufen?
- Sind die Inhalte für unterschiedliche Devices ausgelegt?
- Ist die Performance optimal?
Ein Designer geht die Aufgabe eher User-fokusiert an:
- Was will der Besucher der Seite?
- Wie kommt er einfach an die gesuchten Infos?
- Wie ist der optimale Seitenaufbau, damit die relevanten Inhalte schnell gefunden werden? (Stimmt die Blickführung auf der Seite?)
- Funktioniert die Nutzerführung? (Versteht der User, wo er was findet? Wird verständlich dorthin geleitet?)
- Ist das Corporate Design ordentlich umgesetzt?
- Wie sieht das ganze "responsive" aus? (Wie bricht was um? Welche Inhalte sind auf einem Smartphone sinnvoll?)
Das sind nur einige von vielen Fragen, die bei der Erstellung einer Website aufkommen. Und ehe so detaillierte Fragen entstehen, sind schon viele Stunden in das Projekt geflossen. In den frühen Projektabschnitten steigen die Designer ein, bevor überhaupt an die erste Codezeile gedacht wird. In der Konzeptionsphase ist es dennoch wichtig, dass die Kollegen hier auch schon an die spätere Umsetzung denken und die IT-ler oder Entwickler abholen. So ist schnell erkennbar, ob eine Kundenanforderung überhaupt technisch machbar ist oder den Rahmen des Budgets überschreitet. Eine gewisse Kompetenz im Hinblick auf den nächsten und den vorherigen Arbeitsschritt sollten daher sowohl Designer als auch Entwickler mitbringen.
Kommunikation ist alles
Bleiben wir beim Beispiel "Umsetzung eines Website-Templates". Wer kennt es nicht: Im statischen Layout sieht alles schön rund und sauber aus, aber sobald ein flexibler Browser, ein kleines, altes Smartphone oder ein großer Touch-Screen ins Spiel kommt, fliegt einem alles um die Ohren.
Daher halte ich es für wichtig, so früh wie möglich (und auch schon während der Layout-Erstellung) einbezogen zu werden. Meistens reicht es bereits aus, erste Zwischenergebnisse zu sehen, um mögliche Herausforderungen zu identifizieren oder parallel schon einen kleinen Prototypen zu bauen. Diese Ergebnisse bespreche ich mit den kreativen Kolleginnen, um hier gemeinsame Erfahrungen festzuhalten.
Davon profitieren beide fachlichen Seiten. Die Designerinnen erhalten einen groben Einblick in technische Machbarkeiten und können später auch darauf zurückgreifen. Oder man erarbeitet gemeinsam einen alternativen Weg und baut sich etablierte Lösungen für oft wiederkehrende Anforderungen auf. Gleichzeitig ist der Entwickler früh abgeholt und hat die Möglichkeit zu sehen, was eigentlich auf ihn zukommt. Prototypen gewährleisten einen einfacheren Projekteinstieg und stillen zudem das Verlangen, Dinge auszuprobieren.
Das alles funktioniert gut in einem kleinen interdisziplinären Team, in dem die Wege kurz sind und die Abstimmung direkt ist. Allerdings ist das nicht immer gegeben, beispielsweise wenn Layouts direkt von der Design-Abteilung des Kunden oder einer externen Design-Agentur kommen.
Aber auch in solchen Fällen ist es ratsam, das erhaltene Layout zu verstehen, gegebenenfalls zu hinterfragen und Fragen mit den Designern zu klären, bevor man alles blind abarbeitet. Warum ist es wichtig, dass es genau so aussieht bzw. umgesetzt wird? Ist das sinnvoll oder wurde hier eventuell etwas nicht berücksichtigt? Hier geht es nicht darum, die Design-Kollegen zu kritisieren, sondern darum, ein Verständnis füreinander aufzubauen und voneinander zu lernen.
Pair Programming/Designing?
Ich bin jedenfalls froh darüber, in einem Team zu sein, in dem Designer und Entwickler gemeinsam an Projekten arbeiten können. So bietet sich manchmal auch die Gelegenheit, zusammen ein paar Elemente zu entwickeln - Pair Programming im weiteren Sinne.
Dabei sieht die Designerin, warum der Entwickler während der Layout-Phase an bestimmten Punkten kurz gegrübelt hat. Außerdem können direkt Änderungen am eigentlichen Layout ausprobiert werden, und seien es nur Farbwerte, Varianten von Schriftarten/-größen oder ähnliches. Ganz besonders hilfreich ist das z.B. bei beweglichen Elemente wie Tabs, auf-/zuklappbaren Akkordeons, Hinweisboxen bei Hover etc.
Und auch hier gilt wie oben erwähnt, dass die Entwickler "verstehen lernen", was wie von der Designerin angedacht war. Warum gibt es ein Raster? Welche Wirkung hat eine Schrifthierarchie? Gleichzeitig verstehen die Designerinnen die Herausforderungen bei der Umsetzung ihres Layouts und können direkt sinnvolle Alternativlösungen erarbeiten.
Wir haben für uns eine gute Methode und einen guten Rhythmus gefunden, um die entwickelten Zwischenstände zu teilen. Layout-Ergebnisse werden in unserem Intranet oder im Projektmanagement-Tool dokumentiert und sind so für alle Beteiligten einseh- und kommentierbar. Die Zwischenstände der technischen Umsetzung sind jederzeit über einen Test-Server zugänglich oder können in kleinem Kreis auch direkt auf meinem lokalen System angeschaut werden.
Dennoch bleibt es nicht aus, dass sich Anforderungen ändern oder dass sich die Umsetzung im Browser mit realen Inhalten anders verhält oder "anfühlt" als im grafischen Layout angedacht. Daher gibt es eine Qualitätssicherungs-Phase, in der die Designerin alle umgesetzten Elemente noch mal genau prüft und diese z. B. mithilfe von Screenshots inklusive Dokumentation festhält. Mit dieser Methode ist es einfach, Punkt für Punkt abzuarbeiten.
Ganz besonders hilfreich ist für mich die Art der Dokumentation, die ein technisches "Sprech" nutzt. Als Grundlage für die Anpassung von Werten wie Abständen oder Schriftgrößen nutzen unsere Designerinnen Browser-Entwicklertools wie den Firebug. Somit ist sichergestellt, dass die Pixelangaben genau eingehalten werden können. Daran erkennt man, wie technikaffin unsere kreativen Kolleginnen sind!
Auch das ist ein unmittelbares Ergebnis aus dieser Form des Pairings: Entwickler und Designer haben von Haus aus unterschiedliche Sprachen, und das direkte Zusammenarbeiten hilft dabei, sich gegenseitig und das "Sprech" des anderen besser zu verstehen.
Fazit
Der Schritt in die interdisziplinäre Teams ist richtig und fördert das gegenseitige Verständnis. So kompetent jeder in seinem Fachgebiet ist - es hilft ungemein, darüber hinaus seine Schnittstellen zu pflegen und sich weiterzubilden. Dass Entwickler und Designer dabei direkt nebeneinander sitzen, ist wirklich wertvoll.
Es ist für uns sehr hilfreich, wenn wir wissen, wie für unsere Kollegen eine gute Arbeitsgrundlage aussieht. So stellen wir nach vielen Projekten fest, dass einerseits die Entwickler immer mehr auf Design achten (können) und dass andererseits die Designer immer stärker die Machbarkeit im Auge behalten, ohne Qualitätseinbußen hinnehmen zu müssen - im Gegenteil.
Dieser Status quo ist jedoch nicht von heute auf morgen erreicht. Wir bei //SEIBERT/MEDIA sind in dieser Hinsicht schon sehr fortschrittlich, aber diese Form der fachübergreifenden Zusammenarbeit war auch ein längerer Prozess, und er ist auch noch nicht zu Ende! Die größte Herausforderung ist dabei die Frage, wie man als "Einzelkämpfer" im Team den fachlichen Austausch herstellt. Er entsteht nicht von selbst.
Welche Erfahrungen haben Sie mit interdisziplinärer Zusammenarbeit gemacht? Lassen Sie es uns gerne wissen! 🙂
Weiterführende Infos
Der Nutzen von Pair Programming
Coding-Katas: Steigerung der Produktivität und höhere Code-Qualität
Code-Skizzen – Ein ambitioniertes Ziel für UX-Designer
Kollaborativ ein gemeinsames Verständnis von Oberflächen erreichen
Mehr über die Creative-Commons-Lizenz erfahren
