colspan=17: Über den Entwickler-Trugschluss enger Zusammenarbeit mit Designern
Entwickler sollten eng mit Designern zusammenarbeiten – oder Designern mehr Freiraum geben und sich damit noch mehr herausfordern?
- Jens Oliver Meiert
Es ist eine beliebte Überlegung: Als Entwickler sollten wir eng mit unseren Designern zusammenarbeiten. Es ist eine alte Idee: Wir wollten das in den 90ern genauso wie vor zehn Jahren und ebenso auch heute. Und es ist eine gute Idee: Zusammenarbeit mit Designern ist sinnvoll und nützlich. Was ist aber damit, Designern mehr Freiraum zu geben und sich noch mehr herauszufordern?
Die Vorteile der Zusammenarbeit sind deutlich, wie andere bereits festhalten:
Zum einen verbessern wir, wenn wir enger mit Designern zusammenarbeiten, das Verständnis und die Beziehungen zwischen den beiden Disziplinen. Keine Fragen, wozu der Mock da ist oder welche Anwendungsfälle jene Grafik hat.
Zum anderen, daraus folgend, arbeiten wir effizienter zusammen. Kein Nachbearbeiten von Assets, die Designer im unpassenden Format oder unkomprimiert geteilt haben, und keine extra Schleifen, sobald wir die letzte Sketch-Datei in die Hand bekommen.
Aber es gibt auch Gründe gegen die enge Zusammenarbeit mit Designern. Der größte Grund ist, Designer nicht einzuschränken, also unabsichtlich Kreativität zu begrenzen oder abzutöten. (Stichwort: Design-Potentialität.) "Nein, hier und dort machen wir es so." "Wir haben dieses Element schon in Bootstrap, also sollten wir das Rad nicht neu erfinden." Oder der Sargnagel: "Das geht nicht."
Wir mögen uns dabei wie rationale, gut meinende Champions der Nutzer und unserer Unternehmung vorkommen, aber es gibt einen schmalen Grat, zu bequemen, vielleicht sogar bevormundenden Entwicklergouvernanten zu werden.
Ein weiterer Grund ist, uns selbst herauszufordern, Designkreativität in Entwicklungsexzellenz zu überführen. Das ist nicht möglich, wenn wir unsere Designer dazu bringen, langweilige und leblose Design Patterns zu benutzen (oder?), weil das konsistenter, leichter zu entwickeln und vielleicht sogar schneller ist. Das sind gute Gründe. Aber wie der schmale Grat andeutet, kann das auch nach hinten losgehen, da Konsistenz nicht alles ist, es noch etwas leichter zu Entwickelndes geben mag – etwas, das wiederum schneller sein kann – und den Designern vielmehr alle Freiheiten über ihre Domäne gelassen werden könnten.
Entscheidend ist der folgende Punkt: Wenn wir als Entwickler votieren, bitten, insistieren, dass wir eng mit Designern zusammenarbeiten, dann ist die Angelegenheit längst nicht so klar wie sie an der Oberfläche anmutet.
Was bedeutet dies für die Praxis?
Was dies bedeutet ist zum einen, dass wir in erster Linie an den Rändern unserer Felder aufpassen müssen. Wenn wir ein Team von Weltklasse-Designern haben, wollen wir die Entwickler auf keinen Fall die Designagenda bestimmen lassen. Wenn wir das tun, verschwenden wir nur das Potential unserer Designer (und vielleicht unsere Designer). Am anderen Ende des Spektrums aber, wenn wir mit einem Team von Junior-Designern arbeiten, können Entwickler, vor allem erfahrene, diese sicherlich beraten.
Zum anderen, wie der letzte Punkt schon anzeigt, kommt es darauf an. (Es mag ein Charakteristikum unserer Welt sein, dass vieles "darauf ankommt".) Es kann Sinn ergeben, unsere Designer nah heranzuziehen. Es kann Sinn ergeben, ihnen alle Freiheiten zu lassen. Nur sollten wir einen genauen Blick auf die Situation werfen, nachdenken und entscheiden – denn es scheint ein Trugschluss zu sein, dass enge Zusammenarbeit mit Designern verpflichtend ist. ()
