Introduction — Le test utilisateur.
Le Festival du KIKK, qui consiste en de multiples conférences ça et là dans tout Namur, se déroulait au début du mois de Novembre. Cette conférence est munie, comme tout événement de son propre site web, mais serait-il possible que celui-ci soit très mal optimisé, et ne prenne pas suffisamment en compte l’expérience utilisateur ? C’est grâce à l’atelier RUX que nous obtiendrons une réponse.
Tout commence par un test utilisateur du site web, avec une certaine démarche à suivre. le test consistait à sélectionner une conférence à laquelle assister, en choisir une autre et obtenir des informations sur les deux conférences.
Au départ, je voulais faire le test avec mon meilleur ami, Pierre, et avec mon petit ami, Nicolas. sachant qu’ils ont tous les deux des comportements et des réactions assez différentes — Nicolas avait tendance à plus facilement s’énerver et abandonner face à l’échec, tandis que Pierre était plutôt du genre à réfléchir et trouver une solution calmement — Je me suis dit qu’il serait intéressant de tester les deux et de voir s’ils en penseraient la même chose.
Malheureusement, l’échéance du test était au 31 octobre car la conférence qu’il fallait sélectionner se déroulait ce jour-là, or je ne pouvais pas voir Pierre avant début Novembre, je dus donc abandonner. Il n’empêche que je lui en fis part et lui fit essayer, en dehors des consignes à suivre, afin d’obtenir son ressenti. Quoi qu’il en soit, nous en pensions tous les trois la même chose : « C’est mô foutu » .
1 — Transition au papier.
Les cours reprennent, l’atelier reprend et je forme un groupe avec de nouvelles personnes avec qui je m’entendrai tout de suite très bien. À ce sujet, je décidai de changer de groupe depuis Storyshop, un précédent atelier, suite à un manque crucial d’organisation et de communication. Cela ne serait pas le cas avec ce groupe, et, à l’heure où j’écris ces mots, nous avons formé une véritable amitié : l’organisation et la communication seraient au cœur de notre groupe, et en toute honnêteté, c’était on-ne-peut-plus agréable d’avoir des camarades sur qui l’on pouvait compter et en qui on pouvait avoir confiance pour travailler et remettre les travaux avant les dates de remise finale.
L’intégralité de cet atelier était de nous faire réfléchir à différentes manières de résoudre un problème et de l’optimiser un maximum pour rendre le site/l’application plus agréable et plus facile à utiliser. C’est dans cette optique que mon groupe allait s’organiser pour réaliser nos prototypes papiers, sur bases de nos User Journeys et de nos audits, pour améliorer le site du KIKK et de le rendre bien plus pratique.
Concernant ces User Journeys, nous en réalisâmes un nombre assez conséquent, afin de couvrir l’intégralité des problèmes que les gens puissent rencontrer : par exemple, j’inventa une personne plus âgée avec une acuité visuelle plus faible, ou encore une personne ayant des difficultés à se déplacer, et ainsi de suite. De ces résultats débouchèrent des « pain points » dont nous parvînmes à nous débarrasser d’une manière ou d’une autre. Ces personnes, d’ailleurs, utilisaient également des écrans de tailles différentes, pour s’assurer que notre réflexion s’étende plus loin que la version desktop.
2 — Un atelier productif et récréatif.
Chacun d’entre nous avait sélectionné une fonctionnalité sur laquelle on allait travailler : Guillaume s’occupait du calendrier, Marie et Sylvian des conférences, Florian, je ne sais pas exactement, et moi, du système de tickets. Chacune de ces fonctionnalités sera améliorée et, in fine, si nous rassemblions tous nos prototypes, nous aurions un site fonctionnel, bien plus pratique que celui d’origine.
Grâce au matériel mis à notre disposition, c’est-à-dire plusieurs paires de ciseaux, un bloc de feuilles vierges en format A4 ainsi qu’un ensemble d’équerres et de lattes, nous réalisions nos premiers prototypes papiers, qui furent très anarchiques, mais qui soulevèrent de nombreux problèmes d’UI, par exemple : « comment les prix doivent-ils être organisés ? » , « Comment montrer toutes les conférences sans avoir un scroll incroyablement long mais tout en ayant un peu d’informations sur chacune d’entre elles ? » , « Le calendrier peut-il être mieux agencé ? » , Que nous parviendrons à résoudre dans nos prototypes finaux.
Dès le premier jour, nous imaginions plusieurs moyens pour rendre l’atelier récréatif : Florian apportait du carton dans lequel nous avions découpé la forme d’un très gros téléphone, afin d’y mettre nos interfaces mobiles et de s’assurer qu’elles fonctionnaient convenablement. Il en réalisera une seconde version plus tard mais nous n’utiliserons pas cette dernière.
3 — le panier et la liste de souhaits.
À l’origine, j’imaginais simplement offrir à l’utilisateur la possibilité de classer les tickets selon une certaine hiérarchie, celle-ci soit-elle la croissance ou la décroissance du prix, la disponibilité des tickets ou encore la popularité de ces derniers. En plus de ça, j’ai décidé de partir pour des prix standardisés pour chaque conférence, mais cela me posera un problème fondamental pour les prototypes suivants, que je devrai complètement modifier. J’avais pensé, à ce moment-là, à proposer une option pour montrer les différents prix selon une colonne de prix ou une ligne, mais je finis par abandonner cette idée, la considérant comme frivole à ce niveau de développement, sans compter qu’elle portait plus sur l’aspect esthétique plutôt que la fonctionnalité même sur laquelle je travaillais.
Par la suite, je m’inspirai des sites que j’utilise fréquemment pour acheter en ligne, ainsi que d’autres sites qui proposent des places de pièces de théâtre ou de tickets de visite, pour rajouter une fonctionnalité qui me semblait extrêmement utile au début : une liste de souhaits.
L’utilisateur pourrait stocker les tickets qu’il voulait dans un panier virtuel, temporaire, avant de les placer dans son panier pour les payer via son mode de paiement favori.
4 — Le début de la fin.
Et c’est là que commencent les problèmes, relevés par mon professeur : quelle est l’utilité d’avoir une liste de souhaits si les prix sont standardisés ? Qui plus-est, quelle est l’utilité de classer les prix, s’il n’en existe que 3 variantes ? Je devais donc complètement repenser au fonctionnement, et voici ce je pensai :
tout d’abord, les prix standardisés (c’est-à-dire le prix d’une conférence, le prix d’une journée de plusieurs conférences, et ainsi de suite) seraient simplement à valeur informative : l’utilisateur désirant s’informer davantage sur le ticket était renvoyé sur une page montrant toutes les conférences, classées selon un certain ordre sélectionnable, soit-il, à nouveau, la croissance, la décroissance, la disponibilité, etc. Par exemple, dans le cas des tickets pour des conférences individuelles, la page fait donc charger une liste comprenant l’intégralité des conférences (celles-ci étant overbookées ou déjà passées seraient donc grisées). La liste de souhaits n’était donc plus utile pour toutes les interfaces, et pouvait se trouver redondante face au panier qui servait quasiment la même utilité, je décidai donc de m’en débarrasser pour la version finale.
Pour chaque prototype que je réalisais, j’en faisais également la version mobile, ce qui me permettait d’avoir une différente perspective sur les fonctionnalités. Par exemple, cela me permit de découvrir qu’un burger menu comprenant des raccourcis tels que « voir mon panier » , « retour à la page d’accueil » , serait assez pratique.
Durant les derniers jours de l’atelier, de moins en moins de étudiants se rendaient en cours, et donc nous nous rassemblions tous autour d’une même table, indépendamment de nos groupes. Non seulement c’était plus agréable mais aussi plus pratique car le feedback obtenu entre chaque prototype était beaucoup plus varié et permettait vraiment d’améliorer nos interfaces. Un point assez intéressant à noter est que plus je faisais de prototype, plus l’information était triée et compactée en un minimum d’espace : là où, dans mon premier prototype, je proposais beaucoup plus de pages complètes avec trop d’information, parfois inutile, mon dernier prototype ne consistait qu’en une seule page, avec des éléments modulaires qui venaient se mettre par-dessus, comme le burger menu, par exemple. Cela montre que les tests utilisateurs ont une véritable valeur informative qu’il faut considérer avec beaucoup d’importance.
5 — La transition au Web.
Après avoir réalisé ma cinquième version du prototype, comprenant les versions mobiles et desktop, il ne me restait plus qu’à rédiger mon case-study, dont lequel je craignais déjà l’intégration, notamment pour le temps perdu à dupliquer les images et les avoir en Retina. Je réfléchissais à différentes tactiques pour moi faire ça assez rapidement, notamment en passant par Adobe Lightroom et mettre toutes mes images dans un catalogue et les exporter avec comme suffixe @2X en augmentant la taille de deux, ou l’inverse ; ou encore à tout faire dans Photoshop d’un coup, ce qui serait une option plus résiliente, mais plus chronophage ; ou encore de fouiller le web pour obtenir un programme qui permettrait de faire ça rapidement et efficacement.
Finalement, suite au cours de compression numérique, j’opterai pour Photoshop, qui me permettra d’exporter pour le web, tout en ayant un feedback visuel en direct ainsi que le poids des images.
Après, concernant l’aspect esthétique du site web,je n’avais pas d’idée particulière en tête, tout simplement l’envie d’avoir un site ressemblant à Medium, avec une nav permettant à l’utilisateur de se déplacer entre les chapitres (ce qui souleva la question de si je devais instaurer un deuxième rapport hiérarchique avec des sous-titres). Pour les photos, je pensais les mettre dans le corps de texte, légèrement sur la gauche ou sur la droite, avec une petite légende en dessous. L’idéal serait de les démarquer grâce à une touche de couleur, un peu comme le site DWM utilise le jaune, ou Google utilise le bleu.
Alors que j’étais en train d’intégrer le site web, d’y rajouter les images, les vidéos, de trouver un style qui me correspondait, je voulais absolument avoir un burger menu simple et qui fonctionne, mais voilà que je me retrouve face à un compromis : le bouton, qui vraisemblablement est blanc sur fond noir, devient blanc sur fond blanc lorsque l’on scroll plus bas dans le texte. À la base, il s’agit d’un problème de design et devrait devenir noir quand le fond derrière devient blanc.
D’un autre côté, le fait qu’il disparaisse après être descendu plus bas dans le menu permet à l’utilisateur de se concentrer uniquement sur le corps de texte sans avoir le petit artefact visuel le dérangeant dans sa lecture, mais il devrait toutefois scroller jusqu’en haut à nouveau pour sélectionner un chapitre à lire.
Après moult recherches sur Internet et de nombreuses tentatives vaines de réaliser un menu complètement opérationnel, je décidai d’opter pour un burger menu qui descend jusqu’en bas, afin de permettre au lecteur d’utiliser la nav à n’importe quel moment, ce que je trouvai optimal non seulement pour le tester tout en codant, mais aussi pour rendre la navigation bien plus rapide et plus efficace qu’un très long scroll (par exemple, pour les utilisateurs qui liraient en plusieurs jours). Le bouton change de couleur en fonction de sa position dans le scroll, le rendant visible à tout moment.
Puisque les intégrations respectives d’IOLCE, un autre atelier, et de RUX étaient simultanées, j’en profitai pour partager certains éléments entre les deux travaux, notamment ce système de burger menu. Cela me fit gagner un temps considérable que j’utiliserai afin de perfectionner les deux sites et de leur donner leur propre touche visuelle respective.
En conclusion, RUX me fit découvrir à quel point réaliser des User Journeys, des User tests et des audits obtenir du feedback était important, et qu’il fallait d’abord réfléchir aux fonctionnalités plutôt que directement penser au design. C’est en réfléchissant de cette manière que nous parvînmes à « corriger » et améliorer le site du KIKK.