Zusammenarbeit zwischen Designern und Entwicklern - ein langer Weg

Im Jahr 2017 war die Situation zwischen Designern und Entwicklern etwa so:

Die Designer saßen unter sich in einer Ecke des Büros, entwickelten ihre final_final.PSD und gaben diese letztlich kommentarlos an die Entwickler weiter, die wiederum in einem anderen Raum oder sogar in einem anderen Gebäude saßen. Die Aufgabe des Designers war dann erledigt und er widmete sich dem nächsten Projekt. Bevor die eigentliche Arbeit der Entwickler begann, mussten sie aus dem, was sie vom Designer erhielten schlau werden. Wenn Wochen oder Monate später das endgültige Projekt stand, hatte es häufig wenig mit der ursprünglichen Vorlage zu tun: anderes Layout, andere Farben und neue frei gestaltete Komponenten, die der Designer nie gesehen hatte.

Seitdem haben wir einen langen Weg zurückgelegt. Heute arbeiten wir super effizient zusammen und teilen eine gemeinsame Sprache. Wir haben gegenseitigen Respekt vor unserer Arbeit, bei dem ein tiefes gegenseitiges Verständnis herrscht.Unsere verschiedenen Denkweisen ergänzen sich und führen zu gut gestalteten, schnellen und skalierbaren Produkten. Katja (Hocke) und Markus (Siering) beschreiben in diesem Artikel, was alles dafür getan werden musste, um das zu erreichen.

1. Zusammensetzung des Teams

In seinem Kern ist sum.cumo ein Technologieunternehmen. Die meisten der bei sum.cumo beschäftigten Personen haben einen Titel mit dem Wort "Entwickler" auf ihrer Visitenkarte stehen. Als das Unternehmen und auch die Komplexität der Projekte größer wurden, erschien bei sum.cumo auch eine neue Spezies - die UX-Designer. Sie brachten die nutzerzentrierte Sichtweise und viel Wissen über Methodik, Nutzertests und Recherche auf den Tisch. In der Zeit vor den UX-Designern erledigten unsere visuellen Designer den UX-Job mehr oder weniger erfolgreich, oft mehr aus einem Bauchgefühl heraus statt auf Grundlage fundierter Daten, Recherche und Erfahrung. Oder schlimmer noch, Benutzerfreundlichkeit war überhaupt kein Thema. Das alleinige Interesse der Beteiligten bestand darin, neue Features schnellstmöglich umzusetzen.

So konnte es nicht weitergehen. Wir bildeten funktionsübergreifende Projektteams, sodass die UX-Designer direkt in das Herz des Produktentwicklungsprozesses integriert wurden. Ziel ist es, unsere Teams so zu besetzen, dass es neben den anderen Berufen und Rollen mindestens ein Teammitglied gibt, das ein engagierter UX-Designer ist. Das perfekte Dreieck, das den Output "Ich würde das Produkt meinen Freunden empfehlen" liefert, besteht aus der sehr engen Zusammenarbeit zwischen UX-Design, Visuellem Design und Frontend-Entwicklung. Außerdem haben wir die Distanz zwischen den einzelnen Parteien im wahrsten Sinne des Wortes verringert, indem alle Beteiligten in einem Team sitzen. Sie müssen herumkritzeln und reden und ihre Köpfe zusammenstecken und sich nach getaner Arbeit auf der Dachterrasse auf ein Bier treffen.

2. Design-Tools

Zuallererst haben wir uns endlich von den altmodischen Tools und Gepflogenheiten beim UI-Design befreit. Photoshop dient der Bearbeitung und Zusammenstellung von Bildern (Editing & Composing). Aber es passt nicht so recht in den Prozess der Entwicklung digitaler Produkte.

Dies sind spannende Zeiten für digitale Designer, da es eine riesige Vielfalt an hervorragenden und preisgünstigen Tools gibt. Tools, die den Bedürfnissen für die Erstellung responsiver und modularer Designs entsprechen. Tools, die die gleiche Logik und Struktur unterstützen, die auch ein Frontend-Entwickler beim Erstellen einer Schnittstelle einsetzen würde. Dies ist den Designern dabei behilflich, überflüssige Komplexität in den Layouts zu reduzieren und von Anfang an über verschiedene Stufen des Designs nachzudenken.

Was den Unterschied zwischen einem guten und einem hervorragenden Designer ausmacht, ist, dass sie nicht nur ein brillantes Design innerhalb des Layout-Programms liefern, sondern auch sicherstellen, dass die Idee in Bezug auf die Ausführung des Frontends absolut zuverlässig ist.

Unsere aktuell eingesetztes Design-Toolsets:

Sketch:

• Für die Erkundung von Richtungen des UI-Designs
• Für Designsysteme und Bibliotheken

Photoshop:

• Für Bilder
• Und manchmal für Mockups

Illustrator:

• Für komplexe Vektorgrafiken (einfache Icons werden größtenteils direkt in Sketch erstellt)

Marvel:

• Für Nutzerflows und Designprototypen mit einfachen Interaktionen und Übergängen
• Zum Sammeln von Feedback intern und extern (z.B. mit dem Kunden oder potenziellen Nutzern)
• Für Developer-Handoff

Principle:

• Für Mikro-Interaktionen und -Animationen

Framer:

• Für sehr funktionelle High-Fidelity-Prototypen

3. Verbundener Workflow

Unsere Designer sind in einem agilen Umfeld tätig. Stets versuchen wir, mindestens einen UX-Designer und einen UI-Designer pro Team zu haben. Designer wurden in der Vergangenheit oftmals als eine Art Engpass wahrgenommen, die die Produktentwicklung verlangsamten. Normalerweise stellen Designer vor der Erstellung des Outputs eine Menge Fragen. Sie nehmen sich die Zeit, um den Kunden, das Problem und die Nutzer zu verstehen. Es bestehen ständige Reibungspunkte zwischen der geschäftlichen (z.B. wettbewerbsfähiger Leistungsumfang und Zeit bis zur Markteinführung) und der Nutzerperspektive (umfassendes Verständnis des Problems und die beste Lösung dafür).

Parallele Workstreams

Um Zeit einzusparen und den Designern trotzdem genügend Zeit zum Entdecken und Erkunden zu geben, haben wir parallele Workstreams gestartet.

Während die UX-Designer Recherchen betreiben, Personas erstellen, Anforderungen abstimmen und die Ergebnisse in Wireframes darstellen, entwickeln die Visual Designer das Markendesign und die visuelle Sprache innerhalb des Produkts.

Sobald die Designer erste Grobentwürfe der UX und/oder UI haben, beginnen unsere Entwickler mit dem Aufbau der Struktur. Zwischenzeitlich arbeiten die Designer an den Details des Designs.

Hauptkomponentenbibliothek

Wir verwenden Bootstrap als Framework für eine Vielzahl unserer Projekte. So entstand bei uns die Idee einer Bootstrap-basierten Hauptkomponentenbibliothek für Sketch. Die Sketch-Datei beinhaltet ein System gut strukturierter, geschachtelter Symbole mit responsivem Verhalten und Overrides sowie Dokumentation. An der Seite des Designers sitzt der Entwickler, der eine Bootstrap-basierte Komponentenbibliothek (sogar mit der gleichen Namensgebung) innerhalb vom Storybook hat.

Das sind die Vorteile:

• Reduzierung des sich wiederholenden Aufwands (Designer müssen nicht jedes Mal aufs Neue ein Designsystem entwickeln)
• Reduziertes Risiko einer unvollständigen Entwicklerübergabe (z.B. fehlende Stufen einer Komponente)
• Weniger Ärger bei der Umsetzung des Designs im Code (Design nahe an der technischen Grundlage).
• Mehr Tempo in der Anfangsphase des Komponentendesigns
• Gemeinsame Sprache von Designern und Entwicklern

Das sind die Nachteile:

• Designer müssen sich erst an den neuen Workflow gewöhnen: die Bearbeitung, Anpassung und Ergänzung eines bestehenden Systems erfordert eine andere Denkweise als das Starten mit einer leeren Zeichenfläche
• Designer fühlen sich möglicherweise in ihrer Kreativität eingeschränkt, weil viele Schnittstellengrundlagen bereits definiert sind

Designphasen

Wir haben immer noch diese vollkommen freie Erkundungsphase, in der Visual Designer nicht einmal an Bibliotheken denken. In dieser allerersten Projektphase, in der ein neues Design erstellt wird, produzieren unsere Designer unvollkommene Skizzendateien ohne jegliches System. Und das ist in Ordnung. Wir wollen viel Spielraum für Kreativität und die Erkundung verschiedener Richtungen ermöglichen. Als nächstes drucken wir. Ja, auch digitale Designer bedienen sich eines Druckers. Es ist hilfreich, alle groben Designs an der Wand zu haben, um sie zu beurteilen und in der Gruppe zu debattieren.

Nachdem sich die freien Experimente zu einer Designsprache verdichtet haben und sich alle darauf geeinigt haben, nehmen wir unsere grundlegenden Designregeln zur Hand und legen sie in eine Kopie der Masterbibliothek. In der Regel beginnen wir mit der Anpassung und Aktualisierung der Grundlagen: Farben, Typografie, Logos, Schaltflächen. Anschließend fahren wir mit komplexeren Elementen wie Eingaben, Dropdowns, Checkboxen usw. fort.

Auch wenn sich diese Elemente später im Prozessverlauf noch ändern können, exportieren wir mit Marvel ein Entwickler-Handoff. Dies ist der Startpunkt für unsere Frontend-Entwickler, die mit der Umsetzung des eigentlichen Designs in ihrem Storybook beginnen. Mit der Zeit wächst das System und der Marvel-Link wird mit weiteren Komponenten aktualisiert.

Wir versuchen, frühe Design-Prototypen so oft wie möglich zu testen, lernen aus dem Feedback und lassen es in unser Produkt-Backlog einfließen.

4. Vom Entwurf zum Frontend

Nach der Klärung des Designprozesses möchten wir einen Blick auf den Frontend-Teil der Entwicklung werfen. Wir beginnen, je nach Anforderungen des jeweiligen Projekts, mit der Anlaufphase, während sich das Design in der Erkundungsphase befindet. Dies umfasst das grundlegende Einrichten des Projekts mit viel technischem Hintergrundmaterial, das mittlerweile für jedes Frontend-Projekt als selbstverständlich vorausgesetzt wird. Meistens verwenden wir unser Best-Practice-Boilerplate VuEcoSystem, das unser Wissen aus früheren Projekten beinhaltet. Bei den UI-Komponenten verwenden wir überwiegend die Bootstrap-basierten Daten, die wir mit unseren Designern aufgebaut haben.

Sobald die anfängliche Konfiguration abgeschlossen ist, können wir mit der Umsetzung dessen starten, was bereits als Design erstellt wurde. In dieser Projektphase arbeiten wir überwiegend mit dem Storybook, um sicherzustellen, dass unsere Komponenten auch isoliert gut funktionieren. Dies gewährleistet die Wiederverwendbarkeit über die gesamte Schnittstelle während des Projektverlaufs. In diesem Schritt vollziehen wir das Handoff von Marvel bis zum Code.

Unsere Todos sind davon abhängig, was das Design möchte - manchmal können wir die bereits vorhandenen Basiskomponenten übernehmen und ihnen ein spezielles Styling verleihen - wie beim Design starten wir auch hier mit der Anpassung von Farben, Typografie, Logos und Schaltflächen. Bei jedem Projekt gibt es Elemente, die nicht in die "üblichen" von uns benötigten Schnittstellenkomponenten passen. Es handelt sich hierbei um speziell angefertigte Komponenten, deren Erstellung, Umsetzung und Anpassung gemäß unserem Design etwas mehr Aufwand erfordert.

Dieser gesamte Prozess findet bei keinem Projekt ein wirkliches Ende - die Menge der neu erstellten Komponenten verlangsamt sich einfach im Laufe der Zeit.

Zunächst führt die Entwicklung der Komponenten in Storybook zu zwei interessanten Aspekten.

Einerseits stellen wir sicher, dass alle unsere Komponenten eigenständig und ohne jeden "äußeren" Einfluss funktionieren. Dies verringert das Risiko, dass durch unbeabsichtigte Effekte, Bugs entstehen (technische Nebenbemerkung: z.B. eine CSS-Klasse, die eine Komponente betrifft, aber von einer anderen Komponente stammt). Die später implementierte Schnittstelle wird durch diesen Prozess robuster und wir haben weniger Probleme und Bugs, wenn das Projekt erst einmal aktiv ist. Außerdem ist es sehr einfach, diese isolierten Komponenten mit ihren verschiedenen Zuständen und Interaktionen mit unseren Designern und Produktverantwortlichen gemeinsam zu nutzen, damit diese die Umsetzung mit dem, was entworfen wurde, überprüfen können. Das hört sich einfacher an, als es ist.
Vor dem Einsatz des Storybooks mussten Anweisungen wie diese an Leute geschickt werden, die einen Teil der Schnittstelle überprüfen sollten: "Gehen Sie in die Account-Ansicht. Klicken Sie dann auf den Link Neues Passwort setzen". Geben Sie dann ein Passwort mit nur drei Buchstaben ein. Drücken Sie die Eingabetaste. Nun sehen Sie das Fehlerfenster mit einem Beispieltext." Heute können wir "einfach" einen Link senden, mit dem man den Zustand des Fehlerfensters oder den Text ändern oder auf Schaltflächen klicken kann. Sehr hilfreich.

Allerdings führt der Aufbau isolierter Komponenten leider auch genau dazu: Isolierten Komponenten. Selbstverständlich möchten unsere Kunden, Designer, Projektleiter usw. im Browser "etwas sehen", das zumindest dem ähnelt, was sie im Design erstellt haben. In der Phase der Komponentenerstellung bedarf dieser Prozess einer gewissen Moderation. Das Gute daran ist, dass die Umsetzung der verschiedenen Ansichten einer App viel schneller geht, sobald die Komponenten erstellt und nutzbar sind.

Letztendlich erhalten wir ein gut getestetes, robustes Komponentenset, das nur selten Anpassungen oder massive Refactorings benötigen. Uns als Team erspart das eine Menge komplizierter Arbeit und unseren Kunden eine Stange Geld, das sonst für Iterationen, Refactorings und Bugfixes ausgegeben werden müsste.

Takeaways

• Änderung der Teamstruktur (von einer abteilungsmäßigen Struktur hin zu funktionsübergreifenden Teams) führt zu einer wesentlich besseren Kommunikation
• Einsatz von Design-Tools, die auf den Entwurf digitaler Produkte spezialisiert sind
• Änderung des Design-Workflows von seitengesteuertem Design zu komponentenbasiertem Design
• Arbeit mit Designbibliotheken/Designsystemen
• Erstellen Sie ein Master-Setup, eine auf dem FE-Framework basierende Bibliothek, die Ihre Entwickler verwenden (unsere ist Bootstrap)
• Handoff von Designer zu Entwickler in Marvel (Komponentenbibliothek mit allen Zuständen und Assets + Beispielbildschirme)
• Die Frontend-Umsetzung von Komponenten erfolgt zunächst in Storybook, später in der eigentlichen Schnittstelle
• Kommunikation während des gesamten Prozesses!