Sollten Designer Code oder Entwickler entwerfen?

..oder wir brauchen eine neue Rolle

Kann eine Person Design & Code haben und nicht überfordert sein?
Wie sollten Designer und Entwickler zusammenarbeiten?
Spricht nur häufig genug?
Wo genau endet das Design und die Entwicklung beginnt?
Was ist Design und was ist Entwicklung?

Dieses Thema war seit Jahren mein Dilemma.

Ich habe meine Karriere mit dem Titel „Web-Master“ begonnen, das heißt, ich könnte die Website entwerfen und codieren oder ein Wordpress-Design anpassen - eine wichtige Fähigkeit für einen erfolgreichen Freelancer. Dies ist kein Einzelfall. Brad Frost, der Autor des berühmten Atomic Design und vieler anderer Designer, hat heute einen ähnlichen Weg eingeschlagen. Zu der Zeit wurden die am besten gestalteten Websites in Flash erstellt, und diese Designer müssen selbst programmiert haben. Am Ende gab es Probleme mit SEO, aber es ist eine andere Geschichte.

Mit der Zeit habe ich den sperrigen Titel "UI / UX Designer / Frontend-Entwickler" erworben. Aber auch die Herausforderungen wuchsen.

Als Full-Stack-Designer habe ich viel Zeit investiert, um nicht nur mit den neuen visuellen Trends Schritt zu halten. Verschiedene Plattformen und mobile Apps werden immer mehr nachgefragt. Es waren nicht mehr nur wenige Seiten für Websites, die komplexere Produkte erstellen, die Sie tiefer in die Geschäfts- und Benutzerforschung eintauchen, an der Produktarchitektur arbeiten, Benutzertests durchführen und die Analyse im Auge behalten möchten.

Andererseits war es im Frontend nicht einfacher. Der HTML / CSS / jQuery-Stack wurde durch eine Reihe von Frameworks und Methoden ersetzt, die jeden Monat auftauchten, bevor Angular und React die Revolution revolutionierten. Dadurch wurde das Frontend zum richtigen Ingenieurwesen erhoben und viele frühere Back-End-Entwickler wurden ins Feld gezogen. Diese Leute sind es gewohnt, mit der Kommandozeile zu navigieren und glauben nicht, dass Schnittstellen überhaupt notwendig sind. Es hat das Spiel komplett verändert. Frontender, die schöne Schnittstellen und reaktionsschnelle Layouts mit reibungslosen Interaktionen erstellen wollten, aber nicht tief in Hardcore Engineering eintauchen wollten, waren dazu verdammt, auf Junior-Niveau zu bleiben, und erhielten weder von Development noch von Design Crowd Respekt. Viele von ihnen, darunter auch ich, führten zu einer Identitätskrise.

In beiden Bereichen herrscht großes Durcheinander. Wenn Sie ein Designer sind - Sie werden in die Forschungs- und Geschäftsthemen von UX überfordert, wenn Sie ein Entwickler sind - eröffnet sich Ihnen eine völlig neue Welt des Hardcore Engineering.

Inzwischen wächst der Abstand zwischen den Feldern. Designer und Entwickler leben in verschiedenen Welten, sprechen verschiedene Sprachen und geben vor, dass es so ist, wie es sein sollte. Der einzige Berührungspunkt ist, wenn Designer ihre pixelgenauen statischen Modelle in 2 Auflösungen (Handy und Laptop) mit roten Rändern und Schriftgrößen an die Entwickler schießen und anschließend überprüfen, ob alles genau in Code kopiert wurde. Dies entmutigt die Letzteren dazu, eine Meinung über den visuellen Teil der Benutzeroberfläche zu haben und sich nur über die Phantasie unrealistischer Designer zu beschweren.

Am Ende gehört die Benutzeroberfläche niemandem, das Endergebnis ist immer ein Kompromiss zwischen Designer und Entwickler, der die Kreativität beider abbricht. Außerdem ist es einfach ineffizient, es wird viel Zeit für die Perfektionierung statischer Pixel und langwieriger Kommunikation verschwendet. Dinge, die direkt im Code besser ausgeführt werden können.

Gibt es eine Lösung?

Schauen wir uns den Produkterstellungszyklus und die Jobtitel aus verschiedenen Phasen genauer an.

Je mehr Sie sich auf der linken Seite befinden, desto stärker zoomen wir auf das Gesamtbild hinaus, so dass wir uns weniger auf Details konzentrieren. Ja, Design muss mit dem Verstehen der Geschäfts- und Benutzerziele beginnen, sich auf die Lösung der richtigen Probleme konzentrieren und alle Teile zu einem ganzheitlichen Produkt zusammenfassen, das zu einem nahtlosen Benutzererlebnis führt. Je näher wir in Details hineinzoomen - wie beispielsweise die Benutzeroberfläche für bestimmte Bildschirme, Reaktionsfähigkeit, visuelle Details, Schaltflächen, Schriftgrößen, Ränder und Interaktionen -, desto schwieriger wird es, das Gesamtbild im Blick zu behalten.

Aber genau das wird von so genannten UX / UI-Designern erwartet, die kontinuierlich vergrößert und verkleinert werden. Und es funktioniert selten, meistens fallen wir einem Hasenloch der Pixel-Perfektionierung zu, aber die Logik fehlt völlig.

Es wird sogar detailgenau, wenn UX-Designer in funktionsübergreifenden Teams in den gleichen Sprints mit Entwicklern arbeiten. UX und Engineering haben ein anderes Tempo, es kann nicht parallel bearbeitet werden. Aber UI und Engineering können und sollten - den Unterschied spüren!

In den meisten Teams ist eine Rolle für mehrere Schritte verantwortlich, in einigen Teams werden einige Schritte abgewiesen. Je größer das Team wird, umso enger wird die Verantwortung der einzelnen Rolle. Aus einigen Gründen ist es gut, die UI-Designrolle mit der UX-Rolle zu kombinieren, nicht jedoch das UI-Design mit der UI-Entwicklung.

Wie Sie anhand des Schemas sehen können, steht das UI-Design der Entwicklung viel näher als alle Geschäftsstrategien, Ideenfindung, Benutzerforschung usw. Warum nicht UX / UI-Designer überdehnen, sondern UI mit der Entwicklung verknüpfen und eine Bridge-Rolle erstellen - UI-Ingenieur, kreativer Frontend-Entwickler, wenn Sie möchten - eine Rolle, die das visuelle Erlebnis, das Design und die Entwicklung von UI und Interaktion als Ganzes wirklich besitzen wird und in diesem Bereich kreativ werden kann. Die Benutzeroberflächenentwicklung kann kreativer und unterhaltsamer sein, viel mehr Spaß machen, als Pixel in Sketch zu verschieben.

Multidisziplinäre Teams

Eine gängige Praxis, die ich gesehen habe, ist die Aufteilung des Unternehmens in verschiedene multidisziplinäre Teams, die entweder verschiedene Teile eines Produkts besitzen oder unterschiedliche Produkte, die mit einem Ökosystem verbunden sind. Dieser Ansatz hat viele Vorteile - unabhängige Teams können sich schneller bewegen, da sie weniger von einem anderen abhängig sind. Der kleine, funktionsübergreifende Ansatz lässt die Mitarbeiter im Team, darunter Designer und Entwickler, eng miteinander arbeiten und das besitzen, woran sie arbeiten motiviert jedes Teammitglied, bessere Ergebnisse zu erzielen. ABER. Es gibt immer ein Aber. Dieser Ansatz kann Teams radikal voneinander trennen, Produktkonsistenz kann zu einem echten Problem werden. Es kann schwierig werden, transparent zu sein, was verschiedene Teams an einigen Dingen tun, die mehrmals erledigt werden können.

Ich glaube eher an einen vielschichtigen „Fließband“ -Ansatz, bei dem die Leute sich nicht mit weiteren Arten von Aufgaben innerhalb eines kleinen unabhängigen Produkts / Features beschäftigen, sondern sich auf ihre Stärken bei mehreren Produkten / Features konzentrieren. Auf diese Weise müssten die Mitarbeiter auf natürliche Weise zusammenarbeiten, und jede nächste Schicht würde eine Qualitätskontrolle der Arbeit der vorherigen Schichten vornehmen. Dies würde auch dazu beitragen, die Konsistenz aufrechtzuerhalten.

Beispielsweise kann ein UX-Designer größere Produktbestandteile erfassen, ohne in die Details der Benutzeroberfläche einzutauchen, und der UI-Ingenieur kann diese konsistenter abdecken.

Sobald dies geschieht, müssen wir nicht mindestens drei Personen (PO, Designer und Dev) einbeziehen, um all diese Mikrozustände zu treffen, Entscheidungen über die Reaktionsfähigkeit zu treffen und Schaltflächen im Design und all diese unsinnigen Dinge mit Symbolen zu versehen.

Und es ist nur relevant für Websites, die sich vorwiegend nach Art von Websites befinden, aber noch mehr für normale Produkte. Ich bin sicher, wir werden eine viel schönere konsistente Benutzeroberfläche, wirklich ansprechende Schnittstellen und reibungslose Interaktionen sehen. Glauben Sie mir, der Code ist im Interaktionsdesign leistungsfähiger als jedes Prototyping-Tool.

Wie können wir das machen?

Ich lobe Designer, die programmieren, und loben Entwickler, die noch mehr entwerfen können (weil sie sehr wahrscheinlich mit dem Entwerfen beginnen als Designer, die nach meiner Erfahrung programmieren). Wenn Sie mit einem Entwicklungsentwickler zusammenarbeiten, geben Sie ihm Zeilenmodelle, sogar Drahtmodelle, damit die Details im Code ausgeführt werden können. Arbeiten Sie stattdessen mit dem Entwurfssystem zusammen. Der schwierigste Teil: Entwickler davon überzeugen, die Logik von der Benutzeroberfläche zu trennen und dem Entwickler die Kontrolle über die Benutzeroberfläche zu geben.

Außerdem ist es gut für dein Gehirn. Beim Design geht es um die linke, kreative Seite des Gehirns und die Entwicklung um die rechte, die für analytische Fähigkeiten verantwortlich ist. Das Üben von Design hilft Entwicklern dabei, neue originelle Wege zur Lösung der Probleme zu finden. Durch das Kodieren können Konstrukteure rationalere Entscheidungen treffen und kritisches Denken unterstützen.