![](https://www.wearecube.ch/ueber_uns/phippu/phippu-avatar_hu96bb11121bb14f432fbbec5da1781cbe_13058_48x48_fill_q90_h2_lanczos_center_3.webp)
Die vergessenen Stakeholder
Die Ansichten verschiedener Stakeholder in die Gestaltung einer Applikation einfliessen zu lassen, ist eine der wichtigsten Aufgaben der Designer:innen. Eine Gruppe geht dabei aber oft vergessen: die Entwickler:innen.
In den letzten zwei Jahren hatte ich in meinen Projekten die Gelegenheit, so eng mit Entwickler:innen zusammenzuarbeiten, wie nie zuvor in meiner Karriere. Dabei habe ich festgestellt, dass wir Designer die Entwickler:innen sehr oft vergessen, wenn es um die Bedürfnisse der verschiedenen Stakeholder geht.
Traditionell sind Design und Entwicklung verschiedene Rollen, die von verschiedenen Personen ausgeübt werden. Und in vielen Teams gibt es auch eine gewisse Rivalität zwischen diesen Rollen. Aber letztlich sind es die Entwickler:innen, die erschaffen, was wir gestaltet haben. Sie sind also eine sehr wichtige Zielgruppe. Vielleicht sogar wichtiger, als die effektiven Nutzer:innen.
Viele Designer:innen machen die Erfahrung, dass ihre Designs von den Entwickler:innen anders umgesetzt werden, als sie spezifiziert worden sind. Dafür sehe ich vor allem drei Gründe.
Designer:innen wissen oft zu wenig über Frontend Entwicklung.
Insbesondere kennen sie die Prinzipien und Komponenten der Frameworks und Design Systeme, die im konkreten Vorhaben verwendet werden, zu wenig gut, z.B. Angular, Material Design oder Bootstrap. Das führt dazu, dass die Entwürfe nicht so umgesetzt werden können (oder sollten), wie sie ursprünglich gezeichnet wurden.
In den traditionellen Design-Disziplinen, d.h. im Produkt- und Industriedesign, ist es hingegen sonnenklar, dass man als Designer:in über Materialien und Herstellungsprozesse Bescheid wissen muss.
Entwickler:innen wissen oft zu wenig über Frontend Entwicklung.
Sie kommen zum Teil aus der Backend Entwicklung und haben sich nur wenig mit modernen Web-Technologien befasst, d.h. sie haben zu wenig Know-How und Erfahrung. Dazu kommt, dass die Entwicklung in diesen Gebieten unglaublich rasch voranschreitet und ein Framework, das gestern noch hochgejubelt wurde, heute schon überholt ist. Gute Frontend-Entwickler:innen sind deshalb sehr schwer zu finden.
Wenn diese beiden Fälle gemeinsam auftreten, werden Features weder sauber gestaltet noch richtig implementiert. Meistens sind dann mehrere Überarbeitungen erforderlich, bis etwas gut genug ist, um effektiv ausgeliefert zu werden. Das macht den Prozess teuer und frustrierend.
Designer:innen und Entwickler:innen sprechen zu wenig miteinander.
Dies geschieht oft, wenn Design und Entwicklung zeitlich und örtlich getrennt sind. Zeitlich, wenn das Design vor der Entwicklung geschah und über Spezifikationen an die Entwicklung durchgereicht wurde. Örtlich, wenn Designer:innen und Entwickler:innen an verschiedenen Orten oder gar für verschiedene Firmen arbeiten.
Die Erfahrung zeigt, dass Konzepte, Spezifikationen und Gestaltungsentwürfe nie vollständig sind und es immer Dinge gibt, die während der Entwicklung angepasst werden müssen. Idealerweise können Designer:innen und die Entwickler:innen die notwendigen Änderungen gemeinsam diskutieren und eine gute Lösung finden. Andernfalls müssen die Entwickler:innen nach eigenem Gutdünken handeln.
Was können wir (Designer:innen) tun, um dies zu verbessern?
Die Hausaufgaben machen!
Ich habe damit angefangen, regelmässig die Dokumentation der Design Systeme und Frameworks zu konsultieren, die von den Entwickler:innen verwendet werden. Dadurch verstehe ich besser, auf welchen Bausteinen und Komponenten ich meine Entwürfe aufbauen kann.
Standard-Komponenten verwenden.
Wenn ich einen Design-Entwurf mache, verwende ich wenn immer möglich die Standard-Komponenten des verwendeten Frameworks und dokumentiere in meinen Entwüfen, welche Komponente ich verwendet habe. Grössere Anpassungen oder Speziallösungen müssen einen echten Mehrwert bringen, um den zusätzlichen Aufwand zu rechtfertigen.
Beziehungen aufbauen.
Gute Zusammenarbeit setzt eine gute Beziehung voraus, die aber zuerst einmal aufgebaut werden muss. Ich gehe deshalb aktiv auf die Entwickler:innen zu und lasse mir zeigen, wie sie meine Entwürfe umgesetzt haben. Die Fragen und Diskussionen folgen dann von alleine. Und bei der nächsten Story kommen die Entwickler:innen dann meist schon von selber auf mich zu. Und zwar noch bevor sie ihren Code gemergt haben.
Mein Fazit: Als Designer:innen sind wir uns gewohnt, die Bedürfnisse von Nutzergruppen zu erforschen. Diese Research Skills können wir auch nutzen, um die Bedürfnisse der Entwickler:innen besser zu verstehen und in unsere Arbeit einfliessen zu lassen.