L'éco-conception c’est obligatoire si on veut optimiser l'expérience utilisateur, interview de Ivan Dalmet, Lead Designer UI/UX au Bear Studio

Cette semaine, c’est un ancien collègue que j’interviewe, Ivan Dalmet. C’est un UX Designer de métier et on va parler de son expérience d’optimisation des sites et applications. On ne va pas en parler pour l’impact écologique, mais pour fluidifier au maximum l’expérience pour les utilisateurs.

Particulièrement, les ACF (Note: Ajout de champs configurables) qui permettait de transformer WordPress en vrai CMS sans avoir un Builder.

Le problème des builders, c’est qu’ils générent du code automatiquement. De plus, les administrateurs de contenu n’avaient pas de connaissances très poussées. Généralement, en production, sur mobile, la mise en page était cassée.

Maintenant si tu prends les gens qui utilisent Wordpress, tout le monde utilisent des builders pour être responsive. A l’époque, ce n’était pas vraiment le cas.

J’ai ensuite intégré une équipe en tant qu’UX Designer, comme il n’y avait pas beaucoup de développeurs, j’aidais aussi sur d’autres sujets.

J’ai pu participer à un projet intéressant sur des widgets pour les sites d’e-commerce. Ces widgets sont du javascript et avant que j’arrive, il était assez lourd. Avec un développeur, on a travaillé pour enlever le maximum de code au possible. L’objectif est d’avoir quelque chose qui se charge rapidement sur le site des clients.

On a enlevé toute la notion d’image pour tout faire en CSS. Que tout soit configurable, mais que ce soit ultra léger pour éviter d’avoir à charger 400 images.

Ensuite je suis passé vers de l’applicatif métier. Là le poids de l’application a moins d’impact parce qu’une fois que je l’ai chargé, c’est bon. Par contre, pour la suite de la navigation cela nécessite de fluidifier et d’unifier l’expérience sur toutes les interfaces.

On a créé un design system, c’est une bibliothèque de composants et de design pattern (Note: patron de conception) prêt à l’emploi pour être utilisé par l’équipe de développement (comme des briques Lego). Cela permet d’avoir une navigation cohérente et même de pousser davantage le curseur sur l’accessibilité de l’application.

Enfin, je suis maintenant un des fondateurs du Bear studio (un studio de développement). On a créé des starters pour mieux démarrer les projets avec les bonnes pratiques. On a créé un starter pour le web, pour les applications mobiles et aussi pour les designers sous Figma.

Ensuite ce qu’il faut réfléchir, c’est est-ce que l’usage de l’application mobile est le premier usage dans tel cas il faut construire les interfaces dédiées à cette utilisation, cela peut être coûteux mais nécessaire. Si par contre c’est un usage secondaire de consultation, car je peux me connecter techniquement depuis mon mobile, il faut faire que cela fonctionne et que l’utilisateur puisse au moins consulter et faire des actions simples.

Je me rappellerai toujours au tout début de ma carrière. Il y avait des boutons avec des icônes. Les icônes étaient fait en PNG. Quand on passait au-dessus (hover) du bouton pour survoler, l’icône changeait. On chargeait donc un autre PNG. Sauf que le problème, c’est qu’avec le réseau, le temps que la 2ème icône s’affiche, il y a un moment l’icône disparaissait et puis réapparaissait. Donc ça en termes d’expérience utilisateur, c’est horrible et en plus ça coûte 2 téléchargements d’images, 2 appels de réseau.

Pour éviter cela, on faisait des sprites. C’est-à-dire qu’on chargeait une fois une image avec toutes les choses. L’avantage, c’est que c’était moins coûteux. Pour l’expérience utilisateur, c’était plus rapide. Parce que quand je passais en hover, j’avais déjà mon image. L’expérience utilisateur était améliorée. En plus je gagnais aussi en poids parce que je pouvais optimiser une seule et unique image. Par contre en terme de maintenance, quand il fallait rajouter des images cela commençait à être galère.

Ensuite sont arrivées des fonts (polices de caractère) avec des jeux d’icônes comme font awesome. C’était révolutionnaire parce que ça permettait d’avoir des icônes vectorielles qu’on peut changer juste en changeant la taille de police et en changeant la couleur de la police. Sauf qu’au final on chargeait une police énorme pour utiliser au final 20 icônes…​ Au pire une font de 600 ko pour afficher 3 icônes. Je ne vais pas infliger de charger 600Ko en 3G pour avoir 2 icônes sur mon site. De plus cela provoque des problèmes d’accessibilité parce que ça reste une fonte donc ça reste des caractères que le lecteur d’écran essaie de lire.

Enfin, il y a eu les SVG inline qui permettaient directement de mettre le code, comme du HTML, directement dans la chose. Donc même plus besoin de télécharger une ressource externe au chargement HTML, j’ai directement les icônes qu’il faut au premier affichage de la page. Inconvénient, si j’utilise 4000 fois la même icône, je me trouve avec 4000 fois le petit bout de code (le cas est peu fréquent). L’avantage c’est que c’est déjà dans mon HTML, même si vous avez du délai dans le réseau, dès le début, l’affichage est le plus complet possible.

Par rapport à ce qu’on attend donc pour un site internet type site vitrine, c’est je suis dans le métro et on m’a parlé de tel sujet, je le recherche et je le trouve rapidement sur Google, je clique dessus, j’ai l’information et je parcours rapidement jusqu’à l’objectif final.

Mon objectif c’est de fluidifier tout ça, que ça soit simple à utiliser. En prenant des outils, des pratiques, de l’ergonomie, le développement, le business, en essayant d’orienter les choses pour que ça soit plus utilisable. Je dirais même que si on peut ne rien développer et que ça optimise l’expérience utilisateur, c’est mieux.

J’ai vu une conférence l’autre jour à Codeurs en Seine sur l’éco-conception. Il y a juste un point qui m’a dérangé dans un exemple. Pour télécharger un podcast, il y avait 2 options, basse qualité ou haute qualité. Pour moi, c’est une mauvaise approche aussi bien en UX que en éco-conception. La solution serait de retirer la haute qualité et de mettre télécharger. C’est bien dans le monde parfait, mais je trouve qu’en terme d’expérience, c’est pas forcément la meilleure stratégie. Il y a peut-être des personnes avec du matériel dédié, mais globalement en tant qu’utilisateur je me pose même pas de question, je veux pas de la basse qualité. J’aurais juste transformé en disant « télécharger l’épisode » ou « qualité audiophile ». Puis quand je clic dessus, il y a quelque chose qui me dit « est-ce que vous allez voir la différence si vous n’avez pas le matériel adapté » et dans ce cas je télécharge l’épisode en qualité normale.

Il n’y a pas de débat c’est compresser et optimiser toutes les ressources.

Pour les parties à débats il y a l’utilisation des frameworks : certains vont conseiller de partir sans framework (HTML, CSS, Vanilla Javascript (i.e. javascript sans utilisation de framework)). Le problème est que ce type de projet est souvent fait par des juniors. Au bout d’un moment, pour aller plus vite, il rajoute bootstrap et l’utilise à 5% de ses fonctionnalités et il n’a pas forcément mis le socle pour minifier le javascript, le css. Enfin il rajoute les images à la va vite. A la fin, on se retrouve avec un site avec des performances horribles (mais il n’y a "presque" pas de framework).

De l’autre coté en utilisant Next.js, il y a déjà tout le socle d’optimisation. Automatiquement, les performances vont prendre un coût de boost pour les utilisateurs. Même du coté des core vitals.

C’est comme les outils comme Lighthouse, vous avez une analyse automatique, ce n’est pas magique cela vous permet de savoir à quel niveau vous êtes dans les bonnes pratiques.

Pour optimiser une application, pour moi, on n’est plus sur le temps de chargement initial. On va charger pas mal de librairies pour fluidifier déjà pour le temps de développement. Les attentes dans une application moderne ne vont pas être les mêmes que sur un site web. Sur un site web, si on a peu d’interactivité, c’est pas très grave. Par contre, sur une application, on va s’attendre à énormément d’interactivité. Le javascript même minifié peut vite monter à 1Mo. Par contre sur des applications qui sont utilisées au quotidien, avec un cache bien configuré, le premier usage correspond à l’installation d’une application, tous les prochaines utilisations seront à affichage instantanées (sans nouveau chargement des 1Mo).

Non, si vous faites une application web. Ma préconisation c’est d’avoir un environnement de « pré-production ». Si je teste depuis ma machine en local je verrais moins de chose à optimiser que sur un environnement réel, sur une préproduction, je vais aussi pouvoir lancer des analyses externes comme Lighthouse, tester des choses sans casser la production et me rendre compte des améliorations à faire.

Merci Ivan

Propos recueillis par Eva Giffard et Youen Chéné