Contexte
Découverte et amélioration de l'app Wiki pour la création de pages
Certaines parties de cette étude de cas sont des aperçus afin de préserver la confidentialité de l'entreprise.
Rôles et durée
En mars 2023, j'ai enseigné l'anglais bénévolement dans une école élémentaire en Thaïlande, ce qui a éveillé mon intérêt pour l'enseignement et m'a conduit à postuler comme Product Designer dans la EdTech. Mon travail sur l'étude de cas lors du recrutement a convaincu l'entreprise de m'engager. Entre février et avril 2024, j'ai collaboré avec le Product Manager pour amener ce projet en phase de développement.
Challenges
D'après l'étude de cas, Wiki est "une app utilisée pour créer des supports de cours, articulant plusieurs pages et intégrant du contenu multimédia. La page d'accueil du Wiki est souvent utilisée comme un index référençant l'ensemble des pages créées dans le Wiki". Le brief demandait une analyse du Wiki et des propositions d'amélioration de l'ergonomie via des maquettes, tout en assurant une cohésion avec le reste de la plateforme.
En interne, mes challenges étaient d'intégrer les solutions proposées lors de mon recrutement avec les évolutions de l'app, et d'aider à la prise de décision avec le Product Manager pour le passage en delivery.
Design process
I. Compréhension et définition du problème
Audit UX & UI de l'app
J'ai d'abord testé le Wiki en me plaçant dans la peau d'un enseignant novice sur l'app, essayant de créer des contenus pédagogiques et de réaliser les actions courantes d'un enseignant. Ensuite, j'ai effectué un second test en tant que designer. J'ai synthétisé les résultats dans une grille d'évaluation avec des critères de criticité.
Key findings
Trois principaux problèmes avec l'app :
1. Le positionnement de l'app n'est pas clair : les descriptions affichées dans l'empty state, sur les pages du support utilisateur, et même dans le brief de l'étude de cas, diffèrent. Selon l'empty state, le Wiki semble être conçu pour créer une encyclopédie libre, à l'image de Wikipédia, avec des contenus "à plat", sans liens ni sous-parties.
2. L'organisation des pages créées manque de flexibilité et d'automatisation : l'app ne permet pas aux utilisateurs de modifier facilement l'ordre des pages ou de créer des sous-parties (cf. vue "Liste des pages").
De plus, les utilisateurs doivent manuellement créer un index/sommaire des pages sur la page d'accueil du Wiki, une tâche fastidieuse, alors que la création automatique de sommaires est un standard courant dans les outils informatiques (cf. sommaire automatique dans Word).
3. Au delà de la direction artistique vieillissante, l'interface utilisateur manque d'ergonomie : par exemple, certains éléments ont la même apparence mais des comportements différents (ex. : le bouton "Nouvelle page" pour créer une nouvelle page vs. les éléments "Page d'accueil" et "Liste des pages" pour changer de vues). De plus, le bouton "Commenter" est situé en haut à droite, alors que l'utilisateur doit aller en bas du contenu pour écrire un commentaire.
Expérimentation et définition du First Use Case
J'ai utilisé mon expérience en enseignement pour identifier le First Use Case. Par exemple, lors de la création d'un cours sur la construction grammaticale d'une question en anglais, j'ai constaté qu'un apprenant devait d'abord comprendre des concepts tels que les auxiliaires et les verbes. J'ai donc dû restructurer mon cours pour ajouter des pages en amont, ce qui était difficile à faire dans le Wiki.
Key findings
L'audit, mon observation des enseignants en Thaïlande, et mon expérience m'ont permis de comprendre que :
- Les professeurs ont généralement très peu de temps pour créer des supports de cours, étant déjà très sollicités par la préparation, l'animation et le suivi de leurs cours et évaluations. La plupart utilise des manuels scolaires et des polycopiés.
- Des Wikis sans index, donc sans structure clairement identifiable, compliquent l'apprentissage pour les élèves, ce qui peut augmenter le taux d'abandon de l'application.
- Je dois donc faciliter la création de cours interactifs, structurés et reliés entre eux.
II. Idéation de solutions
Benchmark d'acteurs
J'ai analysé des acteurs de la EdTech tels qu'OpenClassrooms et Coursera, mais j'ai surtout examiné des éditeurs de logiciels de bureautique comme Notion, OneNote et Coda, qui, bien que non spécialisés en éducation, offrent une grande flexibilité pour la création de contenus.
Key findings
Cette analyse m'a conduit à proposer l'ajout d'une fonctionnalité de création de "sous-pages" pour faciliter l'organisation des cours. Je me suis inspirée des pratiques les plus simples de ces outils, en évitant les complexités de Notion qui peuvent ralentir la prise en main.
Ces plateformes m'ont également inspirée pour l'UX writing et pour la mise en place d'une fonctionnalité de glisser-déposer pour réorganiser les pages et insérer une page dans une autre.
Sketches sur papier
J'ai utilisé une méthode de la designer Chunbuns pour concevoir les premiers user flows et sketches sur papier. J'ai défini les objectifs qu'un enseignant pourrait vouloir atteindre dans l'app (créer une page, une sous-page, les déplacer, etc.) et les actions nécessaires pour y parvenir (task flow). J'ai ensuite positionné les éléments représentant ces actions dans des écrans.
Wireframes haute fidélité pour le web et l'app mobile
J'ai réalisé des wireframes haute fidélité pour la version web et l'app mobile sur Figma, en respectant le style graphique de l'entreprise. J'ai créé un prototype pour permettre à l'entreprise de mieux visualiser l'expérience globale proposée.
Key findings
Pour les actions principales (création de pages et de sous-pages), j'ai choisi de permettre la création depuis le sommaire à gauche, comme le font de nombreux éditeurs de logiciels, mais aussi depuis le contenu, avec deux boutons bien visibles en bas à droite. Cette approche vise à s'adapter au niveau des enseignants, qui pourraient ne pas penser à chercher les petits boutons "plus" dans le sommaire.
Finalisation en interne et maquettage avec le design system
Lorsque j'ai repris ce projet en interne avec le Product Manager, plusieurs étapes restaient avant de passer à la phase de delivery :
- Revue des nouvelles fonctionnalités et évolutions à intégrer avec le Product Manager.
- Trois principales problématiques demeuraient :
- Emplacement des call to actions : Créer et modifier une page ou une sous-page devait être intuitif mais aussi et cohérent avec les autres apps de la plateforme.
- Fonctionnalité "Liste des pages" : Déterminer si elle doit être conservée, où la positionner et comment la rendre plus intéressante.
- Page d'accueil : Décider si elle doit rester fixe en première page ou être une page classique que l'utilisateur peut déplacer.
Globalement, il fallait intégrer ces nouveautés avec l'existant de manière fluide et sans alourdir l'app. J'ai maquetté plusieurs propositions et sélectionné les deux meilleures. J'ai ensuite présenté à l'équipe Produit les avantages et inconvénients de chacune, ce qui nous a permis de voter et de valider les derniers points.
Résultats & Apprentissages
Approbation pour le développement et acquisition d'un client
En allant au-delà du brief initial et en proposant une vision produit centrée sur la création de cours, j'ai grandement contribué à la création d'un LMS simplifié et adapté à l'éducation. Cela a permis de passer à la phase de développement et a aidé à l'acquisition d'un nouveau client régional.
Désormais, la solution facilite la création de pages et sous-pages, ainsi que la gestion de leur ordre, avec une structure claire et visible en un coup d'œil
Avec le Product Manager, nous avons ajouté la fonctionnalité "Visible pour tous" enregistrant une page en brouillon, offrant ainsi plus de flexibilité aux enseignants.
Apprentissages clés
Grâce à l'expérience acquise sur d'autres projets internes, ce projet s'est déroulé de manière fluide. En effet, j'ai gagné en rapidité dans le maquettage et en clarté dans la présentation des différentes pistes de solutions, facilitant la prise de décision sur les derniers éléments du projet.
