Code und Design

Das Modulare Denken hält Einzug in das Design

Ein einheitlicher Auftritt

Komponenten basiertes Entwickeln ist gang und gäbe, logischerweise hat sich diese Arbeitsweise auch im Design von Websites und App’s fest verankert. Und das ist auch gut so. Das Erlebnis ist für den User ist schlüssig und Komponenten werden sinnvoll wiederverwendet. Da ist es nur logisch diese Komponenten auch für alle Breakpoints und Endgeräte zu designen, nicht?

«Wir bräuchten noch einen x-ten Breakpoint, wäre das möglich?»

Jeder kennt es, das Design ist abgeschlossen und jetzt braucht es etliche Breakpoints. Nun muss alles in mehrfacher Ausführung wiederholt werden. Oder man übergibt einfach Mobile und Desktop und vertraut dem Frontend, was leider oft zu Spannungen auf beiden Seiten führt (verständlich).

Gängige Tools wie Sketch und XD decken das Bedürfnis nach der Übergabe von responsivem Verhalten noch zu wenig bis gar nicht ab. Warum also nicht schon im Design mehr auf den Code eingehen und somit schon wirklich responsive arbeiten und nicht nur responsive denken? Wäre es für den Designer und den Entwickler in Zukunft nicht einfacher schon von Anfang an mit Code zu arbeiten? Visuelles Coding sozusagen.

Warum Code im Design nicht an vorderster Stelle stehen sollte

Lücken schliessen

Genau dieses Lücken zwischen Design,Frontend und teilweise Backend versuchen neue Design-Tools der Zukunft zu schliessen. Webflow, Hadron und Phase sind nur einige Beispiele die auf Visuelles-Coding und Design setzen.

Zugegeben, der Gedanke im Hintergrund fixfertigen Code dem Entwickler zu übergeben ist reizvoll. Stundenlanges mühsames feinjustierten bei unterschiedlichsten Breakpoints entfällt und Probleme könnten tatsächlich schon früher entdeckt und verhindert werden. Ein Designer wird so zum Frontender und kommt den Entwicklern entgegen. Doch wollen wir das?

Mut zur «vermeintlichen» Lücke

Die Antwort ist nein, nein wir wollen das nicht und dafür gibt es auch gute Gründe. Dieses Vorgehen mag vielleicht für kleinere Projekte und einfache Seiten gut sein. Doch nicht überall macht dieses übereffiziente und optimierte Baukastenprinzip sinn.

Warum sollten sich Designer schon von Beginn weg technische grenzen setzten? Sich selber mittels vorgegebenen Tools und Modulen die Möglichkeiten nehmen, innovatives zu schaffen? Technisches Verständnis muss zwingend vorhanden sein, aber gleich den Code schreiben?

Gleiches gilt für die Entwicklung, sollte vorgegeber Code einfach noch angepasst und gegebenenfalls ergänzt werden? Kreative Lösungen und Herausforderungen in der Umsetzung, für herausragende digitale Produkte, sind auch hier notwendig. Ein Auge für Design ist zwingend, trotzdem ist ein «fundiertes Wissen» über UX/UI nicht notwendig.

Hier gilt es das optimale Zusammenspiel zwischen Entwickler und Designer zu finden. Ein reger Austausch, sorgfältiges Arbeiten und eine gemeinsame Identifikation mit dem Produkt lassen unterschiedliche Visionen auf beiden Seiten leben.

Wie sieht die Zukunft aus?

Mein Wunsch: Mehr als ein Referenzdesign

Klar ist, mit den neuen Designtools werden schon in einem früheren Stadium ganz neue Möglichkeiten geboten. Prototypen oder Designs sind mehr als nur statisch, sie beinhalten Transitions, Multimedia und auch Breakpoints.

Dem Designer sollte bewusst werden, dass in zukünftigen Prototypen responsives Verhalten schon möglich sein wird und dementsprechend wird ein gewisses Verständnis für Code unumgänglich. Die Verantwortung für das Verhalten der Seite liegt noch immer, oder noch mehr beim Designer. Auch Transitions und Animationen werden mit grosser Sicherheit noch mehr in die Designtools integriert. Und da wird in Zukunft gezwungenermassen Code im Hintergrund generiert werden.

Doch dieser Code sollte und darf in Zukunft nicht eine allzu grosse Rolle spielen, er wird immer unvollständig sein und gewisse Lösungen die neu, kreativ und innovativ sind, werden mit diesen Tools auch nicht abgefangen.

Fazit

Innovatives entsteht wenn man aus seiner Komfortzone herausbricht. Das gilt für Entwickler und Designer. Es sollte hinterfragt und verbessert werden. Dies macht unser Beruf einerseits spannend und ermöglicht es auch neue Lösungen zu finden. Solange es das Projekt erlaubt, macht es keinen Sinn sich von Beginn weg Grenzen zu setzten.

Quellen

Header: Photo by Christopher Gower on Unsplash