La conception UX vue par un développeur front-end

Quand on est développeur front-end, le développeur qui s’occupe de faire les interfaces graphiques, il y a plusieurs façons d’aborder une page dans un projet web, selon ce que l’on souhaite en faire.
Par le passé dans d’autres projets, on m’a demandé de juste suivre les maquettes imposées par les UI designers et dans ce cas là, on rentre dans la case “intégration web”. Le souci, c’est que des maquettes ne reflètent pas l’utilisation réelle d’une page, surtout quand on peut avoir beaucoup de données sur cette page. C’est là que rentrent en jeu l’ergonomie et la réflexion utilisateur et c’est un défi que j’aime et que je croise souvent sur les pages de Babbar et YourTextGuru dans la mesure où beaucoup de données sont affichées sur chaque page du site.
Côté UX, les ergonomes vont surtout intervenir une fois la page déjà présente sur le site, et traquer les comportements utilisateurs afin d’ajuster la page en fonction des observations.
Côté développeur front, j’aime anticiper les pratiques utilisateurs pour apporter une bonne expérience dès la première utilisation d’une nouvelle fonctionnalité. Et pour cela, il faut réussir à se mettre dans la peau de l’utilisateur.

Dans cet article, je vais vous montrer mon processus de réflexion autour de la page de positionnement mise en ligne il y a quelques mois sur YourTextGuru.

Différence entre UX, UI et Product Design

Avant toute chose, il faut rappeler la différence entre ces trois termes qui ont souvent tendance à être mélangés. L’UI designer s’occupe des maquettes et imagine les interfaces, de sorte à ce qu’elles soient jolies. 
En comparaison, l’UX designer (ou ergonome) priorise la praticité de l’interface. Il/Elle souhaite que l’expérience soit satisfaisante pour l’utilisateur et qu’il/elle puisse se servir du site web de manière efficace.
Typiquement, pendant très longtemps, CDiscount avait une UI très chaotique (y en avait clairement partout).


Et pourtant, d’un point de vue strictement utilisateur, on avait l’impression d’être dans un grand marché web où on allait forcément dénicher une bonne affaire parmi tous ces prix qui clignotent.
Dans un monde idéal, UI et UX designer travaillent main dans la main, y compris avec le développeur. Mais dans les faits, les 3 partis ont chacun leur propre vision du projet.
C’est là qu’intervient la personne qui tranche au milieu des avis qui divergent, le Product Designer. Son but, c’est surtout de vendre et de faire en sorte que le produit réponde aux attentes du marché. Que l’application web proposée soit utile aux utilisateurs.
Alors ça ne veut pas dire que quand on pense « Produit », qu’on ne veut pas faire une jolie interface ou qu’on ne veut pas que le visiteur soit satisfait du temps passé sur le site. C’est surtout une histoire de priorité. Et il n’y a qu’à lire des interviews de Product Designer dans des grosses entreprises pour comprendre qu’ils sont un peu au milieu de tout le monde, y compris des responsables qui ont des objectifs commerciaux.

De mon point de vue de développeur front-end, j’ai tendance à mettre l’accent sur l’UX et le design produit qui me paraissent essentiels pour réussir à aboutir à des fonctionnalités d’un projet qui correspondent aux besoins du marché et inciter l’utilisateur à revenir sur notre outil. (C’est peut-être aussi parce que je ne sais pas faire de belles interfaces me direz-vous…)

Design, expérience utilisateur avant le code

Nous voulions sur YourTextGuru une page qui répertorie pour un site toute une série de données sur les mots-clés sur lesquels ce site se positionne.
Et là arrivent la liste des types de données provenant du back-end que l’on veut proposer à l’utilisateur :

  • Position
  • URL sur laquelle se positionne le mot-clé
  • Difficulté SEO (à quel point c’est difficile de se positionner bien par-rapport à la concurrence)
  • Catégorie
  • Nombre de mots dans le mot-clé
  • Dernière mise à jour des informations
  • Compétition (à quel point le mot-clé est concurrentiel sur Google Ads)
  • Tendance (l’évolution dans le temps du nombre de recherches pour ce mot-clé)
  • Trafic URL (combien de clics estimés a généré cette URL le mois dernier)
  • Trafic Top1 (combien de clics estimés a généré l’URL en position 1 le mois dernier)
  • Volume (le nombre de recherches mensuel sur Google pour ce mot-clé)
  • Delta mieux (le trafic estimé gagné si l’URL gagnait une position dans la SERP)
  • Delta top (le trafic estimé gagné si l’URL passait top 1 dans la SERP)
  • CPC (le coût moyen par clic payé pour ce mot-clé avec Google Ads)
  • Enchère min (enchère minimale payée pour être positionné via Google Ads)
  • Enchère max (enchère maximale payée pour être positionné via Google Ads)

Ça en fait de la donnée…Dans un tableau, ça donne ça : 

Si le site est positionné sur 5000 mots-clés, on obtient un tableau très large avec 5000 lignes, donc imaginez avec des centaines de milliers de mots-clés.
La solution simple : un tableau énorme qui charge petit à petit et une barre horizontale pour faire défiler horizontalement le tableau.
Mais le scroll horizontal, dans le web c’est tabou ! On aime pas ça. Rien que sur une souris, il faut cliquer sur la molette pour pouvoir activer le scroll horizontal. On fait face à un point de friction, qui va nous poser problème en terme d’ergonomie (et d’UI design, faut avoir qu’une scroll bar, c’est pas très beau et y a une bonne raison si on ne voit ça sur aucun site web).

Dans ces cas-là, il faut réussir à comprendre le besoin d’utilisateur et se mettre à la place des différents cas d’usage. Se poser les bonnes questions.

  • Est-ce que toutes ces informations sont importantes ? 
    Oui, mais certaines plus que d’autres.
  • Est-ce que chaque utilisateur recherche la même chose ?
    Non, chacun a un besoin différent.
  • Est-ce que chaque utilisateur a besoin de filtres ?
    Non, sûrement pas hormis la recherche de mot-clé.

À partir de là, je vais lister les différents “types de profil” utilisateur, les personas, qui pourront arriver sur cette page. Très vite, j’ai décelé plusieurs utilisations : la personne qui veut voir les informations relatives à Google Ads, celle qui veut voir les volumes et celle qui veut juste les infos liées à la SERP comme la catégorie ou la difficulté pour se positionner.

Transformer les personas en interfaces

J’ai mes profils utilisateurs, mes personas. Maintenant, comment les différencier ? 
Avoir plusieurs vues et l’utilisateur peut changer le mode d’affichage en cliquant sur une icône et accéder à plusieurs interfaces ? Pourquoi pas, mais ça oblige à sauvegarder la recherche, les filtres, les tris.

On pourrait imaginer des vues différentes si les utilisateurs ont des rôles différents. Mais ça suppose que chaque rôle se limite forcément à sa vue dédiée.

Finalement, si on repart de la page minimale que j’avais décrite, le principal souci de cette page, c’était le scroll horizontal. Et si on masquait les colonnes dont l’utilisateur n’a pas besoin afin d’éviter ce scroll ?
Et si pour lui simplifier la vie, on enregistrait avec un cookie les colonnes qu’il/elle a l’habitude de regarder ?

Dans ce cas, comment masquer ces colonnes ? Un simple clic sur la colonne ? Un icône oeil ? Une liste déroulante où on cocherait les colonnes qui nous intéressent ?

Et si on reprenait les profils utilisateurs qu’on a détecté pour créer des “catégories” actionnables ? Un switch pourrait faire l’affaire !

Quelques tests plus tard, on obtient la barre graphique ci-dessous : 

On retrouve les filtres rapides que sont l’URL et le mot-clé, il faut pouvoir filtrer rapidement sur ces éléments.
À droite, on remarque les fameux switchs qui permettent de masquer/afficher des colonnes afin d’avoir une vue plus pertinente du tableau de données. Suivi d’un bouton “Filtres” qui permet d’ouvrir une popup pour accéder à des filtres qui ravira les plus experts des utilisateurs.

Forcément il y aura quelques ajustements après les retours clients, mais on a trouvé une manière pour couvrir les cas d’usage des utilisateurs. Ce n’est pas LA page qu’il fallait créer, il y aurait peut-être eu d’autres approches possible, mais c’est celle-ci qui a aboutit après nos tests et qui nous satisfait nous, et nos utilisateurs.

Réfléchir au produit, la clé d’un bon développement front

Toutes ces questions font parties de la réflexion ergonomique liée à la création d’une page. Certaines peuvent être répondues directement, d’autres nécessitent d’être testées afin de pouvoir y répondre lors de l’utilisation.
En tant que développeur front-end, il ne faut pas négliger l’UX et tout bon développeur front-end qui doit faire face à des problématiques liées aux cas d’usage, doit constamment des questions. “Et si …?” fait parti de mon quotidien, et cette remise en question constante me permet de prendre du recul pour proposer la meilleure expérience aux utilisateurs de YourTextGuru.