niklasbarning

Dieser Titel ist reißerisch. Ich weiß. Vielleicht gibt es sogar einen besseren Titel. Doch dieser Gedanke geistert mir schon etwas länger im Kopf herum.
Ich habe mit Kollegen darüber gesprochen. Mit Freunden und sogar mit Leuten, die nichts mit dem Thema am Hut haben.
Entstanden ist bei mir Frustration, Resignation, aber auch Verständnis.

Dieser Text ist etwas länger geworden. Darum stelle ich euch erstmal das Inhaltsverzeichnis vor.

• Was bisher geschah
• Die Umkehr
• Warum ist das ein Problem?
• Die Lösung liegt außerhalb des Tellers
• Einblicke schaffen Verständnis
• Und nun?

Was bisher geschah

Es herrschte, so um das Jahr 2011, eine regelrechte Aufbruchstimmung. Überall las man den Titel „Should Designers Code?“. Zu dieser Zeit gab es nicht viele Tools, die den damaligen Anforderungen der realen/digitalen Welt gerecht wurden. Viele Designerinnen und Designer stießen an die Grenzen von Photoshop, manche reizten das Machbare noch aus (kennt ihr Ebenenkompositionen?), doch andere schielten auf die Bildschirme ihrer Kollegen. Sie arbeiteten hauptsächlich mit Code.

Frontend Entwicklerinnen und Entwickler, so erkannte man, bewegen sich scheinbar mühelos durch die verschiedenen Status eines Layouts, können die Farben aller Buttons auf allen Seiten gleichzeitig ändern (dieses Beispiel ist vielleicht etwas banal aber anschaulich) und mit der gleichen Leichtigkeit an der Typografie schrauben.
Scheinbar hatte sich in den Agenturen der Welt, neben den Designerinnen und Designern, eine zweite dominante Spezies entwickelt. In den meisten Fällen konnte sie sogar Gestalten.

Was in den folgenden Jahren passierte, könnte man in der Biologie als „natürliche Evolution“ beschreiben. Beide Spezies lernten voneinander, tauschten ihre Skillsets aus, oder wechselten die Seiten. Die Designerinnen und Designer erkannten: Wenn ich mir nicht ein paar grundlegende Dinge aus der Frontend Entwicklung aneigne, verstehe ich die wichtigsten Dinge meines Jobs nicht.

So entstanden Designerinnen und Designer, die verstanden, wie Webseiten wirklich gebaut werden und Hand in Hand mit Entwicklerinnen und Entwickler arbeiten. Nicht in Photoshop, sondern im Browser mit all den Technologien, die dafür nötig sind. Diese Entwicklung konnte man in anderen Bereichen des Designs verfolgen. Codende Designerinnen und Designer sitzen heute genauso in der App- und Spieleentwicklung.
Das Prinzip ist einfach. Je näher ich an dem realen Produkt arbeite, desto höher ist die Qualität meiner Arbeit.

Die Umkehr

Allerdings passierte etwas merkwürdiges und für mich zuerst nicht Nachvollziehbares.
Adobe verlor Schrittweise und dann immer schneller die marktbeherrschende Position an große Namen wie Sketch, Invision, Marvel und Andere.
Die Botschaft war verheißungsvoll. Gestaltet euer Interface, inklusive Interaktionen und erstellt Prototypen. Ihr müsst nicht programmieren. Sogar größere Designsysteme können geschaffen werden, die modulare Layouts ermöglichen und den oben angesprochenen „ich ändere alle Farben eines Buttons mit einem Klick“ Workflow umsetzen.

Bei vielen Designerinnen und Designer kam die Erleichterung. Sie mussten sich nicht mit Themen aus der Entwicklung beschäftigen, die zugegebenermaßen nicht immer einfach zu verstehen sind, sondern wechselten nur ihr Werkzeug.
Aus Photoshop-Designer wurden Sketch-Designer.

Warum ist das ein Problem?

Es geht mir nicht darum, herauszufinden mit welchen Tools sich besser arbeiten lässt. Auch die Tatsache, dass Prototypen warscheinlich nicht immer gecodet werden, sollten möchte ich beiseite räumen.
Mir geht es viel mehr um das Mindset, was sich (wieder) bei Vielen eingeschlichen hat.

Ich rede von Symptomen wie „Pixelperfektes Design“, die nicht perfekt sind, weil jemand vergessen hat die Farbe vom letzten Button zu ändern. Wo Abstände nicht stimmen, Schriften wild gewürfelt sind und so weiter. Trotzdem erwarten Designerinnen und Designer, dass alles nach ihren Vorstellungen umgesetzt wird.
Manche würden jetzt die Fähigkeiten der Person anzweifeln, die dieses Layout erstellt hat. Ich hingegen finde aus folgenden Gründen recht verständlich, dass diese Symptome entstehen.

1. Es erscheint schneller und einfacher, ein Layout „zu zeichnen“, als es wirklich umzusetzen.
2. Übersicht kann während der Arbeit verloren gehen, je umfänglicher das Projekt wird. Was eigentlich klein bleiben sollte, wuchs zum Monster heran.
3. Durch Zeitdruck war es nicht möglich, sich an die Regeln zu halten, die man sich am Anfang gesteckt hat.
4. Mehrere Leute arbeiten an dem Projekt und niemand hat sich Gedanken gemacht, wie man diese Leute koordiniert.
5. Sich Irren und Fehler machen ist menschlich.
6. Punkt 1-5 wild durcheinander gewürfelt plus noch andere Faktoren, die euch sicher einfallen

Das größte Problem ist aber, wenn eine Fachrichtung die Andere als minderwertiger ansieht. Sätze wie „Die Entwickler setzen dann das um, was sich die Designer ausgedacht haben“, oder „Die Designer malen das schon hübsch an“ haben wir alle schon einmal gehört.

Die Lösung liegt außerhalb des Tellers

Eigentlich ist es ganz einfach. Wir sollten erst mal alle von unseren hohen Rössern absteigen und auf Augenhöhe agieren. Dann schauen wir, was für ein Produkt wir eigentlich bauen und wie nah die Gewerke daran arbeiten können.
Üblicherweise baden Entwicklerinnen und Entwickler ihre Finger nahezu im Produkt, was nicht bedeutet, dass nur sie daran arbeiten können. Genauso ist ein Layout von Designerinnen und Designern nicht wie eine heilige Schrift und kann immer verbessert werden.
Der Schlüssel ist, wie so oft, Kommunikation.
In der Softwareentwicklung haben sich verschiedene Arten und Frameworks für die strukturierte Zusammenarbeit entwickelt, die wunderbarerweise nicht nur für diesen Bereich genutzt werden kann. Das Buzzword zum googeln heißt „Agile Softwareentwicklung“. Sie versucht Transparenz und Platz für Kommunikation im wilden Arbeitsalltag zu schaffen.

Wenn Kommunikation zwischen allen Projektbeteiligten der Schlüssel ist, müssen wir wissen, mit welcher Sprache wir sprechen.
Oder anders: Mit welchen Werkzeugen arbeiten wir? Wie tun wir das eigentlich? Was für Vokabeln nutzen wir? Was können wir voneinander lernen? Bin ich eventuell auf dem Holzpfad?
Meist sind die Vorlagen, die Designerinnen und Designer gebaut haben, nur Anschauungsobjekte für Entwicklerinnen und Entwickler. Das komplette Layout muss noch einmal in Code umgesetzt werden. Warum kann nicht einfach das Layout direkt in Code erstellt werden und komplexeres Verhalten wird von Entwicklerinnen und Entwicklern umgesetzt?
Oft sind die Tools, die Entwicklerinnen und Entwickler nutzen auch geeignet um Interfaces zu bauen. Schöne Beispiele sind hier Unity oder Xcode.
Genauso sollten Entwicklerinnen und Entwickler in der Lage sein eigene Ideen und Verbesserungen in das Layout einzubringen.
Allerdings: Ohne Kommunikation geht es nicht. Redet miteinander und ihr werdet merken, dass ihr schneller und hochwertiger arbeitet.

Einblicke schaffen Verständnis

Das Schöne ist, dass durch die Kommunikation zwischen den Gewerken nicht nur ein Verständnis entsteht wie die Anderen arbeiten und wie man es besser zusammen schafft. Man lernt viele neue Sachen und versteht die Wirkung seiner Arbeit besser.
Ich habe neulich ein Stück Code geschrieben, welches automatisch Farbflächen aus einer Liste von Farbcodes in CSS generiert. Es erleichtert meinem Team und mir die Arbeit. Mir öffnete es ein Stück weiter die Tür, um lebende Designsysteme besser zu bauen.
Genauso bin ich als Designer nicht daran gebunden, dass Entwicklerinnen und Entwickler genau verstehen, wie ich eine bestimmte Interaktion gestalten möchte, sondern kann sie selber direkt im Browser umsetzen.

Als Entwicklerin oder Entwickler, kann ich genauso versuchen, komplizierten Code nutzbarer für meine Kollegen zu machen. Ein simpler Funktionsaufruf, der „macheFolgendes();“ heißt, kann von jedem genutzt werden und benötigt kein langes einlesen.

Und nun?

Vielleicht wirst du dich nicht in diesem Text wiederfinden. Du fragst dich wieso deine Sketch-Datei mit seinen vielen Artboards so schlecht ist und mich als Quatschkopf bezeichnen.
Allerdings ist die unbequeme Wahrheit, dass sich Dinge ändern. Wir müssen jeden Tag etwas Neues lernen.
Diese Art zu arbeiten wird für eine gewisse Zeit funktionieren. Früher oder später fallen aber alle Luftschlösser in sich zusammen. Entweder geben sie nicht den aktuellen Stand des Projektes wieder, oder sie sehen merkwürdigerweise immer etwas anders aus, als das fertige Produkt.

Und selbst wenn ihr bei eurer Arbeitsweise bleibt. Redet miteinander. Es gibt nichts Schlimmeres als Menschen, die verfeindete Lager gebildet haben, ohne einmal miteinander geredet zu haben.
Wenn ihr redet, kommt der fachliche Austausch meist von alleine.