Kurzfassung
Einleitung
Eine der größten Herausforderungen bei der Entwicklung von Produkten ist die Zusammenarbeit mit Menschen aus unterschiedlichen Bereichen. Ob finanzielle Stakeholder, Produktmanager, Designer, Tester oder Entwickler – nur durch einen Austausch gelingt es, ein Produkt als Ganzes zu gestalten.
Jedes Teammitglied hat unterschiedliche Schwerpunkte und Erwartungen. Mangelhafte Kommunikation ist nicht nur frustrierend, sondern kann durch fehlerhafte Features oder Projektverzögerungen finanziell kostenintensiv sein.
Die enge Zusammenarbeit von Designern und Entwicklern hat einen signifikanten Einfluss auf das Endprodukt. Die Zusammenarbeit zwischen beiden Gruppen gestaltet sich oft schwierig, da pragmatische auf kreative Mentalitäten treffen und sich Hintergründe und Arbeitsansätze voneinander unterscheiden.
Eine unzureichende Zusammenarbeit bedeutet für beide Seiten einen hohen Aufwand an Nacharbeit und Korrektur. Die Designer sind enttäuscht von den realisierten Versionen ihrer Entwürfe, und die Programmierer sind enttäuscht von den hohen Ansprüchen der Designer.
Dieser Artikel erklärt, welche Fähigkeiten ein Designer haben muss, um effizient mit Entwicklern zusammenarbeiten zu können. Denn effektive Zusammenarbeit kann Fragen der Benutzerfreundlichkeit und der Technik bereits im Vorfeld beantworten.
Es gibt viele Internetseiten, auf denen du dir Tipps zur Verbesserung deiner Kommunikationsfähigkeiten beschaffen kannst. Diese Hilfestellungen sind jedoch meist sehr allgemein formuliert. Unter anderem werden die folgenden Themen behandelt:
- Festlegen von Erwartungen
- Sicherstellen offener Gespräche
- Ermutigen zu Fragen
- Einfache Erklärungen schaffen
Diese Tipps sind sicher hilfreich, doch ein offenes Miteinander, ein gewisses Einfühlungsvermögen und eine positive Feedback-Kultur sollten Grundvoraussetzungen für jede Kommunikation innerhalb eines Unternehmens sein.
Wie aber können wir spezifisch die Kommunikation von Designern zu Entwicklern fördern?
Grundlagen der Entwicklung lernen
Als Designer sollten wir ein grundlegendes Verständnis für die Programmiersprachen haben, in denen unsere Entwürfe realisiert werden. Das bedeutet in keinem Fall, dass wir Experten in dieser Sprache werden. Wir müssen nicht verstehen, wie Funktionen tatsächlich programmiert werden. Es geht vielmehr um ein Bewusstsein dafür, wie Elemente auf einer Oberfläche ausgerichtet und gestaltet werden und welche visuellen Möglichkeiten zur Verfügung stehen.
Ein Beispiel: Für ein Projekt, das auf einem Web-Framework wie React, Next, Vue oder Angular basiert, solltest du mit HTML und CSS vertraut sein. HTML bestimmt die Struktur der Seite, während CSS die Darstellung definiert. Die Grundlage von HTML lernst du in circa einer Stunde, die Grundlagen von CSS in wenigen Tagen.
Das Interessante daran ist, dass du vermutlich bereits Vorwissen mitbringst, auch wenn du nie eine Zeile Code gesehen hast. Denn heutzutage verfügen die meisten Tools zum Erstellen von User Interfaces wie Adobe XD oder Figma über Methoden, die Code ähnlich sind. So ist das Auto-Layout Feature von Figma dem Flexbox-Container von CSS sehr ähnlich.
In Flexbox-Containern lässt sich festlegen, ob Elemente gestapelt oder verteilt angeordnet werden sollen. Wir können zudem den Abstand zwischen den Elementen, die Richtung, in die sie fließen und ihre Ausrichtung und Position im Container anpassen. Kommen dir diese Einstellungsmöglichkeiten zufällig bekannt vor?
Auto Layout Figma
Auto Layout Code
Zeit und Geld einschätzen
Das Wissen über die Programmiersprachen gibt dir Auskunft über die Komplexität deiner eigenen Designs. Denn als jemand, der kein Fachmann ist, kannst du nicht wissen, wie lange es dauern wird, etwas fertigzustellen. Je mehr Eigenschaften und Möglichkeiten du kennst, desto besser. Vor allem, wenn es um Grenzen geht, die das Frontend setzt, wie Leistungsbeschränkungen bei Animationen.
Dieses Wissen steigert deinen Business-Value maßgeblich. Du fängst an, die Denkweise eines Entwicklers einzunehmen und verstehst die Struktur, die zur Verfügung steht, um Designs zu erstellen. Dadurch existiert nicht nur weniger Klärungsbedarf zwischen den Teams, du kannst Erwartungen und Aufwände an das Projekt abstimmen und verstehen. Du fängst an, dies in deinen Designprozess einzubeziehen, nicht um dich einzuschränken, sondern um die Auswirkungen deines Designs zu verstehen.
Normalerweise geht es den Entwicklern darum, dass die Dinge funktionieren und nicht um die Farbe des Symbols oder darum, ob Elemente pixelgenau umgesetzt sind. Das Problem hier ist nicht die Schuld von irgendjemandem, denn jeder versucht, seine Arbeit zu machen. Es ist völlig normal, dass Designer jeden Pixel verteidigen, und es wäre auch völlig verständlich, wenn der Entwickler nicht bemerkt, dass der Hintergrund nicht weiß, sondern eher hellgrau ist.
Aber wenn du das nächste Mal ein atemberaubendes Design entwirfst, denke daran, wie es sich auf die Entwicklung auswirkt und wie du Programmierer am besten unterstützt, damit es so funktioniert, wie du es dir vorgestellt hast.
Du kannst die Komplexität nicht einschätzen? Beziehe Entwickler in deinen Designprozess mit ein und frag sie in regelmäßigen Abständen nach dem Umfang deiner aktuellen Lösung.
Designs businesstechnisch einschätzen und priorisieren
Auf Frameworks vertrauen
Häufig arbeiten wir bei großen Projekten mit einem Design System, bestehend aus wiederverwendbaren Variablen wie Schriftgrößen und Farben sowie Komponenten wie Schaltflächen und Eingabefelder.
Sei dir bei jedem Projekt bewusst, dass ein Design System nicht nur initial eine massive Ressourcenbelastung darstellt, sondern ebenfalls in regelmäßigen Abständen gepflegt werden muss. Wir müssen lernen abzuwägen, wann es Sinn ergibt, auf bestehende Design-Systeme zurückzugreifen und wann sich eigen erstellte Komponenten rentieren.
Dazu kommt, dass das Entwickeln von Komponenten viel Zeit in Anspruch nehmen kann. Bei sieben- oder achtstelligen Projekten ist eine solche Freiheit eher gegeben. Doch für kleinere Budgets solltest du dich hinterfragen, ob es ein selbst designter Time-Picker sein muss oder wir nicht doch auf die native Browser-Implementierung zurückgreifen.
Frage bestenfalls direkt deine Entwickler, ob sie bereits Erfahrungen mit Frontend Frameworks gemacht haben. Viele Frontend-Programmierer haben im Laufe ihrer Karriere mit System wie Material Design, Tailwind oder Bootstrap gearbeitet. Sie alle bieten vorgefertigte Komponenten, die nur noch farblich und typografisch angepasst werden müssen, um sie an das Branding und die Bedürfnisse der Zielgruppe auszurichten.
https://www.rgbwebtech.com/blogs/page/front end frameworks for responsive web design
Interaktionen bedenken
Ich habe häufig mitbekommen, dass Designer statische Elemente an Entwickler geben. Doch die wenigsten Elemente in einem Interface sind statisch. Wenn du dein nächstes Eingabefeld designst, denk an die verschiedenen Zustände, die es haben kann:
Wie sieht das Eingabefeld aus, wenn der Mauszeiger es anvisiert? Was passiert, wenn der Fokus über die Tastatur ausgelegt wird? Gibt es eine deaktivierte Version und wenn ja, wie wird diese erkennbar gemacht? Was passiert, wenn ein Fehler auftritt? Werden Eingaben visuell validiert? Was passiert, wenn die Zeichen der Nutzereingabe mehr Platz in Anspruch nehmen, als das Eingabefeld zur Verfügung hat?
Orientiere dich dabei an den typischen Vorgehensweisen der Industrie. Diese Interaktionen können die Benutzererfahrung prägen und sollten nicht der Intuition überlassen werden. Baue in der gesamten Software konsistente Richtlinien für Interaktionen auf und stelle diese Richtlinien den Entwicklern in simpler Form zur Verfügung, bestenfalls mit Grafiken und Erklärungen.
Interaktionen bei Designs
Eigenschaften (Props) beschreiben
Fast noch wichtiger als Interaktionen sind die verschiedenen Eigenschaften, die eine Komponente haben kann. Ein Eingabefeld ist nie nur ein Eingabefeld. Es kann eine Beschriftung haben, eventuell einen begleitenden Text oder einen Platzhalter. Eingabefelder können in verschiedenen Formen und Größen existieren oder Icons einschließen, je nach Situation und Priorität.
Eine lustige Analogie für das Denken in Eigenschaften ist es, sich eine bestimmte Frucht vorzustellen, etwa eine Melone. Erzählst du deinem Arbeitskollegen, dass du neulich im Supermarkt eine Melone gekauft hast, wisst ihr zwar ungefähr, wovon der andere spricht, aber es bleibt noch viel Raum für Fantasie, zum Beispiel:
- Um welche Art von Melone handelt es sich?
- Ist die Melone bereits in Scheiben geschnitten?
- Wie groß ist die Melone?
Bezogen auf die beispielhaften Fragen hat unsere Komponenten ‚melone‘ folgende Eigenschaften:
- typ: Wasser,Honig,Galia,Canaloupe, ..
- geschnitten? Ja oder Nein
- groeße: Durchmesser
Jede dieser Eigenschaften wirkt sich auf das Aussehen und die Benutzbarkeit aus. Händige Entwicklern nicht nur ein einziges Button-Design aus und erwarte, dass sie sich Eigenschaften selbst denken. Liefere alle Eigenschaften gleich mit. Welche Optionen haben die Eigenschaften und welche Auswirkungen ergeben sich?
Eigenschaften von Komponenten
Diese Kommunikation ist nicht einseitig zu verstehen. Du wirst auch häufig mit Entwicklern sprechen, die verschiedene Eigenschaften umsetzen müssen. Hier liegt es an dir, die visuellen Differenzen zu dokumentieren und ihnen bereitzustellen.
Weitergedacht, lässt sich dasselbe Prinzip auf Texte und auf Aspekte der Barrierefreiheit anwenden.
Content und Accessibility Guidelines
Elemente im System betrachten
Komponenten haben nicht nur verschiedene Zustände für sich. Sie leben in einem komplexen Ökosystem, bestehend aus weiteren Elementen. Bei Schaltflächen können wir uns zum Beispiel Folgendes fragen:
- Wie genau wird sie auf der Seite positioniert?
- Ist die Position unabhängig von anderen Elementen?
- Wie wird die Schaltfläche ausgerichtet?
- Existieren Situationen mit mehreren Schaltflächen auf einer Seite?
- Falls ja, wie werden diese Schaltflächen zueinander angeordnet?
- Wie wird eine Schaltfläche mit langem Text skaliert?
Verschiedene Button Positionierungen
Du solltest keinen Gedanken unausgesprochen lassen. Leite alle nötigen Informationen an dein Entwicklungsteam weiter. Bedenke dabei, dass weniger Wörter meist mehr sind. Niemand liest sich gern ein seitenlanges Word-Dokument mit allen Eigenschaften zu Schaltflächen durch. Häufig reichen einige wenige Stichpunkte und dazu passende Illustrationen.
Best Practices für Komponenten, Beispiel
Entwicklungsbasiertes Design-Deployment
Ich sehe immer noch Designer, die PDFs an Entwickler weitergeben. Es ist nicht verkehrt, Entwicklern einen groben Entwurf, ein Mockup oder erste Versionen von Entwürfen in einem Printformat vorzulegen. Doch das Endergebnis sollte immer auf Pixeln basieren, in einer Software, die einzelne Elemente aus deinen Designs anvisieren lässt.
Design-zu-Code-Anwendungen sind in der Regel für Entwickler kaum bis gar nicht zu gebrauchen. Es geht in diesem Punkt vielmehr um Software, die Informationen darüber liefert, was auf dem Bildschirm zu sehen ist. Adobe XD oder Figma bieten diese Option. Die Software muss es den Entwicklern so einfach wie möglich machen, Entwürfe schnell nachzuschlagen und visuelle Eigenschaften eines Elements per Mausklick zu erfahren.
Figma Code Inspect
Zudem sammeln sich im Laufe eines Projektes verschiedenste Dateien und Informationen über das Produkt, von Anforderungsdokumenten hin zu Design Systeme, Styleguides, Logos, Icons, Bildarchive etc.
Versuche, dir von Anfang an ein Konzept zu überlegen, wo und wie du Dateien speicherst. Nicht alle Informationen können in einem Kollaborationstool wie Figma gespeichert werden. Auch in Figma selbst lassen sich zusammengehörige Elemente strukturiert gruppieren, über Seiten, Frames oder Flows. Insbesondere so bald Revisionen ins Spiel kommen und du eventuell mehrere Versionen eines Interface gleichzeitig in einer Datei hast, spielen Anmerkungen, Titel und Beschreibungen eine noch größere Rolle.
Gib deinem Team zudem Zugang zu allen Dateien, die du während deines Designprozesses verwendet hast. Sortiere, gruppiere und benenne Dateien anschaulich, bestenfalls in einem ähnlichen Stil, wie sie im Entwicklungsprojekt gespeichert werden. Auf diese Weise stellst du sicher, dass Entwickler jederzeit und auch ohne Hilfe auf die benötigten Dateien zurückgreifen können.
Design Dateien Ordnerstruktur
Design selbstständig vorstellen
Menschen haben unterschiedliche Kommunikationsstile, geprägt von ihrem Hintergrund, ihrer Persönlichkeit und ihrem Umfeld. Das führt dazu, dass, wenn wir die Ideen eines anderen darstellen, wir nicht dieselbe Erklärungstiefe oder denselben Enthusiasmus mitbringen.
Als Designer ist es deine Verantwortung, visuelle Entwürfe zu präsentieren. Es sollte unter keinen Umständen dazu kommen, dass jemand aus einer anderen Disziplin deine Designs vorstellt. So wie Produktmanager den Cycle ihres Produkts perfekt vorstellen oder Entwickler die Funktionsweise ihres Codes nahelegen können, so solltest du als primärer und bester Ansprechpartner für alle designorientierten Fragen dienen.
Dadurch stellst du dich nur klare Gesprächsprinzipien und -kanäle auf, sondern stellst optimale Kommunikation zwischen den Disziplinen her. Es muss deine Verantwortung sein, Designs so zu transportieren, dass die Zielgruppe sie versteht.
Fazit
Für Designer und Entwickler kann es eine Herausforderung sein, effektiv miteinander zu kommunizieren, obwohl eine effektive Zusammenarbeit zwischen Designern und Entwicklern den Erfolg von funktionsübergreifenden Teams erheblich steigert. Ich freue mich, eine Kultur der Zusammenarbeit geschaffen zu haben, in der Designer und Entwickler ermutigt werden, offen zu kommunizieren und ihre Beiträge zu schätzen. Ich hoffe, dass diese Tipps dir dabei helfen werden, dasselbe zu tun.
Zusammenfassung
- Das harmonische Zusammenspiel von Designer und Entwickler ist im Entwicklungsprozess eines Produkts eine große Herausforderung, aber auch ein Erfolgsfaktor.
- Um effektiv mit Entwicklern zusammenarbeiten zu können, sollten Designer ein grundlegendes Verständnis für Programmiersprachen haben und wissen, wie sie ihre Designs am besten bereitstellen.
- Treffen Designer Entscheidungen über das Design eines Produkts, sollten sie die Auswirkungen auf die Entwicklung berücksichtigen und die Grenzen des Frontends beachten.
- Eigenständige Präsentationen von Designs durch die verantwortlichen Designer stärken die Kommunikation und den Wissenstransfer im gesamten Team.
- Ein Geheimtipp für eine erfolgreichere Zusammenarbeit ist das Nutzen von vorgefertigten Frameworks und Design Systemen, welche den Entwicklungsprozess enorm erleichtern können.