Contexte et objectifs
Dans le cadre de la certification Google UX design, j’ai réalisé cette étude de cas de design d’une application mobile fictive. Mon rôle était celui de l’UX/UI designer, de la recherche utilisateur jusqu’au prototype haute fidélité, en suivant les étapes du Design Thinking. Il s’agit avant tout d’un exercice, destiné à appliquer les concepts clés de l’UX design au fil de l’apprentissage.
Mon choix de prompt (parmi une liste imposée) :
« Concevoir une application qui aide les groupes d’amis ou les familles à gérer leur budget familial et à économiser pour un objectif commun (comme des vacances). »
Recherche utilisateur
Pour la phase de recherche UX, j’ai choisi la méthode du sondage, combinée à de la recherche secondaire.
J’ai soumis à un échantillon varié de personnes de mon entourage un certain nombres de questions pour en tirer des données quantitatives et qualitatives.
Avec ces résultats j’ai pu catégoriser mes utilisateurs en deux groupes distincts, sur lesquels je baserais mes personas :
Groupe A
- 25-34 ans
- à l’aise avec la technologie
- utilisent fréquemment des applis de gestion de dépense
Groupe B
- 35 ans et plus
- moins à l’aise avec la technologie
- n’utilisent pas ou peu d’applis de gestion de dépenses
Points de douleur fréquents
- Motivation des participants
- Applications trop confuses et pas assez attrayantes
- Difficulté ou impossibilité de connecter des outils externes (paiement)
- Information pas assez centralisée
Cartes d'empathie
La cible
Toujours dans la partie Empathie du Design Thinking, j’ai créé, à partir des données issues dans la recherche, et avec l’aide de l’IA générative, deux fiches persona.
Problem statements
- Emma est une voyageuse sociable qui a besoin d’un moyen simple pour planifier et gérer un objectif d’épargne commun, car elle souhaite que son groupe reste organisé et motivé.
- Michael est un père de famille organisé qui a besoin d’un outil simple pour créer et suivre des objectifs financiers communs, car il souhaite que sa famille se coordonne et réalise ses projets ensemble.
User journey map
Idéation
Brainstorming & storyboard
J’ai entamé la phase d’idéation en réalisant un storyboard pour me placer à nouveau dans une posture d’empathie avec l’utilisateur, puis j’ai commencé à noter des idées, des propositions de valeur.
Audit concurrentiel
J’ai réalisé un audit de deux concurrents indirects, les applications Tricount et Splitwise , pour identifier leurs forces, faiblesses, et en extraire des opportunités.
| Tricount | Splitwise | |
|---|---|---|
| Forces | Connexion optionnelle Tutoriel sur la page d'accueil Assez intuitif |
Pages de démo skippables Groupes par types (voyage, habitat, etc) |
| Faiblesses | Peu de fonctionnalités, très simple | Connexion obligatoire dès l'ouverture Manque de transparence sur les dépenses Modèle freemium |
Tricount
Forces :
- Connexion optionnelle
- Tutoriel sur la page d’accueil
- Assez intuitif
Faiblesses :
- Peu de fonctionnalités, très simple
Splitwise
Forces :
- Pages de démo skippables
- Groupes par types (voyage, habitat, etc)
Faiblesses :
- Connexion obligatoire dès l’ouverture
- Manque de transparence sur les dépenses
- Modèle freemium
Opportunités
- Connexion/inscription facultative
- Onboarding léger et skippable
- Projets catégorisés (voyage, cadeau commun, etc)
- Transparence totale sur les dépenses
- Suivi visuel et collaboratif des objectifs communs
- Interface ludique et intuitive
- Ton convivial et engageant
- Gratuité totale
- Interactions de gamifications (badges, rappels, récompenses)
User flow & information architecture
J’ai ensuite créé un user flow pour définir le parcours de l’utilisateur dans l’application…
…puis un sitemap pour organiser et hiérarchiser le contenu.
Wireframes
J’ai réalisé un wireframe des pages du flow principale de l’application, à la main dans un premier temps pour itérer plus facilement et commencer à dégrossir le zoning. Puis je suis passé sur Figma pour réaliser la version digitale, qui a ensuite évolué en prototype basse fidélité.
Test utilisateur
Dans une conception user-centered, tester le prototype basse fidélité est important, car cela permet aux participants de donner des retours honnêtes, et au designer d’itérer en mettant de côté ses biais.
J’ai donc mis en place un UX research plan pour définir l’objectif du test utilisateur, les questions auxquelles on veut répondre, les KPI à mesurer, la méthodologie, l’échantillon des participants (en l’occurrence quelques proches), et le script des tâches à effectuer.
Après le test, j’ai pu en tirer des conclusions pour itérer sur mon prototype.
Insights
- Pas de problème majeur sur le flow principal, la navigation est intuitive
- Hésitations sur les choix du type de projet, donc prévoir une aide et une UI claire sur cette partie
- Hésitations sur la localisation du tchat, et tableau de bord de projet trouvé un peu « confus », donc l’interface de cette page doit être revue, et la navigation par onglet abandonnée
Itération
Design final
J’ai finalement conçu le design system de l’application, la maquette graphique, puis les interactions et la navigation pour en faire un prototype haute fidélité.
Conclusion
📝 Ce projet, de part sa nature fictive et les moyens à ma disposition, m’a contraint à valider mes choix UX avec des données limitées, l’absence de véritables KPI mesurables, un cycle de test réduit…
👍 Malgré cela, j’ai pu approfondir un peu plus mes connaissances en UX/UI, appliquer des nouvelles méthodologies, et créer un produit avec une architecture claire, une expérience utilisateur fluide et un design cohérent.
Train’eat