Die Zukunft des User Interface Designs: UI-Tools der nächsten Generation

Veröffentlicht: 2022-03-11

UI-Design-Tools haben sich seit der ersten Generation von Adobe Photoshop, einem Programm zum Bearbeiten von Fotos und nicht zum Erstellen dynamischer Benutzeroberflächen, weit entwickelt. Die aktuelle Generation von Tools wie Adobe XD, Figma und Sketch hat unsere Arbeit einfacher und schneller gemacht.

Dennoch gibt es viele Ineffizienzen in unseren täglichen Arbeitsabläufen, und wir verschwenden wertvolle Zeit und Ressourcen, wenn wir Produkte entwerfen könnten, die Menschen verwenden möchten. Die heute verfügbaren Designprogramme sind denen überlegen, mit denen wir angefangen haben, aber sie nutzen die aktuelle Technologie nicht und hindern uns daran, unser volles Potenzial als UI-Designer auszuschöpfen.

Es ist Zeit für eine neue Generation von UI-Tools.

Integration von Design und Code

Zukünftige Benutzeroberflächen-Tools werden Design und Code zusammenbringen, um Designern und Entwicklern ein nahtloseres Erlebnis zu bieten. Unsere aktuellen Tools helfen uns nicht beim Entwerfen von Web-UIs; Sie helfen uns dabei, abstrakte Darstellungen von Web-UIs zu entwerfen. Mock-ups, die in Figma und Sketch erstellt wurden, sind vom Quellcode getrennt.

Heute kennen viele Designer die Grundlagen von HTML und CSS. Einige Hardliner entwerfen im Code, aber das ist für komplexe Projekte nicht effektiv; Designer müssen in der Lage sein, einen Machbarkeitsnachweis schnell zu untersuchen, bevor sie sich darauf festlegen.

Softwareentwickler haben Visual Studio Code, ein Tool, das Codebearbeitung und -entwicklung vereint und es Ingenieuren ermöglicht, Code in derselben Umgebung zu erstellen, zu testen und zu debuggen. Ebenso benötigen Designer eine visuelle Entwicklungsumgebung, die alle Designfunktionen bietet, aber auch produktionsbereiten Code generiert.

Hier ist, was die Zukunft bringt.

Die parallele Erstellung ersetzt Designer/Entwickler-Übergaben

Es gibt zu viel Hin und Her zwischen Designern und Entwicklern, besonders während der Übergabephase. Teilweise ist die Übergabe so zeitintensiv und anstrengend, dass die Qualität der Arbeit darunter leidet. Mit Design-Tools der nächsten Generation, die mit dem Quellcode verbunden sind, sind Entwickler nicht mehr allein für die Erstellung von Benutzeroberflächen verantwortlich. Stattdessen können sie sich auf die Entwicklung der logischen Architektur konzentrieren, die die Benutzeroberfläche eines Produkts mit seinem Backend verbindet und dafür sorgt, dass es ordnungsgemäß funktioniert.

Designer werden die Grundlagen für UIs mit dem eingebauten Code legen, und Entwickler werden auf diesem Code aufbauen, um Produkten Leben einzuhauchen. Designer müssen Entwickler nicht mehr mit Anfragen wie „Bitte fügen Sie 16 px Abstand statt 8 px, wie im Mock-up gezeigt“ nörgeln. Und Entwickler müssen nicht innehalten, um Designfragen zu stellen, wie z. B. „Wie sollte diese Komponente zwischen Tablet- und Desktop-Haltepunkten skaliert werden?“

Stattdessen werden Designer und Entwickler bei wichtigeren Fragen zusammenarbeiten, z. B. ob ein Designansatz angesichts der Zeit und des Budgets praktikabel ist oder ob alle Zustände einer UI-Komponente berücksichtigt wurden.

Design-UI-Tools und Entwicklersoftware werden aufeinander abgestimmt

Aktuelle Tools verlassen sich auf maßgeschneiderte Programmiermodelle, um Designkomponenten zu generieren. Diese Modelle sind im Allgemeinen nicht so robust wie CSS und erlauben es Designern nicht, den automatisch generierten Code zu sehen, der ihren Designdateien zugrunde liegt – Code, der letztendlich in HTML, CSS oder JavaScript exportiert werden muss. Es wäre viel einfacher, wenn unsere Tools HTML und CSS nativ verwenden würden.

Zum Beispiel verwendet CSS das Box-Modell, das die Platzierung der HTML-Elemente auf jeder Seite innerhalb einer Box erfordert, die so codiert ist, dass sie Höhe, Breite, Rand und Abstand definiert. Figma kommt dieser Fähigkeit mit seiner Auto-Layout-Funktion nahe. Aber wenn Figma das Box-Modell verwenden würde, das bereits die meisten Web-UIs unterstützt, müssten Entwickler weniger übersetzen und exportieren.

Dasselbe gilt für die Stilvererbung, die steuert, was passiert, wenn für ein bestimmtes Element kein Stil angegeben ist – ähnlich wie bei einem Standard. CSS verwendet es, aber die meisten Design-Tools, die nicht webspezifisch erstellt wurden, tun dies nicht.

Wir brauchen unsere Tools, um Webansichten auszugeben, nicht statische Zeichenflächen oder Modelle. Wir brauchen keine HTML- und CSS-Simulatoren. Wir brauchen HTML und CSS.

Zwei überlappende blaue Kreise. Der linke Kreis trägt die Bezeichnung UI Designer. Der rechte Kreis trägt die Bezeichnung Front-End-Entwickler. Im linken Kreis steht „Designtool der nächsten Generation“ und im rechten „Complex Logic (Javascript)“. In der Mitte in Dunkelblau, wo sie sich schneiden, steht „Layout (HTML)“, „Styling (CSS)“, „Einfache Logik (JavaScript)“.
Design-Tools der nächsten Generation werden direkt mit dem Quellcode verbunden, wodurch wegwerfbare Ergebnisse eliminiert werden und Designer und Entwickler in die Lage versetzt werden, an demselben Ergebnis zusammenzuarbeiten: dem Quellcode.

Mock-ups werden obsolet

Statt Wegwerf-Mock-Ups werfen wir Mock-Ups aus der Tür.

Mock-ups lassen zu viele Fragen unbeantwortet. Es ist unmöglich, einen für jede digitale Umgebung zu entwerfen. Heute erstellen Designer Layouts für Bildschirmbreiten von 320 px, 834 px und 1440 px; aber was passiert, wenn ein Teil des Layouts in einem 1220-Pixel-Darstellungsfenster kaputt geht? Und warum nicht für 375 px optimieren, eine übliche Größe für die heutigen größeren Telefone?

Das Erstellen einer Zeichenfläche für jedes Szenario ist unpraktisch, insbesondere wenn alle Haltepunkte und Ansichten berücksichtigt werden – ganz zu schweigen von dunklen Themen. Das Entwerfen für all diese Variablen erhöht die Anzahl der Zeichenflächen über das Maß hinaus.

Mock-ups sind auch eine Verschwendung von Ressourcen. Sie sind zeitaufwändig in der Erstellung und haben im digitalen Produktdesign an Bedeutung verloren. Webflow hat Mock-ups abgeschafft und plädiert stattdessen für responsive, interaktive Prototypen. (Leider ist Webflow auf webbasierte Lösungen beschränkt und richtet sich an einfache Websites). Und während wegwerfbare Ergebnisse während der Ideenfindung sinnvoll sein können, sind sie während der Lösungsphase eine Verschwendung.

Alle Systemzustände werden berücksichtigt

Alle digitalen Produkte haben Zustände, die dem entsprechen, was sie zu einem bestimmten Zeitpunkt tun – zum Beispiel das Abwürgen beim Laden oder das Anzeigen einer Fehlermeldung.

Jeder Zustand muss berücksichtigt werden, aber aktuelle UI-Tools überlassen diese Aufgabe den Designern und zwingen sie, zahlreiche Varianten einer einzelnen Komponente zu erstellen. Die Entwicklungstools React und Vue.js ermöglichen Entwicklern eine einfache Anpassung an alle möglichen Zustände einer Komponente. Design-Tools müssen diesem Beispiel folgen und Designer ermutigen – sie sogar nörgeln – um sicherzustellen, dass alle Komponentenzustände für sie entworfen werden.

Screenshot von Storybook.js. Auf der linken Seite ist ein Menü und die erste Überschrift ist Bibliothek. Darunter steht das Wort „Diagramme“ und darunter steht „Histogramm“. Die nächste Ebene darunter listet drei Zustände auf. Der erste, „default“, ist hervorgehoben. Im Hauptteil der Seite befindet sich ein Balkendiagramm mit der Überschrift „Latenzverteilung“. Darunter befindet sich eine Liste mit Steuerelementen.
Storybook.js fungiert als Enzyklopädie der UI-Komponenten eines Repositorys. Das Optimieren der Steuerelemente zeigt eine Komponente in allen möglichen Zuständen. Design-Tools müssen sich in diese Richtung bewegen, anstatt isolierte Silos zu sein, die von der Codebasis eines Produkts getrennt sind.

Echte Daten ersetzen Platzhalterinhalte

So wie Designer Komponenten für mehrere Zustände erstellen, entwerfen sie auch für eine Vielzahl von Daten. UI-Designer müssen in der Lage sein, ihre Komponenten mit den tatsächlichen Eingaben zu testen – den Texten, Bildern, Datumsangaben, Namen, Titeln und mehr – die letztendlich die Komponenten in ihren Designs füllen. Derzeit können Designer Daten nur simulieren, indem sie sie manuell kopieren und in Zeichenflächen einfügen, eine äußerst mühsame Aufgabe. Es gibt Plugins, die helfen können, diesen Prozess zu automatisieren, aber sie sind umständlich.

Entwickler zu fragen, wie Komponenten mit Daten umgehen, ist auch nicht die Antwort. Bis die Komponenten getestet werden, ist es zu zeitaufwändig, sie neu zu entwerfen. Und wenn Designer Komponenten nicht mit echten Daten testen und iterieren können, wie sollen sie dann wissen, ob eine Karte mit einem langen Titel – oder gar keinem Titel – funktioniert? Wie werden sie feststellen, dass eine Schriftart keine arabischen Zeichen unterstützt oder dass eine Website keine Sprachen unterstützt, die von rechts nach links gelesen werden?

Eine "Seitentitel"-Komponente von Google Material Design. Die linke Seite zeigt, wie die Komponente funktioniert, wenn der Titel von links nach rechts gelesen wird. Eine Spalte unter dem Bild zeigt Informationen über die Größe der Symbolauffüllung vom Bildschirmrand, den Abstand des Titels vom Bildschirmrand, die Auffüllung unter dem Titel, die Höhe der Navigationsleiste und die Auffüllung des Überlaufmenüs. Auf der rechten Seite wird dieselbe Seitentitelkomponente in Arabisch angezeigt, um zu demonstrieren, wie die Komponente für eine Sprache funktioniert, die von rechts nach links gelesen wird. Eine Spalte unter dem Bild zeigt Informationen über die Symbolauffüllung vom Bildschirmrand, den Titelabstand vom Bildschirmrand, die Auffüllung unter dem Titel, die Höhe der Navigationsleiste und die Auffüllung des Überlaufmenüs.
Material Design unterstützt standardmäßig Bidirektionalität.

Edge-Case-Tests werden einfacher

Wenn UI-Tools endlich allen Zuständen gerecht werden und Tests mit echten Daten ermöglichen, können Designer Randfälle besser vorhersehen. Sobald eine Komponente erstellt ist, werden die Designer ihre verschiedenen Zustände einem Stresstest unterziehen und sie mit verschiedenen Daten bombardieren, um zu sehen, wie sie sich in verschiedenen Szenarien verhält. Auf diese Weise wird die Benutzeroberfläche zur Domäne des Designers, wodurch sich die Entwickler auf Aufgaben wie das Korrigieren des JavaScripts oder das Testen der APIs konzentrieren können.

Zwei Textblöcke demonstrieren den Unterschied, wie viele Pixel verschiedene Sprachen benötigen. Der obere Block lautet „Passwort wiederholen“. In Rot darüber steht „210 Pixel breit in Englisch“. Der zweite Textblock lautet „Wiederholen Sie das Kennwort“. Darüber steht in Rot „380 Pixel breit in Deutsch“.
Kann Ihre UI-Komponente auf einen Sprachwechsel reagieren? Die einzige Möglichkeit, dies herauszufinden, besteht darin, es mit verschiedenen Daten zu testen.

Eine Welt von Entwicklertools und Browsererweiterungen von Drittanbietern wird sich öffnen

Sobald unsere Arbeit in HTML und CSS lebt, wird während der Designphase ein ganzes Ökosystem von Erweiterungen verfügbar sein, wie das unverzichtbare Lighthouse für Leistungs-, SEO- und Barrierefreiheits-Audits oder die verschiedenen Browser-Entwicklertools, die Geräte-Breakpoints und niedrige Netzwerkgeschwindigkeiten simulieren. Das Browser-Toolset ist viel wertvoller für das Erstellen und Testen von produktionsreifen Benutzeroberflächen als jedes der Plug-ins in Figma, Sketch oder Adobe XD.

Designer und Entwickler arbeiten parallel

Ich vergleiche den aktuellen Stand der Produktentwicklung mit einer Küche, in der ein Koch versucht, ein Gericht zuzubereiten, indem er einem anderen Koch vorschreibt, was zu tun ist: Es könnte funktionieren, aber es wird erheblich länger dauern und weit weniger effizient sein. Es gibt Unternehmen, die Code-basierte Design-Tools entwickeln – Hadron, Modulz und Relate haben Produkte in der Beta-Phase. Die weit verbreitete Einführung dieser Tools markiert den Beginn einer Revolution in der Erstellung digitaler Produkte.

Es wird auch eine radikale Veränderung in der Designer-Entwickler-Beziehung signalisieren. Wenn beide Seiten parallel arbeiten, werden Produktteams exponentiell effizienter. Entwickler können sich frei mit der komplexen Logik der UI-Architektur auseinandersetzen, anstatt Zeit mit der Interpretation von Modellen zu verschwenden oder sich von Designern verzetteln zu lassen, die sie bitten, Pixel zur Perfektion zu bringen. Und Designer werden für ihre Teams und Unternehmen wertvoller, wenn sie Mitgestalter erfolgreicher digitaler Produkte werden.