Trotz meiner relativ jungen Karriere als Full-Stack Designer, konnte ich doch schon viele Eindrücke in die Zusammenarbeit zwischen Entwicklern und Designer unterschiedlichster Teams sammeln. So viel sei vorweggenommen: die Workflows haben sich über die letzten Jahre massiv geändert. Zum Besseren.

Ich erinnere mich noch an die Zeiten, in denen wir Designer lediglich fertige Mockups als JPEGs an die Developer geschickt haben. Wenn sie Glück hatten, bekamen sie einen USB Stick mit den offenen Photoshop/Illustrator Dateien. Mit denen konnten sie leider nur selten etwas anfangen, zumal diese mehrere hunderte MB groß waren und noch dazu in einem proprietären Dateiformat mit dem kein Entwickler etwas anfangen kann.

Das Endergebnis war meistens für beide Seiten ernüchternd. Die Entwickler, welche sich jegliche Abstände, Anordnungen und Interaktionen praktisch aus den Fingern saugen mussten, verstanden nicht warum die Designer so kleinlich und übergenau sind. Den Designern wiederum war es unverständlich wie man nur so wenig Wert auf Ästhetik legen kann und warum das Endprodukt total anders als die Mockups aussieht.

[Designer und Developer] sind von Natur aus Feinde! Wie Engländer und Schotten. Oder Waliser und Schotten. Oder Japaner und Schotten. Oder Schotten und andere Schotten. Verdammte Schotten, die haben Schottland ruiniert! - Hausmeister Willie, in etwa

Der technologische Fortschritt löste in den letzten Jahren viele Probleme in der Zusammenarbeit zwischen den beiden. Jedoch können wir nicht alle Probleme durch neue Tools lösen, manchmal braucht es einen neuen Blick auf die Dinge. Einen neuen Weg, den es zu gehen gibt.

1. Gutes Design ist nie fertig

In Zeiten in denen das Wasserfallmodell zunehmend von agileren Methoden verdrängt wird, kann man diesen Satz nicht oft genug wiederholen. Der Gedanke, dass das Design fertig ist sobald alle Screens entworfen und alle Mockups erstellt sind, entspricht schon lange nicht mehr der Realität.

Meist geht die Arbeit erst richtig los, wenn die Entwickler anfangen Fragen zu stellen und neue Anwendungen auftauchen, wo zuvor keine waren. Tatsächlich ist es nur sehr schwierig einen Projektumfang exakt zu definieren bevor es einen visuellen Prototypen dazu gibt. Das ist ein Grund dafür, warum Teams die bereits früh und oft visuelle Prototypen erstellen und Feedback dazu einholen, bessere Ergebnisse und Produkte abliefern.

Wenn die Designs für ein Produkt fertig sind, haben wir die Hälfte des Designs geschafft.

2. Veränderung ist die einzige Konstante

Designer müssen flexibel sein. Wie die Workflows von Projekt zu Projekt unterschiedlich sein können, so entwickeln sich auch Projekte weiter und Entscheidungen müssen in späteren Projektphasen stets schneller und schneller getroffen werden. Aber nicht nur die Zeit spielt eine Rolle, viel wichtiger noch ist das Team im Hintergrund.

Jeder Entwickler hat seine eigenen Routinen und Präferenzen. Manche bevorzugen es, wenn der Designer am Tisch nebenan sitzt, und sie jederzeit die zwei Meter gehen können um über Ideen und Vorschläge zu diskutieren. Ein anderer Entwickler im selben Team bevorzugt es, seine Kopfhörer stets oben zu lassen um im Flow zu bleiben und Fragen über Slack zu klären.

Genau wie die Kommunikation verändert sich auch die Dokumentation des Designs mit jedem neuen Projekt und jedem neuen Teammitglied. Das Einzige das konstant bleibt, ist die Veränderung.

3. Passion, Passion, Passion

In der Konzipierungsphase sowie bei frühen strategischen Entscheidungen sind oftmals nur wenige Entwickler wirklich beteiligt. Das führt dazu, dass sie zwar eine grobe Idee vom Business-Kontext des Projekts haben, aber oftmals nicht im Detail wissen können, wie das Feature, welches sie gerade entwickeln, den Usern im Endeffekt das Leben vereinfacht.

Als Designer beschäftigen wir uns in erster Linie mit den letztendlichen Nutzern des Produkts, und in dieser Rolle sind wir im Team meistens alleine. Daher gilt es diese externe Stimme auch in das Projektteam zu bringen und Anekdoten des letzten Gesprächs mit den Stakeholdern einzubringen und persönliche Geschichten von den Nutzern zu teilen, die wir mit der Software unterstützen.

So können wir den Entwicklern helfen, ein Gespür für die Auswirkungen unserer Entscheidungen zu entwickeln und sie direkt mit den Ergebnissen ihrer harten Arbeit in Kontakt bringen.

Es geht nicht mehr nur darum wie ein Feature funktionieren soll, sondern wie wir damit das Leben von Menschen erleichtern.

Trainer am Spielfeldrand

Auch wenn nur einige wenige Personen Wireframes, Mockups und Prototypen erstellen, hängt gutes Design jedoch vom ganzen Team ab. Genau wie ein guter Trainerstab essenziell für jedes erstklassige Team ist, liegt es schlussendlich an den Spielern die Tore zu schießen. So geht es für Designer vielmehr darum, stets das ganze Team mit ins Boot zu holen und die Richtung vorzugeben anstatt eine möglichst ästhetische Lösung zu finden.

Gutes Design entsteht nicht im Kopf eines einzelnen talentierten Designers. Es entsteht vor allem in einem Team, welches sich das letztendliche Nutzererlebnis zur Priorität #1 gemacht hat. In einem Team, dass auf Flexibilität und Passion aufgebaut ist und eine gute Kollaborations- und Feedbackkultur lebt.