Izdihar
RÉSUMÉ
Izdihar est un jeu de plateforme et de puzzle dont j'ai eu le plaisir d'être le porteur de projet lors de mon année de licence 3 à l'école Piktura.
Dans le cadre de ce projet, j'ai organisé et supervisé les séances de playtest.
Cette page détaille ma méthodologie pour gérer et prioriser les retours des utilisateurs.
Dans ce projet, j'ai occupé les rôles de directeur créatif, game designer et UX designer.
Leyna Amies : Character Artist
Adam Aubart : Environment Artist
Ludovic Charlet : Cutscenes
Arthur Hache : Level Designer
Iris Pecquet : Programmer
Elliot Cosneau : Composer
Josh Burne : Sound Designer
Ali : Father's voice actor
Solenn Vollet : Izdihar Voice actress
Rémi Logez : Creative Director
Notre jeu Izdihar a été nominé pour le festival des Pégases dans la catégorie 'Jeu Étudiant de l'année'.
Prioriser les retours utilisateurs sur Izdihar
Lors des playtests d'Izdihar, j'ai eu l'opportunité de gérer les retours utilisateurs. Dans cette section, je partage la méthode que j'ai employée pour organiser et prioriser ces retours, tout en intégrant les contraintes liées à la production.
.jpg)
Je me pose 3 questions
Lors des tests utilisateurs, j’ai utilisé un processus structuré pour déterminer quels problèmes devaient être corrigés en priorité, en fonction de leur impact sur les joueurs. Cette première étape consiste à analyser à quel point le problème gêne ou bloque les utilisateurs dans leur progression.
🤔
Le problème se produit-il sur une core mechanic ?
Si le problème affecte une mécanique centrale du jeu (comme un système de puzzle ou de déplacement), il touche un grand nombre de joueurs et doit être traité en priorité.
😓
Le problème empêche-t-il les utilisateurs de progresser ?
Certains problèmes rendent la progression impossible ou très difficile.
Ce type de problème doit être considéré comme bloquant et donc prioritaire.
😡
Le problème est-il persistant ?
Les problèmes récurrents, qui apparaissent à plusieurs endroits du jeu, sont plus perturbants pour les joueurs et doivent être traités rapidement.
Plutôt que de me fier uniquement à mon intuition, j'utilise un arbre de décision pour garantir que mes priorités sont claires et justifiables. Cela permet de fournir des résultats plus fiables et de faciliter les échanges avec l'équipe.
Interpréter les niveaux de gravité :
Critique
Problème majeur qui empêche les utilisateurs de progresser. Impact direct sur l'utilisation des fonctionnalités principales. 😰
Sérieux
Problème significatif qui ralentit les utilisateurs ou provoque des erreurs régulières, mais ne bloque pas complètement la progression.
Moyen
Problème qui cause de la frustration ou des ralentissements mineurs, mais n'affecte pas de manière critique l'expérience.
Faible
Problème cosmétique ou mineur qui n'empêche pas l'utilisation normale, mais peut affecter la satisfaction générale.
Exemple contextuel
Comme le montre cet extrait d'une joueuse ayant enregistrée sa partie lors de son premier test du jeu, l'un des problèmes rencontrés était que les joueurs ne comprenaient pas toujours que maintenir la touche de saut plus longtemps permettait au personnage de sauter plus haut.
Certainement un problème d'onboarding. 🤫
Le problème est critique car il touche une mécanique centrale, le saut, essentielle à la progression. Les joueurs, ne comprenant pas qu'il fallait maintenir la touche pour sauter plus haut, trouvaient certains puzzles inutilement difficiles. Ce problème est bloquant pour beaucoup et persistant, car il se répète dans plusieurs puzzles, nécessitant une correction prioritaire.
Évaluer l'Impact du Problème sur la Production
Une fois que la gravité du problème est déterminée, il est aussi essentiel d’évaluer l’impact que sa résolution aura sur la production. J’ai donc travaillé en collaboration avec les autres membres de l’équipe pour évaluer le temps et les ressources nécessaires pour corriger chaque problème. Cette étape permet de hiérarchiser les problèmes non seulement par leur importance pour l'utilisateur, mais aussi par la faisabilité de leur correction.
Les tâches sont classées selon trois niveaux d’effort.
Si la gravité d'un problème est souvent évidente, estimer l'effort pour le résoudre peut être plus subjectif. Cela dépend de la complexité technique, des ressources disponibles, et des équipes impliquées.
Faible Effort
Les corrections simples, comme des ajustements visuels ou des bugs mineurs.
Effort Moyen
Des changements un peu plus complexes nécessitant des modifications dans l’interface ou les mécaniques.
Effort Élevé
Des ajustements plus lourds, touchant à la structure du jeu ou aux fonctionnalités majeures.
Classer et Prioriser les Problèmes
En combinant ces deux aspects (gravité et effort), j’ai pu prioriser les problèmes selon leur urgence pour l’utilisateur, mais aussi selon l'effort nécessaire pour les résoudre. Voici comment les problèmes ont été classés dans une matrice de priorisation :
Mise en forme
J'ai utilisé Notion pour regrouper tous les retours des utilisateurs, car c'est un outil simple, accessible et facile à utiliser pour toute l’équipe. Il permet de filtrer, trier et organiser les informations rapidement, ce qui a facilité le suivi des retours et la collaboration avec les autres membres de l'équipe.
L'expérience de travail sur Izdihar m'a permis de comprendre l'importance de bien structurer le processus de collecte et de priorisation des retours utilisateurs. ✨ Grâce à cette approche, j'ai pu contribuer à des améliorations significatives du jeu, tout en prenant en compte les contraintes de production.
Bien que cette méthode soit encore en perfectionnement et adaptée à un projet de petite taille, elle m'a permis d'apprendre énormément sur l'optimisation de l'expérience utilisateur tout en travaillant de façon collaborative avec l'équipe de développement.