Smashing Podcast Folge 9 mit Stephanie Walter: Wie kann ich mit UI-Frameworks arbeiten?

Als Entwickler mag ich an UI-Frameworks unter anderem, dass sie oft mit Standardstilen ausgestattet sind, aber sollten wir uns in Projekten darauf verlassen? Einfach das Standard-Styling verwenden und darauf vertrauen, dass derjenige, der das Framework erstellt hat, beim Design dieser Komponenten wirklich gute Arbeit geleistet hat? Begleiten Sie mich in der heutigen Podcast-Episode, in der ich mit der UX-Designerin Stephanie Walter über Dinge spreche, die wir beim Aufbau eines UI-Frameworks berücksichtigen sollten.

Notizen anzeigen

• Stephanies Website
• Stefanie auf Twitter

Wöchentliches Update

• „Wie man ein Karten-Matching-Spiel mit Angular und RxJS erstellt“ von Anna Prenzel
• „So erstellen Sie eine Headless-WordPress-Site auf dem JAMstack“ von Sarah Drasner
• „Magic Flip Cards: Lösen eines gängigen Größenproblems“ von Dan Halliday
• „Django-Highlights: Benutzermodelle und Authentifizierung (Teil 1)“ von Philip Kiely
• „Wie man Karten mit React und Leaflet erstellt“ von Shajia Abidi

Abschrift

Drew McLellan: Sie ist eine benutzerorientierte Designerin und Expertin für mobile Erlebnisse, die reizvolle Produkte und Schnittstellen mit besonderem Fokus auf Leistung kombiniert hat. Sie hat an Projekten für Kunden wie die Universität Luxemburg, die Europäische Investitionsbank, BMW und Microsoft gearbeitet, um nur einige zu nennen, und sie hilft diesen Kunden dabei, ihrem Publikum erfolgreiche Projekte von der Strategie bis zum Endprodukt zu liefern. Sie ist eine Google Developer-Expertin für Produktdesign und eine leidenschaftliche Lehrerin, die ihr Wissen in zahlreichen Blogbeiträgen, Artikeln, Workshops und Konferenzpräsentationen weitergibt. Wir wissen also, dass sie eine erfahrene User Experience Designerin ist, aber wussten Sie, dass sie einmal bei Sir Elton John Teppiche verlegt hat? Meine Smashing-Freunde, bitte heißt Stephanie Walter willkommen. Hallo Stephanie, wie geht es dir?

Stephanie Walter: Hi, ich bin super und fand die Einführung toll.

Drew: Deshalb wollte ich heute mit Ihnen über ein bestimmtes Thema sprechen, und das ist das Thema der Verwendung von handelsüblichen Benutzeroberflächen-Frameworks. Jetzt sind Sie User Experience Designer und arbeiten mit vielen verschiedenen Kunden zusammen. Ihre Aufgabe ist es, diesen Kunden dabei zu helfen, die bestmöglichen Benutzererlebnisse zu schaffen, indem Sie äußerst benutzerfreundliche Benutzeroberflächen erstellen. Die Idee, dies mit einem handelsüblichen Werkzeugsatz tun zu können, scheint mir also etwas weit hergeholt. Ist die Verwendung des UI-Frameworks etwas, das Sie während Ihrer Arbeit häufig sehen?

Stephanie: Ja, das ist etwas, das ich oft gesehen habe, besonders in den letzten Jahren, weil ich angefangen habe, mit einer Agentur zu arbeiten, und jetzt in der Firma arbeite. Also in diesen supergroßen IT-Tech-Teams und ja, im Moment gibt es viele Framework-UIs, wie die, die ich am häufigsten gesehen habe, ist Material-UI, im Grunde ist Materialdesign eine Art Google-Design-Richtlinien und -Ding, und Material -UI ist das Team von Angular, aber auch das Team von React. Sie haben ihr eigenes Framework erstellt, indem sie das Look-and-Feel des Materialdesigns von Google verwendet haben. Aber das hat nichts mehr mit Google zu tun. Es ist einfach so, dass sie, ich weiß nicht, ich glaube, sie mochten das Aussehen und die Haptik. Im Moment sind dies also die beiden wichtigsten UI-Frameworks, mit denen ich arbeite. Und es gibt auch etwas namens Ant Design, das ziemlich populär geworden ist.

Stephanie: Es ist ein React-Framework. Ich weiß nicht, ob sie auch Angular haben. Ich glaube, es wurde von einem Team in China hergestellt. Und es ist interessant, weil es nicht nur die Komponenten bereitstellt, alles in React, sondern wenn Sie auf ihre Website gehen, erhalten Sie auch die Scratch-Dateien, was eigentlich ziemlich interessant ist, weil es den Designer dann irgendwie motiviert oder ihm hilft, zu bauen oder zu formen die Schnittstelle in die UI-Komponenten, die von diesem Framework verwendet werden. Also ja, das ist etwas, was ich oft gesehen habe, besonders in großen IT-Teams, weil diese meistens keinen Designer haben. Im Moment bin ich im Grunde ein UX-Team in einem kleinen Team bei einer europäischen Investmentbank. Also ich als UX-Designer. Ich arbeite mit einem Team von Entwicklern, Business-Analysten und all den guten Leuten zusammen, bin aber immer noch ein Designer für das gesamte Projekt.

Stephanie: Bis zu meiner Ankunft gab es keinen Designer. Es handelt sich also um eine Art Lösung, die in vielen Unternehmen implementiert wird, insbesondere beispielsweise bei internen Produkten. Wo sie normalerweise sagen, okay, dafür brauchen wir eigentlich keinen Designer. Wir brauchen nur etwas, das für unsere internen Benutzer funktioniert, und verwenden wir einfach ein Framework, weil es für die Entwickler praktisch ist. Die meisten Komponenten sind bereits vorhanden und da sie keine Designer im Team haben, ersetzt es sozusagen die Rolle eines UI-Designers. Ja, das Problem dabei ist, okay, dann haben Sie die Komponenten, aber die Rolle des UI-Designers besteht nicht nur darin, zu entscheiden, ob die Schaltfläche rot, grün, orange, blau oder was auch immer sein soll. Normalerweise ist die Rolle des UI-Designers die Informationsarchitektur und das Verstehen der Benutzeranforderungen. Also alles, was über die Schnittstelle hinausgeht. Selbst wenn Sie diese Art von Framework haben, kümmert sich diese Art um die gesamte Benutzeroberfläche, also um das, was Sie visuell auf dem Bildschirm sehen.

Stephanie: Irgendwann brauchst du immer noch jemanden, der versteht, was wir auf den Bildschirm bringen, wie wird es sich verhalten? Was passiert, wenn wir hier klicken? Wie erreicht der Benutzer sein Ziel? Wie kommen wir von Punkt A nach Punkt B? Weil wir ein Modell verwenden können, können wir Registerkarten verwenden, wir können alle Komponenten verwenden. Deshalb ist es immer ein bisschen komplex und knifflig.

Drew: Ist es Ihrer Meinung nach möglich, eine brauchbare Benutzeroberfläche mit einem handelsüblichen UI-Framework zu erstellen, oder wird es immer ein kleiner Kompromiss sein?

Stephanie: Ich hoffe es irgendwie. Ich hoffe es zumindest, denn sonst baue ich unbrauchbare Interfaces. Diese Antwort ist also völlig voreingenommen, aber ja, ich denke schon, aber es hängt auch von der Kompromissbereitschaft ab, zu der Sie bereit sind, und es gibt Kompromisse auf beiden Seiten. Im Moment kompromittiere ich zum Beispiel viele Schaltflächen, weil Sie einige wirklich spezifische Schaltflächen in der Material-UI haben und ich den Welleneffekt auf der Schaltfläche nicht wirklich mag. Ich denke, es funktioniert auf Mobilgeräten hervorragend, da Sie auf Mobilgeräten eine Art großes Feedback benötigen, wenn der Benutzer auf die Schaltfläche klickt oder sie berührt. Aber dann sind die Schritte eine Art Welleneffekt, der bis zum Knopf reicht. Es ist ein bisschen übertrieben, besonders wenn es viele Knöpfe gibt. Aber wir werden diesen Welleneffekt trotzdem beibehalten, da es sehr komplex wäre, ihn zu entfernen, da dies in das React-Framework integriert war. Und um einen weiteren Hover-Effekt auf dieser Schaltfläche zu haben, etwas Subtileres, das hier nicht so ein Whooshy-Ding sein wird. Es wäre superkomplex.

Stephanie: Das ist also die Art von Kompromissen, die man eingeht. Aber in der Zwischenzeit gehe ich keine Kompromisse bei bestimmten Dingen ein, bei denen es sich um benutzerdefinierte Komponenten handelt. Wo ich zuvor gearbeitet habe, der aktuelle Kunde für eine Reise- und Fluggesellschaft. Und die Fluggesellschaft hat einige wirklich, wirklich super spezifische Bedürfnisse. Der Kalender für die Fluggesellschaft zum Beispiel, Sie möchten Preise eintragen, Sie möchten eintragen … Wenn Sie an einem bestimmten Datum nicht zu diesem Zielort reisen, wissen Sie nicht, wann Sie das eintragen sollen, Sie haben diesen Abflug und diese Ankunft und Der grundlegende Kalender der meisten dieser UI-Frameworks bietet solche Dinge nicht. Irgendwann kann man also sagen, okay, wir verwenden einfach den Kalender, den sie haben. Und das ist es. Sie müssen darüber hinausgehen. Die meisten Kompromisse bauen also im Grunde darauf auf, verwenden wir die Basiskomponente? Erstellen wir eine benutzerdefinierte, die den Benutzeranforderungen entspricht? Oder machen wir eine Mischung aus beidem? Im Fall des Kalenders verwenden wir zum Beispiel das Kalenderraster, also verwenden wir die Basiskomponente und haben sie dann obendrein mit Anpassungen erweitert. Es war also eine Menge React-Entwicklung für diesen einen.

Stephanie: Und ja, normalerweise geht man viele Kompromisse ein.

Drew: Es hört sich also so an, als ob die Verwendung eines Benutzeroberflächen-Frameworks Sie ein Stück weit dorthin bringen kann, aber um wirklich eine gute Benutzeroberfläche als Ergebnis zu haben, müssen Sie noch einiges an Anpassungen vornehmen?

Stephanie: Normalerweise. Ja.

Drew: Geht diese Anpassung über Themen hinaus?

Stephanie: Ja, mein Entwickler wünschte sich, es würde nicht über Theming hinausgehen. Eugene, wenn du mir zuhörst. Ich glaube, er wäre super glücklich, wenn wir bei allem einfach ein paar Farben ändern würden. Aber ja, irgendwann müssen Sie über die Anpassung hinausgehen, denn erstens sind UI-Frameworks wie Lego-Tools eine Art Toolbox. Sie haben also viele verschiedene Komponenten in der Box, aber das baut keine Seite auf. Du brauchst noch eine Kopfzeile, du brauchst noch eine Fußzeile. Sie benötigen immer noch zusätzliche Inhalte, die nicht im Framework enthalten waren. Manchmal können Sie also eine Komponente an das anpassen, was Sie benötigen. Soweit ich verstanden habe, verwenden wir die Kartenkomponente, um ein modales Fenster zu erstellen, aber die Sache mit den modalen Fenstern ist, dass es sich nicht wirklich wie eine Karte verhält.

Stephanie: Du gehst ein bisschen darüber hinaus. Sie benötigen einen Hintergrund mit Verdunkelung. Sie müssen es per Klick auslösen, während sich Ihre Karte normalerweise bereits in der Benutzeroberfläche befindet. Wir verwenden diese Kartenkomponente, weil sie viele Dinge enthält, die wir brauchen, wie den Hintergrund, eine Kopfzeile und einen Titel oben und einige Schaltflächen unten. Wir haben also die Struktur und passen sie dann ein wenig an. Aber wir enden manchmal mit einigen Konflikten über Semantik, auch über HTML. Weil ich zum Beispiel Schaltflächen haben wollte, die keine Schaltflächenformen hatten, also wie eine Link-Schaltfläche, und der Entwickler sagte: „Okay, also verwenden wir einen Link wie Ihren Href-Link.“ Ich sagte: „Nein, das ist kein Link. Es ist ein Knopf. Wenn sie darauf klicken, wird keine neue Seite geöffnet. Es löscht alles, was in der Form ist.“

Stephanie: Also technisch sollte es semantisch gesehen ein Button sein. "Ja. Aber es existiert nicht im Framework.“ Ich sage: „Also okay, ich weiß, also was machen wir?“ Normalerweise fängt man also an, über diese kleinen Dinge zu diskutieren, und da ich meine Entwickler auch mit Barrierefreiheit wirklich ärgere, ist dies eine weitere zusätzliche Ebene, um sicherzustellen, dass wir die grundlegenden Komponenten haben, mit denen sie gut funktionieren. Aber auch, dass sie semantisch so sind, als ob ich keine Schaltflächen mit Gifs in Gifs in Gifs haben möchte. Sonst bekommen wir am Ende Probleme.

Drew: Ich denke, wenn Sie ein neues Projekt starten, das ein UI-Framework verwendet, müssen Sie wahrscheinlich mit einer Art Benutzerforschung beginnen.

Stéphanie: Ja.

Drew: Ist das fair?

Stéphanie: Das solltest du. Du musst. Also ja, normalerweise können Sie alle Komponenten haben, die Sie wollen. Sie müssen immer noch wissen, was Ihre Benutzer auf den Seiten brauchen, wie sie navigieren werden? Sie müssen einen Fluss aufbauen. Also gehen wir normalerweise, noch bevor wir uns für ein Framework entscheiden, zu unseren Benutzern, wir sprechen mit ihnen, wir versuchen, ihre Bedürfnisse zu verstehen. Im Moment habe ich also ziemliches Glück, weil die Benutzer intern innerhalb der Bank sind. Wir machen also viele Workshops mit ihnen und Sie müssen sich vorstellen, dass es eine super komplexe Schnittstelle ist. Wir migrieren von etwas, das vor 10 oder sogar 15 Jahren gebaut wurde, ich weiß nicht, ich glaube, zu etwas ganz Neuem, glänzendem mit Material-UI React. Es ist also eine ziemlich große Veränderung und man muss verstehen, dass in diesen 15 Jahren jeder, der etwas wollte, zum Support gehen konnte und dann das IT-Team bat, es umzusetzen. Im Moment besteht meine Schnittstelle also aus 400 Seiten mit Tabellen, innerhalb von Tabellen, innerhalb von Tabellen, mit anderen Tabellen und Sachen, die nicht einmal in Tabellen sein sollten.

Stephanie: Als hätten wir viele Dinge, die nur Schlüsselwert, Schlüsselwert, Schlüsselwert sind. Also bauen sie die Tabelle mit zwei Spalten auf. Ich sage: „Nein, vielleicht können wir damit etwas besser machen.“ Im Moment führen wir also einige Benutzerstudien durch, um die unterschiedlichen Ziele der Benutzer zu verstehen. Was wir also festgestellt haben, ist, dass sie bei dem, was sie mit der Schnittstelle machen, einige Planungsziele haben. Sie müssen ihre Arbeit planen. Also möchte ich wissen, dass diese Operation zu diesem Meeting geht, also brauche ich das in diesem Zeitplan, solche Sachen. Sie wollen etwas überwachen, sie wollen die Daten melden. Überwachung ist also genauso, wie sich die Daten anzusehen und sicherzustellen, dass alles in Ordnung ist. Reporting ist in der Lage, die Daten zu nutzen, etwas damit zu tun, das sie teilen möchten, und irgendwie mit Kollegen zusammenzuarbeiten, und all das haben wir entdeckt, indem wir direkt mit den Benutzern diskutiert haben.

Stephanie: Und was wir entdeckt haben, ist, dass einige der Dinge, die wir am Ende migrieren wollten, tatsächlich einige der wichtigsten Dinge auf täglicher Basis für den Benutzer sind. Das Benutzerziel der Planifizierung ist derzeit eines der größten. Daran arbeiten wir wirklich, wirklich. Also ja, wir nutzen das Interview und jetzt sind wir in der Phase, in der wir im Moment auf superhohem Niveau sagen, okay, wir müssen die Hülle bauen, wir müssen die Navigation verstehen. Aber im Moment sind wir noch nicht wirklich alle Daten durchgegangen und das werden wir jetzt tun. Und es ist interessant, weil wir viele Tabellen haben und wir sagten, wir können entweder den etwas nicht schlauen Weg gehen und die Tabellen einfach in die neue Oberfläche einfügen und wir sind fertig, oder wir können sagen, okay, versuchen wir zu verstehen, was Diese Tabellen sind: Wofür verwenden unsere Benutzer diese Tabelle?

Stephanie: Und dann könnten vielleicht einige der Tabellen als Datenvisualisierung angezeigt werden, und dazu muss man das ganze Geschäft verstehen, damit die Daten Sinn machen. Also, wenn Sie ein nettes Framework haben und sagen, okay, lass uns dieses Diagramm verwenden … Ich denke, es heißt Diagramm JS-Framework. Sie haben viele Dinge, Sie können Histogramme, Tortendiagramme und Grafiken und alles haben, aber irgendwann brauchen Sie immer noch einen Designer, der Ihnen bei der Entscheidung hilft. Okay, diese Daten, macht es Sinn, wenn wir sie in einem Diagramm darstellen, oder ist es sinnvoller, sie als Kuchen darzustellen, weil wir einen Teil des Ganzen zeigen wollen, oder wir wollen die Entwicklung für ein Land in den letzten 10 vergleichen? Jahre, dann ist ein Histogramm interessanter. Je nachdem, was der Benutzer mit den Daten machen möchte, werden Sie sie also auf eine ganz andere Weise anzeigen.

Stephanie: Und normalerweise ist es kein Entwicklerjob, das zu tun. Unsere Entwickler, sie sind superschlau. Es tut mir leid, aber ich arbeite ehrlich mit männlichen Entwicklern, ich wünschte, ich hätte ein paar Damen, aber nein. Keine von ihnen sind Frauen. Also super schlaue Jungs, aber sie sind nicht super qualifiziert zu sagen, okay, diese Daten sollten so, so, so und so angezeigt werden. Am Ende müssen also noch einige Designer mit den Benutzern sprechen, verstehen, was man mit den Daten machen kann, und das geht weit darüber hinaus, nur zu sagen, okay, das sollte eine Tab-Leiste sein oder dies sollte eine Navigation auf der linken Seite sein.

Drew: Und nachdem wir diese Art von Entscheidungen auf der Grundlage von Gesprächen mit den Benutzern getroffen haben. Würden Sie die resultierenden Prototypen oder Designs normalerweise zu den Benutzern zurückbringen, um sie erneut zu testen, um zu sehen, ob sie beispielsweise Ihre Art der Diagrammauswahl verstehen?

Stephanie: Ja, das haben wir tatsächlich oft gemacht, was wirklich schön ist, denn dann entwickelt man nichts, bis man weiß, dass es nützlich und brauchbar sein wird. Es kommt also darauf an. Wenn es schneller geht, das Ding tatsächlich zu entwickeln, weil sie bereits die meisten Komponenten haben, mache ich normalerweise ein wirklich schnelles Papier-Prototyping und dann entwickeln wir das Ding, weil es schnell ist, auch ohne die Daten. Wenn es etwas Komplexes ist, etwas wirklich, wirklich Neues, dessen Entwicklung viel Zeit in Anspruch nehmen wird, dann sagen wir, okay, wir entwerfen ein paar Bildschirme und testen direkt auf dem Bildschirm. Wir haben also ein Tool namens InVision, in das Sie im Grunde Ihr gesamtes Design einfügen und Verknüpfungen zwischen den verschiedenen Teilen erstellen können. Die Sache ist, es hängt auch davon ab, was Sie testen möchten. Wenn Sie beispielsweise Telefone testen möchten, ist es ein Albtraum, diese in InVision zu testen, da die Leute sie nicht wirklich fühlen können, insbesondere beispielsweise auf Mobiltelefonen.

Stephanie: Also ist es immer irgendwie schlau zu sein. Was ist der schnellste und billigste Weg? Ist es schneller und billiger, nur Designs zu testen? Ist das genug? Für Formulare normalerweise nicht wirklich, weil Sie all das schwere Heben, das Sie in das Frontend gesteckt haben, automatisch vervollständigen, das den Benutzer tatsächlich ein Formular ausfüllen lässt. Für Formulare ist es also möglicherweise effizienter, ein Formular tatsächlich zu erstellen und zu testen. Aber für neue Dinge, ja, wir machen viele Designs. Wir gehen zu den Nutzern. Im Moment machen wir also entweder Einzelgespräche, aber meine Benutzer sind wirklich vielbeschäftigte Leute. Es ist eine europäische Investmentbank, also haben sie nicht so viel Zeit. Was wir also normalerweise tun, ist, dass wir, wenn wir mit den Benutzern zu einem Einzelgespräch kommen, einige kleine Meetings abhalten, eher wie Fokusgruppen. Und es ist auch interessant, weil man dann manchmal eine Art Konfrontation hat. Einige Leute sagen: „Ja, ich denke, es funktioniert für mich, weil ich so und so arbeite“, und dann gibt es andere Leute, die sagen: „Oh, du arbeitest so? Eigentlich nein, ich mache es so und so.“

Stephanie: Es ist also auch interessant, ein paar Leute im Raum zu haben und einfach dem Gespräch zuzuhören, sich Notizen zu machen und zu sagen: „Oh, vielleicht könnten wir das dann machen“ und „Diese Komponente wäre besser, basierend auf dem, was ich gerade mache gehört." Und solche Sachen.

Drew: Wenn Sie mit einem allgemeineren Publikum für Ihr Produkt arbeiten. Gibt es also vielleicht nicht interne Benutzer wie Sie, sondern eher die allgemeine Öffentlichkeit, gibt es kostengünstige Möglichkeiten, wie Designer diese Forschung nutzen können? Gibt es einfachere Möglichkeiten, wenn Sie nicht direkt wissen, wer Ihre Benutzer sein werden?

Stephanie: Sie sollten wissen, wer sie sein werden, sonst erledigt es die Arbeit der Marketingleute, bevor das Produkt entwickelt wird. Aber ja, wir haben zum Beispiel einige Guerilla-Benutzertests durchgeführt. Sie können zum Beispiel immer noch InVision verwenden. Sie können also einige Prototypen in InVision bauen und dann die Benutzer zum Beispiel über soziale Medien rekrutieren. Ich habe für ein Produkt gearbeitet, das geholfen hat, wie heißt es, Autohausmechanikern, die Dinge reparieren und den Kunden dann auch über zusätzliche Reparaturen und solche Dinge zu informieren. Wir hatten also bereits eine Art wachsende Community auf LinkedIn und Facebook. Was Sie also tun können, ist, diese Leute zu rekrutieren. Sie können Ferntests durchführen, als würden wir uns in einem Tool wie einem Online-Tool unterhalten. Sie können eine Bildschirmfreigabe durchführen. Also haben wir das auch für ein Projekt gemacht.

Stephanie: Ich würde dir nur einen Rat geben, teste das Tool vorher, weil ich es benutzt habe, es hießerscheinung.in. Aber ich denke, sie haben den Namen in Whereby oder so geändert, aber es ist wirklich im Browser, von dem ich gesagt habe, okay, es ist nett, weil die Benutzer dann nichts installieren müssen, aber Benutzer waren nicht auf einem echten Computer. Sie waren in VM, in Citrix und sie hatten keine Mikrofone, also haben wir am Ende so getan, als hätten sie mein Tool verwendet, um den Bildschirm freizugeben. Sie klickten auf den Prototypen und gleichzeitig hatte ich sie über das Telefon, wie ein Festnetztelefon, um direkt mit ihnen zu sprechen. Es war also immer so, das war ziemlich billig, weil es ein wunderbarer Tag der Rekrutierung war, ich glaube, wir hatten 10 Benutzer oder so. Ja, Sie können eine Menge Dinge tun, auch wenn Sie sich nicht von Angesicht zu Angesicht treffen können. Ich habe viele Usability-Tests direkt über Skype oder ähnliches durchgeführt. Es gibt also immer einige billige Möglichkeiten, dies zu tun.

Drew: Wenn es darum geht, ein UI-Framework auszuwählen, mit dem Sie arbeiten möchten, ist das etwas, das Sie nur den Entwicklern überlassen würden, oder sollten Designer sich auch daran beteiligen?

Stephanie: Für mich sollte man das ganze Team einbeziehen. Wie die Designer, die Entwickler, vielleicht auch Architekten, wenn Sie welche haben, denn wie das Framework aufgebaut ist, kann diese Art von Dingen ebenfalls beeinflussen. Leider steht der Rahmen meist schon fest, wenn sie zum Projekt kommen. Nein, eigentlich ist es lustig, entweder ist es bereits entschieden oder sie bitten mich, ihre Wahl des Frameworks zu validieren, aber ich habe keine Überprüfungen oder Nachforschungen angestellt. Ich habe absolut keine Ahnung, was in dem Projekt steckt, weil sie mir nicht einmal ihre Bildschirme gezeigt haben. Sie sagen: „Ja, mach dein Ding. Diesen Rahmen können wir nutzen.“ Ich weiß nicht. Nun, haben wir einen Bildschirm? Am Ende zeigten sie Ihnen ein paar Bildschirme, bei denen es sich um eine native Windows-App handelte, die sie in die Cloud migrieren wollten. Sie sagten: „Ja, wir brauchen nur die Knöpfe und mögen meistens Formulare und solche Sachen.“

Stephanie: Aber es ist wirklich schwer zu sagen: „Ja, entscheiden Sie sich für dieses Framework, wir haben alle Komponenten, die wir brauchen.“ Oder wie: „Gehen Sie nicht, wenn Sie keine ungefähre Vorstellung davon haben, was Ihre Inhalte sein werden, wie die Navigation ist.“ Daher denke ich, dass Sie immer noch einen globalen Überblick haben sollten, bevor Sie Ihre Frameworks auswählen, es sei denn, Sie sind sich zu 100% sicher, dass Sie alle Komponenten haben. Aber ich habe das Gefühl, dass die Wahl des Frameworks meistens darauf basiert, welche Technologien die Entwickler im Moment mögen, haben sie vorher Erfahrung mit einem Framework? Wir haben Ant bei einigen Projekten verwendet, nur weil einige Entwickler damit Erfahrung hatten und es ihnen wirklich gefiel und sie mit Ant ziemlich effizient waren. Und für die Benutzeroberfläche von Material React ist es dasselbe. Es ist so, weil der Entwickler es bereits in früheren Projekten verwendet hat, also sind sie damit effizient.

Drew: Es muss also wirklich ein Gleichgewicht zwischen dem sein, womit die Entwickler vertraut sind, was sie wissen, was mit ihrem Technologie-Stack funktionieren wird und was die Anforderungen an das Produkt in Bezug auf die Erstellung einer guten Benutzeroberfläche sind. Und man muss die beiden irgendwie ausbalancieren, um den idealen Rahmen dafür zu finden.

Stéphanie: Ja. Ich habe eine Art spezifische Anforderung für ein Projekt, und zwar … Ich bin in Luxemburg, wir haben viele europäische Institutionen und solche Dinge, also haben wir für einige davon eine zusätzliche Barrierefreiheitsanforderung. Und wenn der Rahmen beschlossen wurde, haben sie normalerweise nicht wirklich die Zugänglichkeit ihres Rahmens überprüft und dann kommen sie ein paar Monate nach Beginn des Projekts zurück und sagen: „Oh, sie haben uns gerade gesagt, dass es dieses neue Gesetz gibt und wir sollten zugänglich sein, aber wir wissen nicht, wie das geht.“ Wie ja, es ist ein bisschen zu spät. Um also ein Framework auszuwählen, müssen Sie zu Beginn des Projekts wirklich alle Einschränkungen kennen, und wenn die Zugänglichkeit eine davon ist, müssen Sie Ihre Komponenten testen und sicherstellen, dass sie zugänglich sind. Aber ich bin kein React- oder Angular-Entwickler, aber ich bin mir ziemlich sicher, dass es super komplex ist, ein nicht zugängliches UI-Framework in etwas Zugängliches zu verwandeln. Ich denke, es könnte ein bisschen kompliziert sein, alle Komponenten neu zu erstellen, also solche Sachen.

Drew: Wenn Sie an einem Projekt arbeiten, in dem dieser Prozess noch nicht stattgefunden hat und bereits ein UI-Framework ausgewählt wurde, besteht die Gefahr, dass die Benutzeroberfläche von den Komponenten beeinflusst wird, die bereits in diesem Framework vorhanden sind, anstatt von den Bedürfnissen des Benutzers getrieben?

Stephanie: Ehrlich gesagt, bei den meisten Projekten, an denen ich gearbeitet habe, muss man am Ende viele Kompromisse eingehen, selbst wenn man wirklich versucht, Druck auszuüben. Es geht also hauptsächlich um Balance und Diskussionen mit den Entwicklern. Normalerweise mache ich also ein paar Wireframes, sogar schnelle Papierdrahtframes. Okay, auf dieser Seite brauchen wir diese und jene Komponente. Das erste, was ich tue, ist, den Entwickler zu fragen, ob wir das in unserem haben Rahmen im Moment? Wie sieht es aus? Und dann entscheiden wir gemeinsam, okay, das ist eine Komponente, die den Job machen würde, oder okay, das wird den Job nicht machen. Passen wir es an? Behalten wir die Komponente immer noch, ändern sie aber ein wenig, damit sie funktioniert, oder bauen wir etwas von Grund auf neu?

Stephanie: Und am Ende des Tages hängt es natürlich vom Budget ab. Also hast du am Ende Kompromisse gemacht. Als ob ich für kleine Komponenten in Ordnung wäre, die fast nie verwendet werden, wenn sie nicht perfekt sind und es ein paar Probleme gibt. Aber für die Hauptnavigation, die Hauptstruktur, Dinge, die Sie zum Beispiel ständig auf dem Bildschirm sehen, muss das wirklich funktionieren. Die Benutzer müssen verstehen, wie sie effizient arbeiten, und ja, es geht, wie Sie sagten, darum, ein Gleichgewicht zwischen der idealen Erfahrung zu finden, die Sie sich wünschen, wenn Sie kein Framework hätten, und dem, was Sie zur Hand haben, und dem Budget und auch dem zeitliche Koordinierung. Wenn wir sagen, okay, für diese Sprints muss das Feature am Ende dieses Sprints fertig sein, und dann sagen sie, okay, aber wenn Sie Ihre Komponenten wollen, werden wir das Feature niemals am Ende dieses Sprints fertigstellen, dann Sie Beginnen Sie zu diskutieren, okay, beenden wir diese Funktion im nächsten Bildschirm, nehmen wir uns mehr Zeit, um es richtig zu machen? Und normalerweise kommt es wirklich darauf an.

Stephanie: Was mich am meisten frustriert, ist, wenn ich weiß, dass wir eine Crop-Fix-Komponente verwenden und sie zu mir sagen: Oh nein, mach dir keine Sorgen. Wir werden das später beheben. Und ich wusste, dass das spätere leider nie passieren würde. Kommt also auf das Team an. Aber nach einer Weile hat man die Erfahrung und weiß, kommt das später und oder nicht? Ja, es geht um Kompromisse. Wenn Sie mit solchen Tools arbeiten.

Drew: Als Entwickler gefällt mir an UI-Frameworks unter anderem, dass sie oft mit Standardstilen ausgestattet sind. Das bedeutet also, dass ich nicht unbedingt einen Designer haben muss, der mir vielleicht beim Look and Feel aller Komponenten hilft. Ist das etwas, worauf wir uns in Projekten verlassen sollten? Nur das Standard-Styling und darauf vertrauen, dass derjenige, der das Framework erstellt hat, beim Design dieser Komponenten wirklich gute Arbeit geleistet hat? Oder würden Sie diese Komponenten selbst stylen?

Stephanie: Ich denke, es kommt wirklich darauf an. Das Problem zum Beispiel mit Material-UI ist, dass das Erscheinungsbild Ihrer Web-App im Wesentlichen die konfigurierten Google-Produkte sind. Wenn Sie also nicht wirklich die Schriftart ändern, ein paar Farben ändern und Ihre eigene Markenidentität einbringen und das tun, haben Sie ein Produkt, das einfach wie jedes Google-Produkt aussieht, was eine gute Sache sein könnte, denn wenn Ihre Nutzer an Google-Produkte gewöhnt sind, könnte es ihnen helfen, sie zu verstehen. Wenn Sie also normalerweise keinen Designer im Team haben, haben Sie dann eine Wahl? Wie viele andere Arbeiten, die ich gesehen habe, werden sie mit benutzerdefinierten Themen geliefert, sodass Sie zumindest die Farben ändern können. Ich denke, Sie können die Schriftarten auch ziemlich einfach ändern. Aber noch einmal, wenn Sie die Farben ändern und nicht besonders gut im Design oder sogar in der Zugänglichkeit sind, werden die Farben, die Sie verwenden, möglicherweise kollidieren, sie könnten Kontrastprobleme haben.

Stephanie: Zum Beispiel liebe ich Orange, aber es ist eine der lästigsten Farben, mit der man arbeiten kann, weil ein wirklich zugängliches Orange, zum Beispiel als Schaltfläche mit weißem Text, fast bräunlich aussieht. Und wenn Sie dieses wirklich glänzende Orange haben möchten, brauchen Sie einen dunklen Text darüber, damit es lesbar ist, aber es lässt Ihre Benutzeroberfläche am Ende des Tages irgendwie wie Halloween aussehen. Ja, ich sehe dich lachen. Aber es ist wahr. Es geht also immer um diese Art von Kompromissen und wenn Sie sagen, wenn Sie ein Entwickler sind und das Framework so verwenden möchten, wie es ist, und Sie keinen Designer haben, denke ich, dass es immer noch besser ist, als nichts zu haben und es von Grund auf neu zu erstellen und dann ist es super komplex zu bedienen. Aber die Sache ist die, nur weil Sie die Komponenten haben, heißt das nicht, dass Sie eine großartige Schnittstelle bauen werden. Es ist wie Legosteine. Wenn Sie die Legosteine ​​haben, okay, das ist in Ordnung, aber Sie können ein wirklich schönes Raumschiff bauen oder Sie können etwas tun, das nicht zusammenhält und auseinanderfällt, weil Sie keinen wirklichen Plan hatten.

Stephanie: Design ist also mehr als das. Beim Design geht es darum, wirklich zu verstehen, was auf dem Bildschirm erscheinen wird, wie es funktionieren wird. Und ich kenne einige Entwickler, die tatsächlich die Fähigkeit dazu haben. Sie kennen sich also sehr gut mit Usability-Richtlinien aus und verstehen zum Beispiel viele Designregeln. Wenn es also um die Auswahl der Komponenten geht, sind sie wirklich gut darin. Und ich kenne Entwickler, die keine Ahnung haben, welche Komponenten sie wählen sollen, und sich für die erste entscheiden, die den Job macht. Aber nach einer Weile geht es nicht mehr. Wie zum Beispiel Tabs hatten wir eine Schnittstelle, bei der einige Entwickler Tabs auswählten. Ich denke, es macht am Anfang Sinn, wenn man nur drei Items hat. Aber dann gab es 12 Elemente auf dem Bildschirm und dann haben Sie die Registerkarten, die drei Zeilen von Registerkarten sind, und alle diese Registerkarten sind die gleichen Registerkarten der Ebene eins, und es gibt Registerkarten innerhalb von Registerkarten. Sie hatten also die Komponente, sie sah gut aus, weil sie das Framework verwenden, aber sie war nicht wirklich brauchbar.

Stephanie: Und ich hatte zum Beispiel dasselbe mit einem modalen Fenster. Wo sie die Projekte ohne einen Designer erstellen und nach einer Weile, glaube ich, hat der Kunde nach mehr und mehr Sachen für dieses Modal gefragt. Sie hatten also einen Bildschirm mit einer Tabelle und wenn Sie auf Zeile hinzufügen klicken, öffnen Sie ein Modal, und in diesem Modal haben Sie zwei Registerkarten, und dann haben Sie in einer dieser Registerkarten sogar eine weitere Tabelle, und dann wollten sie füge ein zusätzliches Zeug hinzu, ich dachte, okay, vielleicht können wir ein Modal auf ein Modal setzen. Und irgendwann würde der Designer antworten, okay, wenn Sie so viel Inhalt im Modal haben, sollte es kein modales Fenster sein. Es sollte eine Seite sein. Selbst wenn Sie die Komponente haben, brauchen Sie immer noch eine Art Architekt, der den Plan erstellt und sicherstellt, dass alle diese Komponenten gut zusammenarbeiten.

Drew: Wenn Sie also als Designer gebeten werden, das Styling einiger Komponenten zu ändern, würden Sie dann einfach versuchen, das gesamte Styling zu ändern? Würden Sie alles anpassen oder gibt es bestimmte Bereiche, auf die Sie sich konzentrieren würden?

Stephanie: Ich denke, weil Farben das erste sind, was Sie sehen, können Farben Ihnen tatsächlich Identität verleihen. Wenn Sie eine starke Markenidentität haben, hilft es Ihnen bereits, das Framework anzupassen, wenn Sie zumindest die Farben Ihres Produkts auf den Schaltflächen oder den Symbolen und dergleichen haben. Schriftarten, weil ich denke, dass es einfach ist, wenn das Framework gut gebaut ist, ändert man normalerweise die gesamte Schriftartenfamilie an einer Stelle und dann sollte es auf den Rest der Website kaskadieren. Farben und Schriftarten sind also meiner Meinung nach zwei einfache Möglichkeiten, um das Framework schnell anzupassen. Symbole sind eine weitere nette Möglichkeit, Persönlichkeit zu verleihen, aber es könnte schwierig sein, da die meisten Frameworks nach dem, was ich gesehen habe, mit benutzerdefinierten Symbolen oder Font Awesome oder einer bereits integrierten Bibliothek geliefert werden viele Symbole, wenn Sie sie alle ersetzen möchten. Es könnte also etwas komplex sein. Ich habe auch Frameworks gesehen, mit denen Sie auswählen können, welches Symbolpaket Sie verwenden möchten. wie Font Awesome, Glyphicons und einige andere. Das ist also die Art von Dingen, die Sie ganz einfach anpassen können.

Stephanie: Und dann geht es um Look and Feel, zum Beispiel die Kopfzeile, normalerweise gibt es verschiedene Arten von Kopf- und Fußzeilen. Wie navigiert man so etwas. Es gibt also bereits viele kleine Anpassungen, die Sie vornehmen können, damit es nicht nach Material-UI aussieht, sondern eher wie Ihre Marke aussieht, und dann können Sie beispielsweise mit den Randradien herumspielen. Egal, ob Sie vollständig abgerundete Schaltflächen oder quadratische Schaltflächen oder etwas in der Mitte wie Schatten wünschen. Also ein paar kleine Dinge, die normalerweise einfach anzupassen sind, weil die meisten dieser Frameworks sie in CSS-Variablen haben. Dies sind die kleinen Dinge, die Sie ohne großen Aufwand anpassen können, abgesehen von diesen Welleneffekten. Ich hasse es, dass. Ich werde dagegen ankämpfen. Ich hoffe irgendwie, dass sie es irgendwann ändern.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. Do you know?

Drew: Yup.

Stephanie: It does. In Ordnung. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.