La RéUXite
Késako?
RUX, ou “Rethinking User Experience” est un atelier visant à revisiter, repenser l’expérience utilisateur d’un site donné dans le but de détecter d'éventuels manquement et d’y remédier. Pour ce RUX ci, le site choisi fut une archive du site de l’iMAL.
Que demande le peuple?
Isoler les problèmes qu’aurait un utilisateur durant son utilisation du site est la première étape importante de ce procédé de longue haleine. Et pour ce faire, un test utilisateur était tout indiqué. Le Covid n’aidant pas, mon choix de testeur était réduit. J’ai cependant pu faire appel à ma mère. Le test ainsi que son étude plus complète peut être trouvé dans cet article Médium.
Les points soulevés:
Les points important souligné durant ce test furent les suivants :
- une navigation trop discrète à l’agencement chaotique;
- un manque de respect des Lois de la Gestalt (exemple : manque d’espace entres les blocs d'informations);
- mauvaise architecture de l’information : Les blocs de contenus ne sont pas regroupés de manière pertinente;
La Réuxite: premier pas.
Vient le moment de créer les groupes, moment légèrement confus où le hasard fait le plus souvent les choses!
Armé de mon meilleur jeu de mot et de bonne volonté, c’est à quatre que nous avons revisité les tests utilisateurs réalisés.
Notre conclusion resta la même, ce qui nous conforta un peu dans ce début d’atelier. Content de nous rendre compte de l’évidence des défauts mis en avant, nous avons entamé la suite du programme.
Réalisé en groupes, chacun s’occupant d’une page à la fois, l’inventaire du contenu avait pour but de mettre en évidence les éléments importants des pages, de revenir à l’essence du contenu et de clairement l’identifier.
Mais qu’est-ce que l’iMAL?
Après avoir observé dans sa structure ce qu’était le site de l’iMAL, moi et mes collègues nous sommes attaqué à la question de “qu’est-ce que l’iMal?”, l’organisation, plutôt que le site. Nous en sommes arrivé à la définition qui suit:
iMAL: Centre créatif et artistique à Bruxelles, ouvert au public, et à vocation d’exposition et d’expérimentation sur les sujets de l’art, des médias et des nouvelles technologies. Le centre offre un accès à diverses infrastructures pour ses visiteurs ainsi que des conférences et ateliers.
C’est en comprenant ce qu’est cette organisation que nous pouvions alors penser aux différentes tâches que ce site était supposé réaliser afin de correctement aiguiller les potentiels visiteurs. Tous ensemble, nous avons alors établi une liste desdites tâches.
Des tâches supérieures:
De là, un vote a eu lieu : Nous devions choisir les Top Tasks, les tâches primordiales du site, celles qui devaient être travaillées et optimisées pour les utilisateurs. La sélection établie fut la suivante:
- consulter la liste/s’inscrire à un atelier;
- location d’un espace au sein de l’iMAL;
- développer un projet avec l’iMAL/au FabLab/résidence;
- informer l’utilisateur sur les prochains ateliers/activités/expo/…;
- voir les tutoriels;
À partir de là, les différents groupes ont sélectionné la Top Task les inspirants le plus pour l’étudier davantage et proposer une solution quant à sa réalisation.
De quoi à besoin l’utilisateur?
La tâche sélectionnée par la RéUXite fut celle d’informer les utilisateurs sur les différentes activités, conventions et ateliers organisés par l’iMAL.
Une fois cela en tête, il devenait important de se demander les différents éléments nécessaires à la réalisation de cette tâche pour un utilisateur. Sur base d’une brève recherche sur le sens d’informer sur le web, nous avons donc établi une liste des éléments essentiels à l’information ainsi que des fonctionnalités à jumeler à ces éléments pour garantir une navigation et utilisation du site plus aisée.
Parlons Fonctionnalités:
Maintenant que la questions des besoins utilisateurs et des tâches à accomplir était résolue, il nous fallait progresser sur comment répondre aux besoins identifiés. Pour ce faire, j’ai donc exploré une variété de sites offrants des biens et services afin de trouver plusieurs fonctionnalités utiles à ma tâche. Parmis le lot de fonctionnalités trouvées, certaines relativements intéressantes ont retenues mon attentions:
- Un panier: L’utilisateur a ainsi un moyen de se constituer un ensemble d'événement qui l’intéresse qu’il pourra consulter et trier plus tard avant de finaliser une réservation;
- "Susceptible de vous intéresser": Une liste de propositions visant à informer sur des évènements similaires pouvant convenir à l’utilisateur en fonction des articles consultés ou en fonction des articles souvent consultés par des utilisateurs ayant les mêmes intérêts;
- La Newsletter: Outil pratique pour garder un utilisateurs informé. Donner à cette Newsletter la possibilité d’être customisé en fonction de ce que l’utilisateur désire serait également intéressant;
- Une fonction de recherche et de tags: La possibilité de filtrer par intérêt dans une offre aussi importante est capitale pour ne pas noyer l’utilisateur dans des informations non désirées;
Un Squelette, un début d’articulation :
Les idées étaient écrites, il fallait maintenant leur donner forme. Quelques feuilles de papier et un bic à ma disposition, je commençais à imaginer du faux contenu pour mettre en forme cette hypothétique page web. Comment s'organisera le contenu? En colonne, en grille? Les fonctionnalités, comment les intégrer de manière intuitive? à coup d’essais et d’erreurs, une quantité d’ébauche se dessine, permettant ensuite de proposer ces concepts au groupes et recevoir des critiques concernant nos plans et idées.
Images: Présentation du projet de Sylvian Bergiers.
Une mise à l’épreuve: Le User journey.
Un bon moyen de tester directement ses idées est de se mettre dans la peau de plusieurs utilisateurs différents arrivant sur le site.
En agissant de manière aussi fidèle que possible avec cet échantillon hypothétique en utilisant les croquis réalisés, nous pouvons établir une liste de faiblesse de notre design afin d’y remédier. En répétant le processus suffisamment de fois, nous réduisons ainsi le nombre de défauts arrivant dans la prochaine étape de conception de la page.
Si la satisfaction de l’utilisateur diminue, il faut alors réfléchir à une solution. Consultez la mind‑map complète ici!
Le souci le plus commun durant les user journey que j’ai réalisé était le choc de l’information frappant un utilisateur qui désirait une information particulière. Effectivement, arriver sur une page proposant une dizaine d'articles au premier regard risque de brusquer l’utilisateur. Pour éviter ce soucis, j’ai donc réfléchis à l’éventualité d’inclure une sous-navigation dans l’onglet événement qui sélectionnerait directement le tag “Fablab” par exemple, ou “Exposition” lorsque l’utilisateur sera redirigé afin qu’il n’ai pas à chercher les filtres sur la page, et se voit immédiatement proposé une sélection large de ce qu’il recherche avant de l’affiner lui-même par la suite.
Ajoutons du corps: La maquette papier!
Après avoir filtré les premières erreurs grâce aux méthodes ci-dessus, j’ai commencé à mettre en place une maquette sur papier.
J’ai tout de suite commencé avec la page “événements” puisqu’elle était ma Top Task, articulant l’idée des “cards” pour présenter les différents ateliers avec un système de filtre constamment visible sur le côté droit de la page. Inspiré par Amazon, je me suis rendu compte qu'une partie de l’espace dédié aux cards sur Desktop pouvait être allouée aux filtres sans nuire à l’aspect visuel ou l’utilité de l’interface. De plus, ce choix assure que l’utilisateur n’aura pas de mal à trouver les dits filtres, un features très importants pour cette page.
Les premiers changements:
Le système de favoris, fonctionnant comme un panier sur n’importe quel site de shopping à lui ,par-contre, été revu. Plutôt que de rediriger d’office l’utilisateur sur une autre page lorsque ce dernier cherche à consulter la liste des évènements sélectionner, j’ai opté pour une solution intermédiaire: Un menu s’ouvrant par dessus les filtres et reprenant la liste des différents atelier ou expositions auxquelles notre user aura apposé la petite étoile dorée! Cela lui permet, entre-autre, de désélectionner certains ateliers au vol! Et pour éviter un malencontreux clic de travers, j’ai également pensé à un petit message avertissant l’utilisateur lorsqu’il a supprimé du contenu de ses favoris avec l’option de “undo” ces changements.
Toujours par rapport aux filtres, je me suis posé la question de l’utilité d’une sous-navigation, et me suis rendu compte que cette dernière pourrait servir à immédiatement triés le contenus en fonction de ce que l’utilisateur désire: Survolez “évènement”, Sélectionnez “FabLab”, vous arriverez sur la page avec le filtre “FabLab” déjà sélectionner! D’ailleurs, afin qu’il soit clair pour l’utilisateur que des filtres sont sélectionnés, ces derniers apparaîtront à côté du titre plutôt que de simplement être cochés dans la colonne de droite. Cette idée m’est d’ailleur venue après un premier test où mon utilisateur a simplement tenté une blague sur le fait qu’il ne retrouvait pas sa case cochée parmi la liste. Cette fonctionnalité permet donc au user de ne pas avoir à chercher ce qu’il doit décocher dans ce menu potentiellement long, mais de pouvoir simplement faire cette action via le dessus de la page.
La touche 'finale':
Une fois la page évènement terminée, il fallait encore régler quelques détails: Comment y arrivait-on, et comment irait-on à l’étape suivante; celle de la planification et/ou payement des activités! Pour cela, une simple page d’accueil avec déjà, une mise en avant d’activités ayant la cote pour attirer l'œil de l’utilisateur servirait la première étape. Pour la seconde, une page à part où l’utilisateur peut exporter son horaire vers google agenda ou en PDF avant de payer pour ses achats en plus d’un rappel des horaires, activités et prix afin de s’assurer que la personne navigant le site soit bien au courant du détails de son achat.
Rux: La conclusion:
Critiquer le site était facile.
Et chacun avait son propre moyen pour y remédier. Pourtant, en soumettant nos idées, nous nous rendions assez souvent compte que quelqu’un dans le groupe de travail avait certains maux vis-à-vis de nos solutions pourtant supposées combler une faille évidente. Pourquoi? Parce qu'en tant que développeur, notre vision de notre propre produit était biaisé! Nous connaissions notre produit, nous savions ce que chaque boutons faisait, donc la navigation de notre interface nous paraissait intuitive, sans pour autant l’être pour les autres.
Si cet atelier m’a appris une chose, c’est de soumettre à l’opinion d’autrui mon produit plus souvent. Car si je suis capable de bonne volonté et de me poser des questions, je ne suis pas capable d’être un autre, et que fatalement, le site que je réalise n’est pas pour moi. Il est capital de se souvenir que quelqu’un d'inexpérimenté dans le domaine du web pourrait arriver sur ma landing page, et que malgré ce handicap, mon site doit pouvoir aiguiller l’utilisateur. Si je ne réalise des sites que pour moi, je finirai par faire des sites qui ne sont pour personne. Tout le contraire de ce qu’il faut, pour atteindre la RéUXite !