Comment puisje travailler avec des cadres d'interface utilisateur?

En tant que développeur moi-même, une des choses que j'aime dans les frameworks UI est qu'ils viennent souvent avec un style par défaut, mais c'est quelque chose que nous devrait compter sur des projets? Simplement en utilisant le style par défaut et en espérant 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 dans lequel je parle à la designer UX Stéphanie Walter des choses que nous devrions considérer lors de la construction d'un cadre d'interface utilisateur.

Afficher les notes

Mise à jour hebdomadaire

Transcription

Drew McLellan: Elle est une designer centrée sur l'utilisateur et experte en expérience mobile, qui a croisé de délicieux produits et interfaces 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 nommer que quelques-uns, et elle aide ces clients à livrer des projets réussis à leur public, de la stratégie au produit final. Elle est un développeur Google expert en conception de produits et un enseignant passionné partageant ses connaissances dans de nombreux articles de blog, articles, ateliers et présentations de conférence. Nous savons donc qu'elle est une experte en conception d'expérience utilisateur, mais saviez-vous qu'elle avait déjà travaillé avec Sir Elton John? Mes amis Smashing, veuillez accueillir Stéphanie Walter. Bonjour Stéphanie, comment ça va?

Stéphanie Walter: Salut, je suis en train de casser 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 des cadres d'interface utilisateur standard. Désormais, 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 standard me semble un peu exagérée. Est-ce que l'utilisation du cadre d'interface utilisateur est quelque chose que vous voyez beaucoup tout au long de votre travail?

Stéphanie: Oui, c'est quelque chose que j'ai vu beaucoup, surtout ces dernières années parce que j'ai commencé à travailler avec une agence et maintenant je travailler au sein de l'entreprise. Donc, dans ces super grosses équipes de technologie informatique et oui, en ce moment, il y a beaucoup d'interfaces-cadres comme celle que j'ai le plus vue est Material-UI, la conception Material est essentiellement une sorte de directives et de choses de Google, et Material -UI est l'équipe d'Angular, mais aussi l'équipe de React. Ils ont créé leur propre cadre en utilisant le style et la convivialité de la conception matérielle de Google. Mais cela n'a plus rien à voir avec Google. C’est 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 assez populaire.

Stéphanie: C'est un framework React. Je ne sais pas s'ils ont aussi Angular. Je pense que cela a été fait 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 cadre. Alors oui, c’est quelque chose que j’ai beaucoup vu, surtout dans les grandes équipes informatiques parce que la plupart du temps celles-ci n’ont pas de designer. En ce moment, je suis essentiellement une équipe UX d'une personne dans une petite équipe dans 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 d'affaires, toutes les bonnes personnes, mais est toujours un concepteur pour l'ensemble du projet.

Stéphanie: Jusqu'à mon arrivée, il n'y avait pas de concepteur. C'est donc une sorte de solution implémentée dans de nombreuses entreprises, notamment sur les produits internes par exemple. Là où ils disent habituellement, d'accord, nous n'avons pas vraiment besoin d'un designer pour ça. Nous avons juste besoin de quelque chose qui fonctionne pour nos utilisateurs internes et utilisons simplement un framework car il 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 de concepteur d’interface utilisateur. Oui, le problème est que, d'accord, alors vous avez les composants, mais le rôle du concepteur d'interface utilisateur n'est pas simplement 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 l'ensemble de 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 que mettons-nous à 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 va-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 pouvoir créer une interface utilisateur utilisable en utilisant un cadre d'interface utilisateur standard, ou est-ce que ça va toujours être un peu un compromis?

Stéphanie: J'espère que oui. J'espère en quelque sorte parce que sinon je ne construis pas d'interfaces utilisables. Donc, cette réponse est 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 compromets 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 retour d'informations important lorsque l'utilisateur clique sur ou touche le bouton. Mais ensuite, les étapes sont une sorte d'effet d'entraînement qui va jusqu'au bout. 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 il 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 super 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, le client actuel d'une compagnie de voyages et de compagnies aériennes. 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 arrivée et le calendrier de base de la plupart de ces cadres 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 dont ils disposent. 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? En créons-nous un personnalisé qui répondra aux besoins des utilisateurs? Ou faisons-nous un mélange des deux? Dans le cas du calendrier, par exemple, nous utilisons la grille de calendrier, nous utilisons donc le composant de base, puis nous l'avons amélioré avec une personnalisation en plus de cela. Donc, il y avait beaucoup de développement React pour celui-là.

Stéphanie: Et oui, donc généralement vous faites beaucoup de compromis.

Drew: Donc, on dirait que l'utilisation d'un cadre d'interface utilisateur peut vous y amener un certain chemin, mais pour avoir vraiment une bonne interface utilisateur à la suite de cela, vous devez faire un peu de personnalisation sur le dessus?

Stéphanie: Habituellement.

Drew: Cette personnalisation va-t-elle au-delà du thème?

Stéphanie: Oui, mon développeur souhaitait que cela ne dépasse pas le thème. Eugene Si vous m'écoutez. Je pense qu'il serait super heureux si nous changions simplement quelques couleurs sur tout. Mais oui, à un moment donné, vous devez aller au-delà de la personnalisation, car tout d'abord, comme les cadres d'interface utilisateur sont comme les outils Lego, c'est une sorte de boîte à outils. Donc, vous avez beaucoup de composants différents dans la boîte, mais cela ne crée pas une 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. Ainsi, vous pouvez parfois modifier un composant en fonction de vos besoins. D'après ce que j'ai compris, nous utilisons le composant de carte pour construire une fenêtre modale, mais le truc avec les fenêtres modales, c'est qu'il ne se comporte pas vraiment comme une carte.

Stéphanie: Vous allez en quelque sorte un peu au-delà. Vous avez besoin d'un fond avec obscurcissement. Vous devez le déclencher au clic alors que votre carte est généralement déjà présente 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 peaufinons un peu. Mais nous nous retrouvons parfois avec des conflits concernant la sémantique, le 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 se trouve dans la forme. »

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 donc que faisons-nous? »Donc, d'habitude, vous commencez à discuter de ces petites choses et comme j'énerve vraiment mes développeurs avec l'accessibilité aussi, c'est une autre couche supplémentaire d'essayer de nous 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 les gifs dans les gifs. Sinon, nous aurons des problèmes à la fin.

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

Stéphanie: Oui.

Drew: Est-ce juste?

Stéphanie: Vous devriez. Tu dois. Alors oui, vous pouvez généralement avoir tous les composants que vous souhaitez. Vous devez toujours 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 cadre, ce que nous faisons, c'est que nous allons vers nos utilisateurs, nous leur parlons, nous essayons de comprendre leurs besoins. Donc pour le moment, je suis assez chanceux parce que les utilisateurs sont en interne au sein de la banque. Nous faisons donc beaucoup d'ateliers avec eux et vous devez imaginer que c'est une interface super complexe. Nous migrons de quelque chose qui a été construit, je ne sais pas, je pense qu'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 grand changement et vous devez comprendre que pendant ces 15 années, tous ceux qui voulaient quelque chose pouvaient aller au support et ensuite demander à l'équipe informatique de le mettre en œuvre. Donc en ce moment mon interface est comme 400 pages avec des tableaux, dans des tableaux, dans des tableaux, avec d'autres tableaux, et des trucs qui ne devraient même pas être dans des tableaux.

Stéphanie: Comme nous avons beaucoup de choses qui sont juste une valeur clé, une valeur clé, une valeur clé. Ils construisent donc la table avec deux colonnes. Je me dis: "Non, peut-être que nous pouvons faire quelque chose de mieux avec ça." Pour le moment, ce que nous faisons, c'est que 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, j'ai donc besoin de cela sur ce calendrier, des trucs comme ça. Ils veulent surveiller une chose, ils veulent rapporter les données. La surveillance, c'est comme regarder les données et s'assurer que tout va bien. Le reporting, c'est pouvoir exploiter les données, en faire quelque chose qu'ils souhaitent partager et collaborer en quelque sorte avec des collègues et tout ce que nous avons découvert en discutant directement avec les utilisateurs.

Stéphanie: Et ce que nous avons découvert est qu'en fait, certaines des choses que nous avions prévu de migrer à la fin sont parmi les choses les plus importantes au quotidien pour l'utilisateur. Donc, l'objectif de planification de l'utilisateur est l'un des plus importants du moment. Nous y travaillons donc vraiment, vraiment. Donc oui, nous utilisons l'interview et maintenant nous sommes dans la phase où, pour le moment, nous sommes de très haut niveau disant que nous devons construire le shell, nous devons comprendre la navigation. Mais pour le moment, nous n'avons pas vraiment parcouru 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 pouvons soit opter pour le type non intelligent et simplement mettre les tables dans la nouvelle interface et nous avons terminé, ou nous pouvons dire, d'accord, essayons de comprendre ce que ces tableaux sont, à quoi nos utilisateurs utilisent-ils ce tableau?

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 logique. Donc, si vous avez un bon cadre et que vous dites, d'accord, utilisons ce graphique… Je pense que c'est ce qu'on appelle le cadre graphique JS. Vous avez beaucoup de choses, vous pouvez avoir un histogramme, 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 dans un graphique ou il est plus logique de les afficher 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 derniers ans, puis un histogramme est plus intéressant. Donc, en fonction de ce que l'utilisateur veut faire des données, vous allez les afficher d'une toute autre manière.

Stéphanie: Et généralement ce n'est pas un travail de développeur de faire ça. Notre développeur, c'est un gars super intelligent. Je suis désolé, mais je travaille honnêtement avec des développeurs de gars, j'aurais aimé avoir des dames, mais non. Aucun d'eux n'est une femme. Donc, les gars super intelligents, mais ils ne sont pas super qualifiés pour dire, d'accord, ces données devraient être affichées comme ça, cela, cela et cela. 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 basées sur des discussions avec les utilisateurs. Souhaitez-vous généralement ramener les prototypes ou 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 fait beaucoup de choses en fait, ce qui est vraiment sympa car alors vous ne développez pas quelque chose avant de savoir que cela va être utile et utilisable. Cela dépend donc. 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 du 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 appelé InVision, où, fondamentalement, vous mettez toute votre conception, 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 d'InVision parce que les gens ne les sentent pas vraiment et surtout sur le téléphone portable par exemple.

Stéphanie: Donc c'est toujours un peu intelligent. Quel est le moyen le plus rapide et le moins cher? Est-il plus rapide et moins cher de ne tester que les designs? Est-ce assez? Pour les formulaires en général, pas vraiment parce que vous avez terminé automatiquement tous les efforts que vous mettez dans le front-end et que l'utilisateur remplit réellement un formulaire.Pour les formulaires, il est peut-être plus efficace de créer un formulaire et de le tester. Mais pour de nouvelles choses, oui, nous faisons beaucoup de designs. Nous allons aux utilisateurs. Donc pour le moment, nous faisons soit en tête-à-tête, 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'alors vous avez 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 se disent, "Oh tu travailles comme ça? En fait non, je fais ça comme ça et ça. »

Stéphanie: Donc c'est aussi intéressant d'avoir quelques personnes dans la salle et d'écouter juste la conversation, de prendre des notes et de dire:« Oh peut-être alors nous pourrions le faire "et" Ce composant serait mieux basé sur ce que je viens d'entendre. "Et des choses comme ça.

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

Stéphanie: Vous devriez savoir qui ils seront, sinon cela fait le travail des responsables marketing avant de créer le produit. Mais oui, nous avons fait des tests utilisateur de guérilla par exemple, vous pouvez toujours utiliser InVision par exemple. Vous pouvez donc créer des prototypes dans InVision, puis recruter les utilisateurs via les réseaux sociaux, par exemple. Je travaillais pour un produit qui a aidé, quel est le nom, les mécaniciens des concessionnaires automobiles qui réparent les choses et ensuite pour informer également le client des réparations supplémentaires, des choses comme ça. Nous avions donc déjà une sorte de communauté croissante sur LinkedIn et Facebook. Vous pouvez donc recruter ces personnes. Vous pouvez faire des tests à distance, comme nous avons une conversation dans un outil comme un outil en ligne. Vous pouvez faire du partage d'écran. Nous l'avons donc fait pour certains projets également.

Stéphanie: Je voudrais juste vous donner un conseil: tester l'outil avant, parce que j'utilisais, il s'appelait appear.in. Mais je pense qu'ils ont changé le nom en Whereby ou quelque chose, mais c'est vraiment dans le navigateur que j'ai dit, d'accord, c'est bien parce que 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 VM, dans un Citrix et ils n'avaient pas de micros, 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. Il y a donc toujours, c'était 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: Quand il s'agit de choisir un cadre d'interface utilisateur avec lequel travailler, si c'est la voie que vous empruntez, est-ce quelque chose que vous laisseriez juste au

Stéphanie: Pour moi, vous devriez 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 a déjà été décidé. Non, en fait c'est drôle, soit c'est déjà décidé, soit ils me demandent de valider leur choix du framework, mais je n'ai fait aucune revue ni recherche. Je n'ai absolument aucune idée du contenu du projet, car ils ne m'ont même pas montré leurs écrans. Ils disent: "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, une application native de Windows qu'ils voulaient migrer dans le cloud. Ils ont dit: «Oui, nous avons seulement besoin des boutons et surtout de formes et de choses comme ça.»

Stéphanie: Mais c'est vraiment difficile de dire: «Ouais, optez pour ce cadre, nous avons tous les composants 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. "Donc je pense que vous devriez toujours avoir une sorte de vue d'ensemble globale avant de choisir votre cadres, sauf si vous êtes sûr à 100% que vous avez tous les composants. Mais j'ai le sentiment 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 une 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 étaient plutôt efficaces en utilisant Ant. Et pour l'interface utilisateur 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 lui.

Drew: Donc, vraiment, il doit y avoir un équilibre entre ce avec quoi les développeurs sont à l'aise, ce qu'ils savent, ce qui va travailler avec leur pile technologique et ensuite 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 un projet, qui est … Je suis au Luxembourg, nous avons beaucoup d'institutions européennes et des choses comme ça, nous avons donc une exigence d'accessibilité supplémentaire pour certaines d'entre elles. Et généralement, lorsque le cadre a été décidé, ils n'ont pas vraiment vérifié l'accessibilité de leur cadre, puis ils reviennent quelques mois après le début du projet en disant: «Oh, nous avons juste dit qu'il y avait cette nouvelle loi et nous devrions être accessible mais nous ne savons pas comment faire. »Comme oui, il 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 qu'il est super complexe de transformer un cadre d'interface utilisateur non accessible en quelque chose d'accessible. Je suppose que cela 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 un cadre d'interface utilisateur a a déjà été choisi, existe-t-il un risque que l'interface utilisateur commence à être influencée par les composants qui existent déjà dans ce cadre plutôt qu'à être motivée 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. Il s'agit donc principalement d'équilibre et de discussion avec les développeurs. Donc, généralement, ce que je fais, c'est que nous faisons des cadres métalliques, même des cadres métalliques rapides, disons d'accord, sur cette page, nous aurons besoin de ceci et 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 en ce moment? À quoi cela ressemble-t-il? Et puis nous décidons ensemble, d'accord, c'est un composant qui ferait le travail ou bien cela ne fera pas le travail. Le peaufinons-nous? Comme on garde toujours le composant mais on le change un peu pour qu'il fasse le boulot, ou on construit quelque chose à partir de zéro?

Stéphanie: Et au final ça dépendra du budget de cours. Vous avez donc 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 quelques 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 doit comprendre comment il fonctionne efficacement et oui, c'est, comme vous l'avez dit, 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, terminons-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: Ce qui me frustre le plus, c'est quand je sais que nous utilisons un composant de correction de récolte et ils me disent: Oh non, ne t'inquiète pas. Nous corrigerons cela plus tard. Et je savais que ce dernier ne pourrait malheureusement 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? Oui, il s'agit de compromis. Lorsque vous travaillez avec ce type d'outils.

Drew: 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. Cela signifie donc que je n'ai pas nécessairement besoin d'un designer pour m'aider avec l'apparence de tous les composants. Est-ce quelque chose sur lequel nous devrions nous appuyer 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 styliseriez ces composants vous-même?

Stéphanie: Je pense que cela dépend vraiment. Le problème avec Material-UI, par exemple, 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 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 car 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 sont livrés avec des thèmes personnalisés afin qu'au moins vous puissiez 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 très 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 orange, mais c'est l'une des couleurs les plus ennuyeuses avec lesquelles travailler parce que pour avoir une vraie orange accessible, par exemple, comme un bouton avec du texte blanc, il a presque l'air brunâtre. Et si vous voulez avoir cette orange vraiment brillante, vous avez besoin d'un texte sombre dessus pour le rendre lisible, mais cela fait en quelque sorte que votre interface ressemble à Halloween à la fin de la journée. Ouais, je te vois rire. Mais c'est vrai. Il s'agit donc toujours de ce type de compromis et de dire si vous êtes développeur et que vous souhaitez utiliser le framework tel quel et que vous n'avez pas de designer, je pense que c'est toujours mieux que de ne rien avoir et de le construire à partir de zéro et alors 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, ça va, mais vous pouvez faire un très beau vaisseau spatial ou vous pouvez faire quelque chose qui ne tient pas ensemble et qui s'effondrera parce que vous n'aviez pas vraiment de plan.

Stéphanie: Le design est donc bien plus que cela. Le design consiste à vraiment comprendre ce qui va apparaître à l'écran, comment cela fonctionnera. Et je connais des développeurs qui ont réellement la capacité de le faire. Ils sont donc vraiment bons avec les directives d'utilisation et ils comprennent beaucoup de règles de conception, par exemple. Donc, quand il s'agit de choisir les composants, ils sont vraiment bons dans ce domaine. Et je connais des développeurs qui n'ont aucune idée des composants à choisir et choisissent le premier qui fait le travail. Mais après un certain temps, cela ne fonctionne 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 ce sont tous 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 comme 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 des trucs supplémentaires dans ça, je me disais, d'accord, peut-être que nous pouvons mettre un modal sur un modal. Et à un moment donné, le concepteur répondrait, d'accord, si vous avez autant de contenu dans le modal, ce ne devrait pas être une fenêtre modale. Ce 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 concepteur, on vous demande pour changer le style de certains composants, voudriez-vous simplement essayer de changer tout le style? Souhaitez-vous tout personnaliser ou y a-t-il certains domaines sur lesquels vous vous concentreriez?

Stéphanie: Couleurs Je pense que parce que c'est la première chose que vous voyez, les couleurs peuvent réellement vous apporter une identité. Si vous avez une identité de marque forte, au moins avoir 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, vous changez généralement la famille de polices entière à un endroit et cela devrait en quelque sorte se mettre en cascade sur le reste du site. Donc, les couleurs et les polices sont, je pense, deux façons simples de personnaliser rapidement le cadre. Icons is another nice way to bring personality, but it might be difficult because from what I’ve seen, most of the framework come with custom icons or Font Awesome or like a library already built in. So to replace those, first you need a lot of icons if you want to replace them all. So it might be a little bit complex. I have also seen frameworks that lets you choose which icon pack you want to use. like Font Awesome, Glyphicons and some of the other ones. So this is the kind of things you can quite easily customize.

Stéphanie: And then it’s about look and feel, for instance the header, usually you have different kinds of headers, footers. How do you navigate things like that. So there’s already a lot of small customization you can bring so that it doesn’t look Material-UI-ish, it more looks like your brand and then you can play around with border radius’s for instance. Whether you want completely rounded buttons, or you want square buttons or you want something in the middle like shadows also. So some small stuff that are kind of usually easy to customize because most of those frameworks have them in CSS variables. This is the kind of small things that you can customize without I think a lot of effort, except for these ripple effects. I hate that. I’m going to fight it. I kind of hope they change it eventually.

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?

Stéphanie: 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.

Stéphanie: 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.

Stéphanie: 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.

Stéphanie: 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?

Stéphanie: 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.

Stéphanie: 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?

Stéphanie: 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.

Stéphanie: 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?

Stéphanie: 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.

Stéphanie: 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?

Stéphanie: 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.

Stéphanie: 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.

Stéphanie: 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?

Stéphanie: 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?

Stéphanie: I’ve been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stéphanie: 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 Stéphanie. You can follow her on Twitter where she’s @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stéphanie. Do you have any parting words for us?

Stéphanie: Thanks for having me. It was a smashing experience.

(dm, ra, il)