Smashing Podcast Épisode 9 Avec Stephanie Walter : Comment puis-je travailler avec des frameworks d'interface utilisateur ?

En tant que développeur moi-même, l'une des choses que j'aime dans les frameworks d'interface utilisateur est qu'ils sont souvent livrés avec un style par défaut, mais est-ce quelque chose sur lequel nous devrions nous appuyer dans les projets ? Utiliser simplement le style par défaut et croire que celui qui a produit le framework a fait un très bon travail dans la conception de ces composants ? Rejoignez-moi pour l'épisode de podcast d'aujourd'hui où je parle à la designer UX Stephanie Walter des choses que nous devrions prendre en compte lors de la construction d'un cadre d'interface utilisateur.

Afficher les remarques

• Le site de Stéphanie
• Stéphanie sur Twitter

Mise à jour hebdomadaire

• "Comment créer un jeu de correspondance de cartes en utilisant Angular et RxJS" par Anna Prenzel
• "Comment créer un site WordPress sans tête sur le JAMstack" par Sarah Drasner
• "Magic Flip Cards: Résoudre un problème de dimensionnement courant" par Dan Halliday
• "Django Highlights : Modèles d'utilisateurs et authentification (Partie 1)" par Philip Kiely
• "Comment créer des cartes avec React et Leaflet" par Shajia Abidi

Transcription

Drew McLellan : C'est une designer centrée sur l'utilisateur et une experte en expérience mobile, qui a croisé des produits et des interfaces délicieux avec un accent particulier sur la performance. Elle a travaillé sur des projets pour des clients tels que l'Université du Luxembourg, la Banque européenne d'investissement, BMW et Microsoft, pour n'en citer que quelques-uns, et elle aide ces clients à livrer des projets réussis à leur public, de la stratégie au produit final. Elle est une experte Google Developer en conception de produits et une enseignante passionnée partageant ses connaissances dans de nombreux articles de blog, articles, ateliers et présentations de conférences. Nous savons donc qu'elle est une experte en conception d'expérience utilisateur, mais saviez-vous qu'elle a déjà travaillé comme poseuse de tapis avec Sir Elton John ? Mes amis Smashing, veuillez accueillir Stephanie Walter. Bonjour Stéphanie, comment allez-vous ?

Stephanie Walter : Bonjour, je suis géniale et j'ai adoré l'introduction.

Drew : Je voulais donc vous parler aujourd'hui d'un problème particulier et c'est le sujet de l'utilisation de frameworks d'interface utilisateur prêts à l'emploi. Maintenant, vous êtes un concepteur d'expérience utilisateur et vous travaillez avec de nombreux clients différents et votre travail consiste à aider ces clients à créer les meilleures expériences utilisateur possibles en créant des interfaces utilisateur hautement utilisables. Donc, l'idée de pouvoir le faire avec un ensemble d'outils prêts à l'emploi me semble un peu exagérée. L'utilisation du framework d'interface utilisateur est-elle quelque chose que vous voyez beaucoup tout au long de votre travail ?

Stéphanie : Oui, c'est quelque chose que j'ai beaucoup vu, surtout ces dernières années parce que j'ai commencé à travailler avec une agence et maintenant je travaille au sein de l'entreprise. Donc, dans ces super grandes équipes de technologie informatique et oui, en ce moment, il y a beaucoup d'interfaces utilisateur de cadre comme celle que j'ai le plus vue est Material-UI, fondamentalement la conception matérielle est une sorte de directives de conception de Google et chose, et Matériel -UI c'est l'équipe d'Angular, mais aussi l'équipe de React. Ils ont créé leur propre cadre en utilisant un peu l'apparence de la conception matérielle de Google. Mais cela n'a plus rien à voir avec Google. C'est juste comme eux, je ne sais pas, je pense qu'ils ont aimé le look and feel. Donc, pour le moment, ce sont les deux principaux cadres d'interface utilisateur avec lesquels je travaille. Et il y a aussi quelque chose qui s'appelle Ant Design, qui est devenu très populaire.

Stéphanie : C'est un framework React. Je ne sais pas s'ils ont aussi Angular. Je pense qu'il a été fabriqué par une équipe en Chine. Et c'est intéressant parce que non seulement il fournit les composants, tout dans React, mais si vous allez sur leur site Web, vous obtiendrez également les fichiers de travail, ce qui est en fait assez intéressant car cela motive ou aide le concepteur à construire ou à façonner l'interface dans les composants d'interface utilisateur utilisés par ce framework. Alors oui, c'est quelque chose que j'ai beaucoup vu, en particulier dans les grandes équipes informatiques, car la plupart du temps, celles-ci n'ont pas de concepteur. En ce moment, je suis essentiellement l'équipe UX d'une personne dans une petite équipe d'une banque d'investissement européenne. C'est donc moi en tant que designer UX. Je travaille avec une équipe de développeurs, d'analystes commerciaux, toutes les bonnes personnes, mais c'est toujours un concepteur pour l'ensemble du projet.

Stéphanie : Jusqu'à mon arrivée, il n'y avait pas de designer. C'est donc une sorte de solution mise en place dans beaucoup d'entreprises, notamment sur des produits internes par exemple. Là où ils disent généralement, d'accord, nous n'avons pas vraiment besoin d'un designer pour cela. Nous avons juste besoin de quelque chose qui fonctionne pour nos utilisateurs internes et utilisons simplement un framework parce que c'est pratique pour les développeurs. La plupart des composants sont déjà là et comme ils n'ont pas de concepteurs dans l'équipe, cela remplace en quelque sorte le rôle d'un concepteur d'interface utilisateur. Ouais, le problème avec ça, c'est que, d'accord, alors vous avez les composants, mais le rôle du concepteur d'interface utilisateur n'est pas seulement de décider si le bouton doit être rouge, vert, orange, bleu, peu importe. Habituellement, le rôle du concepteur d'interface utilisateur est l'architecture de l'information, la compréhension des besoins des utilisateurs. Donc tout ce qui va au-delà de l'interface. Donc, même si vous avez ce genre de cadre qui prend en charge toute l'interface utilisateur, donc visuellement ce que vous voyez à l'écran.

Stéphanie : Vous avez toujours besoin de quelqu'un à un moment donné pour faire le travail de comprendre ce qu'on met à l'écran, comment va-t-il se comporter ? Que se passe-t-il lorsque nous cliquons ici ? Comment l'utilisateur atteint-il son objectif ? Comment passe-t-on du point A au point B ? Parce que nous pouvons utiliser un modèle, nous pouvons utiliser des onglets, nous pouvons utiliser tous les composants. C'est pourquoi c'est toujours un peu complexe et délicat.

Drew : Est-il possible, pensez-vous être capable de créer une interface utilisateur utilisable à l'aide d'un cadre d'interface utilisateur prêt à l'emploi, ou cela va-t-il toujours être un peu un compromis ?

Stéphanie : J'espère que oui. J'espère un peu parce que sinon je construis des interfaces non utilisables. Cette réponse est donc totalement biaisée, mais oui, je pense que oui, mais cela dépend aussi du niveau de compromis que vous êtes prêt à faire et il y a des compromis des deux côtés. Pour le moment, je compromet beaucoup de boutons par exemple, parce que vous avez des boutons vraiment spécifiques dans Material-UI, et je n'aime pas vraiment l'effet d'entraînement sur le bouton. Je pense que cela fonctionne très bien sur mobile car sur mobile, vous avez besoin d'une sorte de gros retour lorsque l'utilisateur clique ou touche le bouton. Mais ensuite, les étapes sont une sorte d'effet d'entraînement qui va jusqu'au bout sur le bouton. C'est un peu exagéré, surtout quand il y a beaucoup de boutons. Mais nous allons quand même conserver cet effet d'entraînement car il serait super complexe de le supprimer car cela a été intégré au framework React. Et pour avoir un autre effet de survol sur ce bouton, quelque chose de plus subtil qui ne sera pas ce genre de chose whooshy ici. Ce serait hyper complexe.

Stéphanie : C'est donc le genre de compromis que vous faites. Mais en attendant, je ne fais aucun compromis sur des choses spécifiques qui sont des composants personnalisés. Là où je travaillais auparavant, client actuel d'une compagnie aérienne et de voyages. Et la compagnie aérienne a des besoins vraiment très spécifiques. Le calendrier de la compagnie aérienne par exemple, vous voulez mettre des prix, vous voulez mettre… si vous ne voyagez pas vers cette destination à une date précise, vous ne savez pas quand mettre ça, vous avez ce départ et cette arrivée et le calendrier de base de la plupart de ces frameworks d'interface utilisateur ne fournit pas ce genre de choses. Donc, à un moment donné, vous pouvez dire, d'accord, nous allons simplement utiliser le calendrier qu'ils ont. Et c'est tout. Vous devez aller au-delà de cela. Donc, la plupart des compromis sont essentiellement basés sur, utilisons-nous le composant de base ? Créons-nous un modèle personnalisé qui répondra aux besoins de l'utilisateur ? Ou fait-on un mix des deux ? Dans le cas du calendrier, par exemple, nous utilisons la grille du calendrier, nous utilisons donc le composant de base, puis nous l'avons amélioré avec une personnalisation en plus de cela. Il y a donc eu beaucoup de développement React pour celui-là.

Stéphanie : Et ouais, donc généralement tu fais beaucoup de compromis.

Drew : Il semble donc que l'utilisation d'un cadre d'interface utilisateur peut vous permettre d'atteindre un certain niveau, mais pour vraiment avoir une bonne interface utilisateur, vous devez faire un peu de personnalisation en plus ?

Stéphanie : Généralement. Ouais.

Drew : Cette personnalisation va-t-elle au-delà de la thématisation ?

Stéphanie : Oui, mon développeur souhaitait que cela n'aille pas au-delà de la thématisation. Eugène Si vous m'écoutez. Je pense qu'il serait super content si on changeait juste quelques couleurs sur tout. Mais oui, à un moment donné, vous devez aller au-delà de la personnalisation, car d'abord, comme les cadres d'interface utilisateur sont comme les outils Lego, c'est une sorte de boîte à outils. Vous avez donc beaucoup de composants différents dans la boîte, mais cela ne crée pas de page. Vous avez toujours besoin d'un en-tête, vous avez toujours besoin d'un pied de page. Vous avez toujours besoin de contenu supplémentaire qui n'était pas dans le cadre. Donc, parfois, vous pouvez modifier un composant en fonction de vos besoins. D'après ce que j'ai compris, nous utilisons le composant carte pour construire une fenêtre modale, mais le problème avec les fenêtres modales, c'est qu'elles ne se comportent pas vraiment comme une carte.

Stéphanie : Vous allez un peu au-delà de ça. Vous avez besoin d'un arrière-plan avec obscurcissement. Vous devez le déclencher au clic alors que généralement votre carte est déjà là dans l'interface. Nous utilisons donc ce composant de carte car il a beaucoup de choses dont nous avons besoin comme l'arrière-plan, un en-tête et un titre en haut, quelques boutons en bas. Nous avons donc la structure, puis nous la modifions un peu. Mais nous nous retrouvons parfois avec des conflits de sémantique, HTML également. Parce que, par exemple, je voulais avoir des boutons qui n'avaient pas de forme de bouton, donc tout comme le bouton de lien et le développeur a dit: "D'accord, nous utilisons donc un lien comme votre lien href." J'ai dit : « Non, ce n'est pas un lien. C'est un bouton. Lorsqu'ils cliquent dessus, cela n'ouvre pas une nouvelle page. Cela efface tout ce qui est dans le formulaire.

Stéphanie : Donc ça devrait être techniquement d'un point de vue sémantique, ça devrait être un bouton. "Ouais. Mais cela n'existe pas dans le cadre. Je dis "Alors d'accord, je sais alors qu'est-ce qu'on fait?" Donc, généralement, vous commencez à discuter de ces petites choses et comme j'ennuie vraiment mes développeurs avec l'accessibilité aussi, c'est une autre couche supplémentaire pour essayer de s'assurer que nous avons les composants de base avec lesquels ils fonctionnent bien. Mais aussi qu'ils sont sémantiquement comme je ne veux pas avoir de boutons avec des gifs dans des gifs dans des gifs. Sinon, nous aurons des problèmes à la fin.

Drew : Je suppose que pour démarrer un nouveau projet qui va utiliser un framework d'interface utilisateur, vous devez probablement commencer par une sorte de recherche d'utilisateurs.

Stéphanie : Oui.

Drew : Est-ce juste ?

Stéphanie : Tu devrais. Tu dois. Alors oui, généralement vous pouvez avoir tous les composants que vous voulez. Encore faut-il savoir de quoi vos utilisateurs ont besoin sur les pages, comment vont-ils naviguer ? Vous devez créer un flux. Donc généralement avant même de décider d'un framework, nous allons voir nos utilisateurs, nous leur parlons, nous essayons de comprendre leurs besoins. Donc pour le moment j'ai pas mal de chance car les utilisateurs sont en interne au sein de la banque. Nous faisons donc beaucoup d'ateliers avec eux et il faut imaginer que c'est une interface super complexe. Nous migrons de quelque chose qui a été construit, je ne sais pas, je pense il y a 10 ou même 15 ans vers quelque chose de tout nouveau brillant en utilisant Material-UI React. C'est donc un changement assez important et il faut comprendre que durant ces 15 années, tous ceux qui voulaient quelque chose pouvaient aller au support et demander ensuite à l'équipe informatique de le mettre en place. Donc, pour le moment, mon interface est comme 400 pages avec des tableaux, dans des tableaux, dans des tableaux, avec d'autres tableaux, et des choses qui ne devraient même pas être dans des tableaux.

Stéphanie : Comme nous avons beaucoup de choses qui ne sont que des valeurs clés, des valeurs clés, des valeurs clés. Ils construisent donc le tableau à deux colonnes. Je me dis: "Non, peut-être que nous pouvons faire quelque chose de mieux avec ça." Donc, pour le moment, nous avons fait des recherches sur les utilisateurs pour comprendre les différents objectifs des utilisateurs. Donc, ce que nous avons identifié, c'est que ce qu'ils font avec l'interface, ils ont des objectifs de planification. Ils doivent planifier leur travail. Donc je veux savoir que cette opération va aller à cette réunion, donc j'ai besoin de ça sur ce calendrier, des trucs comme ça. Ils veulent surveiller quelque chose, ils veulent rapporter les données. La surveillance revient donc à examiner les données et à s'assurer que tout va bien. Le reporting, c'est être capable d'exploiter les données, d'en faire quelque chose qu'ils veulent partager et de collaborer en quelque sorte avec des collègues et tout cela, nous l'avons découvert en discutant directement avec les utilisateurs.

Stephanie : Et ce que nous avons découvert, c'est qu'en fait, certaines des choses que nous prévoyions de migrer à la fin sont parmi les choses les plus importantes au quotidien pour l'utilisateur. Ainsi, l'objectif de l'utilisateur de planification est l'un des plus importants en ce moment. Nous travaillons donc vraiment, vraiment là-dessus. Alors oui, nous utilisons l'interview et maintenant nous sommes dans la phase où, pour le moment, nous sommes de très haut niveau en disant d'accord, nous devons construire le shell, nous devons comprendre la navigation. Mais pour le moment, nous n'avons pas vraiment examiné toutes les données et c'est maintenant ce que nous allons faire. Et c'est intéressant parce que nous avons beaucoup de tables et nous avons dit que nous pouvions soit suivre la voie peu intelligente et simplement mettre les tables dans la nouvelle interface et nous avons terminé, soit nous pouvons dire, d'accord, essayons de comprendre ce ces tables sont, Pourquoi nos utilisateurs utilisent-ils cette table ?

Stéphanie : Et puis peut-être que certains des tableaux pourraient être affichés sous forme de visualisation de données et pour ce faire, vous devez comprendre l'ensemble de l'entreprise afin que les données aient un sens. Donc, si vous avez un bon cadre et que vous dites, d'accord, utilisons ce graphique… Je pense qu'il s'appelle le cadre graphique JS. Vous avez beaucoup de choses, vous pouvez avoir des histogrammes, des camemberts et des graphiques et tout, mais à un moment donné, vous avez toujours besoin d'un concepteur pour vous aider à décider. D'accord, ces données ont-elles un sens si nous les montrons sous forme de graphique ou s'il est plus logique de les montrer sous forme de tarte parce que nous voulons montrer une partie de l'ensemble, ou nous voulons comparer l'évolution d'un pays au cours des 10 dernières années ans, alors un histogramme est plus intéressant. Donc, en fonction de ce que l'utilisateur veut faire avec les données, vous allez les afficher d'une toute autre manière.

Stephanie : Et généralement, ce n'est pas un travail de développeur de faire cela. Notre développeur, ce sont des gars super intelligents. Je suis désolé, mais je travaille honnêtement avec des développeurs masculins, j'aimerais avoir des femmes, mais non. Aucun d'entre eux n'est une femme. Donc des gars super intelligents mais ils ne sont pas super qualifiés pour dire, d'accord, ces données devraient être affichées comme ça, ça, ça et ça. Donc, à la fin, vous avez toujours besoin que certains concepteurs parlent aux utilisateurs, comprennent ce que vous pouvez faire avec les données et cela va bien au-delà de simplement dire, d'accord, cela devrait être une barre d'onglets ou cela devrait être une navigation sur la gauche.

Drew : Et après avoir pris ce genre de décisions en discutant avec les utilisateurs. Souhaitez-vous généralement rapporter les prototypes ou les conceptions résultants aux utilisateurs pour les tester à nouveau afin de voir s'ils comprennent votre type de choix de graphique, par exemple ?

Stéphanie : Oui, nous avons beaucoup fait cela en fait, ce qui est vraiment bien, car vous ne développez pas quelque chose tant que vous ne savez pas qu'il sera utile et utilisable. Donc ça dépend. S'il est plus rapide de développer la chose parce qu'ils ont déjà la plupart des composants, ce que je fais habituellement, c'est que je fais un prototypage papier très rapide, puis nous développons la chose parce que c'est rapide, même sans les données. Si c'est quelque chose de complexe, quelque chose de vraiment, vraiment nouveau qui prendra beaucoup de temps à développer, alors nous disons, d'accord, nous concevons quelques écrans et nous faisons des tests directement sur l'écran. Nous avons donc un outil qui s'appelle InVision, où vous mettez en gros tout votre design, vous pouvez créer des liens entre les différentes parties. Le fait est que cela dépend aussi de ce que vous voulez tester. Si vous voulez tester des téléphones par exemple, c'est un cauchemar de tester ceux dans InVision car les gens ne peuvent pas vraiment les sentir et surtout sur téléphone portable par exemple.

Stéphanie : Donc, c'est toujours le genre d'être intelligent. Quel est le moyen le plus rapide et le moins cher ? Est-il plus rapide et moins cher de tester uniquement les conceptions. Est-ce assez? Pour les formulaires généralement, pas vraiment parce que vous avez complété automatiquement tout le travail lourd que vous mettez dans le front-end qui demande à l'utilisateur de remplir un formulaire, donc pour les formulaires, il est peut-être plus efficace de créer un formulaire et de le tester. Mais pour les nouveautés, oui, nous faisons beaucoup de designs. Nous allons vers les utilisateurs. Donc, pour le moment, nous faisons soit des entretiens individuels, mais mes utilisateurs sont des gens très occupés. C'est une banque d'investissement européenne, donc ils n'ont pas beaucoup de temps. Donc, ce que nous faisons habituellement, c'est que si nous venons en tête-à-tête avec les utilisateurs, nous organisons de petites réunions, comme des groupes de discussion. Et c'est aussi intéressant parce qu'il y a parfois une sorte de confrontation. Certaines personnes disent : « Ouais, je pense que ça marche pour moi parce que je travaille comme ça et ça », et puis il y aura d'autres personnes qui diront : « Oh, tu travailles comme ça ? En fait non, je fais comme ça et ça.

Stéphanie : Il est donc également intéressant d'avoir quelques personnes dans la salle et d'écouter uniquement la conversation, de prendre des notes et de dire : "Oh, peut-être que nous pourrions faire cela" et "Ce composant serait mieux basé sur ce que je viens de faire". entendu." Et des choses dans le genre.

Drew : Si vous travaillez avec un public plus général pour votre produit. Donc, peut-être pas des utilisateurs internes comme vous, mais plutôt le grand public, existe-t-il des moyens peu coûteux pour les concepteurs d'utiliser cette recherche ? Existe-t-il des moyens plus simples si vous ne savez pas directement qui seront vos utilisateurs ?

Stéphanie : Vous devriez savoir qui ils vont être sinon cela fait le travail des gens du marketing avant de construire le produit. Mais oui, nous avons fait des tests d'utilisateurs de guérilla par exemple, vous pouvez toujours utiliser InVision par exemple. Vous pouvez donc créer des prototypes dans InVision, puis recruter des utilisateurs via les réseaux sociaux, par exemple. Je travaillais pour un produit qui aidait, comment s'appelle-t-il, les mécaniciens des concessionnaires automobiles qui réparent des choses, puis informent également le client des réparations supplémentaires, des choses comme ça. Nous avions donc déjà une sorte de communauté grandissante sur LinkedIn et Facebook. Donc, ce que vous pouvez faire, c'est recruter ces personnes. Vous pouvez faire des tests à distance, comme si nous avions une conversation dans un outil comme un outil en ligne. Vous pouvez faire du partage d'écran. Nous avons donc fait cela pour certains projets également.

Stéphanie : Je voudrais juste vous donner un conseil, c'est de tester l'outil avant, car je l'utilisais, il s'appelaitappear.in. Mais je pense qu'ils ont changé le nom en Whereby ou quelque chose comme ça, mais c'est vraiment dans le navigateur que j'ai dit, d'accord, c'est bien parce qu'alors les utilisateurs n'ont pas besoin d'installer quoi que ce soit mais les utilisateurs n'étaient pas sur un vrai ordinateur. Ils étaient dans une machine virtuelle, dans un Citrix et ils n'avaient pas de microphones, donc ce que nous avons fini par faire, c'est comme s'ils utilisaient mon outil pour partager l'écran. Ils cliquaient sur le prototype et en même temps je les avais au téléphone, comme un téléphone fixe, pour leur parler directement. Donc, il y a toujours, c'était un assez bon marché parce que c'était une merveilleuse journée de recrutement, je pense que nous avions 10 utilisateurs ou quelque chose comme ça. Oui, vous pouvez faire beaucoup de choses même si vous ne pouvez pas vous retrouver face à face, j'ai fait beaucoup de tests d'utilisabilité directement sur Skype ou des choses comme ça. Il y a donc toujours des moyens peu coûteux de le faire.

Drew : Lorsqu'il s'agit de choisir un framework d'interface utilisateur avec lequel travailler, si c'est la voie que vous suivez, est-ce quelque chose que vous laisseriez aux développeurs uniquement ou est-ce quelque chose dans lequel les concepteurs devraient également s'impliquer ?

Stéphanie : Pour moi, il faut impliquer toute l'équipe. Comme les concepteurs, les développeurs, peut-être aussi les architectes si vous en avez, car la façon dont le framework est construit peut également influencer ce genre de choses. Malheureusement, la plupart du temps lorsqu'ils arrivent sur le projet, le cadre était déjà décidé. Non, en fait c'est marrant, soit c'est déjà décidé soit ils me demandent de valider leur choix de cadre, mais je n'ai fait aucune revue ni recherche. Je n'ai strictement aucune idée de ce qu'il y a dans le projet car ils ne m'ont même pas montré leurs écrans. Ils sont comme, « Ouais, fais ton truc. Nous pouvons utiliser ce cadre. Je ne sais pas. Eh bien, avons-nous un écran? Ils ont donc fini par vous montrer quelques écrans, qui étaient une application native Windows qu'ils voulaient migrer dans le cloud. Ils ont dit: "Oui, nous n'avons besoin que des boutons et surtout des formulaires et des choses comme ça."

Stephanie : Mais c'est vraiment difficile de dire : « Oui, optez pour ce cadre, nous avons tous les composants dont nous avons besoin. » Ou comme, "N'y allez pas si vous n'avez pas une idée approximative de ce que sera votre contenu, quelle est la navigation." Je pense donc que vous devriez toujours avoir une sorte d'aperçu global avant de choisir vos frameworks, sauf si vous êtes sûr à 100% d'avoir tous les composants. Mais j'ai l'impression que la plupart du temps, le choix du framework est essentiellement basé sur les technologies que les développeurs aiment en ce moment, ont-ils de l'expérience avec un framework avant cela ? Nous avons utilisé Ant sur certains projets simplement parce que quelques développeurs avaient de l'expérience avec cela et ils l'ont vraiment aimé et ils ont été assez efficaces en utilisant Ant. Et pour l'interface utilisateur de Material React, c'est la même chose. C'est comme parce que le développeur l'a déjà utilisé sur des projets précédents, donc ils sont efficaces avec ça.

Drew : Donc, il faut vraiment trouver un équilibre entre ce avec quoi les développeurs sont à l'aise, ce qu'ils savent, ce qui fonctionnera avec leur pile technologique, puis quelles sont les exigences du produit en termes de création d'une bonne interface utilisateur. Et vous devez en quelque sorte équilibrer les deux pour trouver le cadre idéal pour cela.

Stéphanie : Oui. J'ai une sorte d'exigence spécifique pour certains projets, qui est… Je suis au Luxembourg, nous avons beaucoup d'institutions européennes et des choses comme ça, donc nous avons une exigence d'accessibilité supplémentaire pour certaines d'entre elles. Et généralement, lorsque le cadre était décidé, ils ne vérifiaient pas vraiment l'accessibilité de leur cadre, puis ils revenaient quelques mois après le début du projet en disant : "Oh, je viens de nous dire qu'il y a cette nouvelle loi et nous devrions être accessible, mais nous ne savons pas comment faire cela. Comme ouais, c'est un peu trop tard. Donc pour moi, pour choisir un framework il faut vraiment connaître toutes les contraintes au début du projet et si l'accessibilité en fait partie il faut tester ses composants et s'assurer qu'ils vont être accessibles. Mais je ne suis pas un développeur React ou Angular, mais je suis à peu près sûr que c'est super complexe de transformer un framework d'interface utilisateur non accessible en quelque chose d'accessible. Je suppose qu'il pourrait être un peu complexe de reconstruire tous les composants, donc des choses comme ça.

Drew : Si vous vous retrouvez à travailler sur un projet où ce processus n'a pas eu lieu et qu'un cadre d'interface utilisateur a déjà été choisi, y a-t-il un danger que l'interface utilisateur commence à être influencée par les composants qui existent déjà dans ce cadre plutôt que être guidé par les besoins de l'utilisateur ?

Stéphanie : C'est vraiment, honnêtement, la plupart des projets sur lesquels j'ai travaillé, vous finissez par avoir beaucoup de compromis, même si vous essayez vraiment de pousser. C'est donc surtout une question d'équilibre et de discussion avec les développeurs. Donc, généralement, ce que je fais, c'est que nous faisons des wireframes, même des wireframes rapides en papier, disons d'accord, sur cette page, nous aurons besoin de cela et de cela et de ce composant, la première chose que je fais est de demander au développeur si nous avons cela dans notre cadre pour le moment ? À quoi cela ressemble-t-il? Et puis on décide ensemble, d'accord, c'est un composant qui ferait l'affaire ou d'accord ça ne fera pas l'affaire. Est-ce qu'on le peaufine ? Par exemple, gardons-nous toujours le composant mais le modifions-nous un peu pour qu'il fasse le travail, ou construisons-nous quelque chose à partir de rien ?

Stéphanie : Et en fin de compte, cela dépendra du budget bien sûr. Donc, vous avez fini par faire des compromis. Par exemple, je serais d'accord pour les petits composants qui ne sont presque jamais utilisés s'ils ne sont pas parfaits et qu'il y a peu de problèmes. Mais pour la navigation principale, la structure principale, les choses que vous voyez tout le temps à l'écran, par exemple, cela doit vraiment fonctionner. L'utilisateur a besoin de comprendre comment il fonctionne efficacement et oui, comme vous l'avez dit, il s'agit de trouver un équilibre entre l'expérience idéale que vous souhaiteriez avoir si vous n'aviez pas de cadre et ce que vous avez sous la main et le budget et aussi le Horaire. Si nous disons, d'accord, pour ces sprints, la fonctionnalité doit être terminée à la fin de ce sprint, puis ils disent, d'accord, mais si vous voulez vos composants, nous ne terminerons jamais la fonctionnalité à la fin de ce sprint alors vous commencer à discuter, d'accord, finissons-nous cette fonctionnalité dans l'écran suivant, prenons-nous plus de temps pour le faire correctement ? Et généralement, cela dépend vraiment.

Stéphanie : Les choses qui me frustrent le plus, c'est quand je sais que nous utilisons un composant crop fix et qu'ils me disent, Oh non, ne t'inquiète pas. Nous réglerons cela plus tard. Et je savais que le plus tard, malheureusement, pourrait ne jamais arriver. Cela dépend donc de l'équipe. Mais après un certain temps, vous avez l'expérience et vous savez, cela arrivera-t-il plus tard et ou non ? Ouais, c'est une question de compromis. Lorsque vous travaillez avec ce genre d'outils.

Drew : En tant que développeur moi-même, l'une des choses que j'aime dans les frameworks d'interface utilisateur, c'est qu'ils sont souvent accompagnés d'un style par défaut. Cela signifie donc que je n'ai pas nécessairement besoin d'avoir un concepteur pour m'aider avec l'aspect et la convivialité de tous les composants. Est-ce quelque chose sur lequel nous devrions compter dans les projets? Juste le style par défaut et la confiance que celui qui a produit le framework a fait un très bon travail dans la conception de ces composants ? Ou est-ce que vous coifferiez vous-même ces composants ?

Stéphanie : Je pense que ça dépend vraiment. Le problème, par exemple, avec Material-UI est que l'apparence de votre application Web sera essentiellement les produits Google configurés. Donc, si vous ne changez pas réellement la police, changez quelques couleurs et apportez en quelque sorte votre propre identité de marque et faites cela, vous aurez un produit qui ressemblera à n'importe quel produit Google, ce qui pourrait être une bonne chose parce que si vos utilisateurs sont habitués aux produits Google, cela pourrait les aider à le comprendre. Donc généralement si vous n'avez pas de designer dans l'équipe, avez-vous le choix ? Comme beaucoup de travaux différents que j'ai vus, ils viennent avec des thèmes personnalisés afin que vous puissiez au moins changer les couleurs. Je pense que vous pouvez également changer les polices assez facilement. Mais encore une fois, comme si vous changez les couleurs et que vous n'êtes pas super bon en design ou même en accessibilité, peut-être que les couleurs que vous utiliserez se heurteront, elles pourraient avoir des problèmes de contraste.

Stéphanie : Par exemple, j'adore l'orange, mais c'est l'une des couleurs les plus ennuyeuses à travailler car pour avoir un vrai orange accessible, par exemple, comme un bouton avec du texte blanc, il semble presque brunâtre. Et si vous voulez avoir cet orange vraiment brillant, vous avez besoin d'un texte sombre dessus pour le rendre lisible, mais cela donne à votre interface l'apparence d'Halloween à la fin de la journée. Ouais, je te vois rire. Mais c'est vrai. Il s'agit donc toujours de ce genre de compromis et de dire que si vous êtes un développeur et que vous voulez utiliser le framework tel qu'il est et que vous n'avez pas de concepteur, je pense que c'est toujours mieux que de ne rien avoir et de le construire à partir de zéro et après c'est super complexe à utiliser. Mais le fait est que ce n'est pas parce que vous avez les composants que vous allez créer une excellente interface. C'est comme des briques Lego. Si vous avez les briques Lego, d'accord, c'est bien, mais vous pouvez faire un très beau vaisseau spatial ou vous pouvez faire quelque chose qui ne tient pas et qui s'effondrera parce que vous n'aviez pas vraiment de plan.

Stephanie : Donc, le design est un peu plus que cela. Le design consiste à vraiment comprendre ce qui va être à l'écran, comment cela va fonctionner. Et je connais des développeurs qui ont réellement la capacité de le faire. Ils sont donc très bons avec les directives d'utilisabilité et ils comprennent beaucoup de règles de conception, par exemple. Donc, quand il s'agit de choisir les composants, ils sont vraiment doués pour ça. Et je connais des développeurs qui n'ont aucune idée des composants à choisir et choisissent le premier qui fait le travail. Mais au bout d'un moment ça ne marche plus. Comme les onglets par exemple, nous avions une interface où certains développeurs choisissaient des onglets. Je pense que cela a du sens au début lorsque vous n'avez que trois éléments. Mais ensuite, il y avait 12 éléments à l'écran, puis vous avez les onglets qui sont trois lignes d'onglets, et tous sont les mêmes onglets de niveau un, et il y a des onglets dans les onglets. Donc ils avaient le composant, ça avait l'air bien parce qu'ils utilisent le framework, mais ce n'était pas vraiment utilisable.

Stéphanie : Et j'ai eu la même chose avec une fenêtre modale par exemple. Où ils construisent les projets sans designer et après un certain temps, je pense que le client a demandé de plus en plus de choses dans ce modal. Ils se sont donc retrouvés avec un écran avec un tableau et lorsque vous cliquez sur ajouter une ligne, vous ouvrez un modal, et dans ce modal vous avez deux onglets, puis dans l'un de ces onglets, vous avez même un autre tableau et ensuite ils voulaient ajouter un élément supplémentaire à cela, je me disais, d'accord, peut-être pouvons-nous mettre un modal au-dessus d'un modal. Et à un moment donné, le concepteur répondrait, d'accord, si vous avez autant de contenu dans le modal, cela ne devrait pas être une fenêtre modale. Cela devrait être une page. Donc, même si vous avez le composant, vous avez toujours besoin d'une sorte d'architecte pour faire le plan et vous assurer que tous ces composants fonctionnent bien ensemble.

Drew : Donc, si en tant que designer, on vous demande de modifier le style de certains composants, pourriez-vous essayer de changer tout le style ? Souhaitez-vous tout personnaliser ou y a-t-il certains domaines sur lesquels vous vous concentreriez ?

Stéphanie : Je pense que les couleurs parce que c'est la première chose que vous voyez, les couleurs peuvent en fait vous apporter une identité. Si vous avez comme une identité de marque forte, avoir au moins les couleurs de votre produit sur les boutons ou les icônes et des choses comme ça, vous aide déjà à personnaliser le cadre. Les polices parce que je pense que c'est facile, si le cadre est bien construit, généralement vous changez toute la famille de polices quelque part et ensuite cela devrait se répercuter sur le reste du site. Donc, les couleurs et les polices sont, je pense, deux façons simples de personnaliser rapidement le cadre. Les icônes sont un autre bon moyen d'apporter de la personnalité, mais cela peut être difficile car d'après ce que j'ai vu, la plupart des cadres sont livrés avec des icônes personnalisées ou Font Awesome ou comme une bibliothèque déjà intégrée. Donc, pour les remplacer, vous avez d'abord besoin d'un beaucoup d'icônes si vous voulez toutes les remplacer. Donc c'est peut-être un peu complexe. J'ai également vu des frameworks qui vous permettent de choisir le pack d'icônes que vous souhaitez utiliser. comme Font Awesome, Glyphicons et quelques autres. C'est donc le genre de choses que vous pouvez facilement personnaliser.

Stephanie : Et puis c'est une question d'aspect et de convivialité, par exemple l'en-tête, généralement vous avez différents types d'en-têtes, de pieds de page. Comment gérez-vous des choses comme ça. Il y a donc déjà beaucoup de petites personnalisations que vous pouvez apporter pour que cela ne ressemble pas à Material-UI, cela ressemble plus à votre marque et vous pouvez ensuite jouer avec les rayons de bordure par exemple. Que vous vouliez des boutons complètement arrondis, ou que vous vouliez des boutons carrés ou que vous vouliez aussi quelque chose au milieu comme des ombres. Donc, quelques petites choses qui sont généralement faciles à personnaliser car la plupart de ces frameworks les ont dans des variables CSS. C'est le genre de petites choses que l'on peut personnaliser sans je pense beaucoup d'efforts, à part ces effets d'entraînement. Je déteste ça. Je vais le combattre. J'espère qu'ils finiront par le changer.

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. Savez-vous?

Drew: Yup.

Stephanie: It does. D'accord. 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.