MOOV MONEY
Moov Money, repensé avec la voix
Redesign de l'application de mobile money et intégration de Moov Assistant, un assistant vocal qui prépare les opérations sans jamais décider à la place de l'utilisateur.
- ANNÉE
- 2026
- RÔLE
- Product Designer UX/UI
- SUPPORT
- Mobile iOS
- FORMAT
- Projet conceptuel
LE PROBLÈME
Moov Money sert chaque jour à envoyer de l'argent, payer, recharger et acheter des forfaits. Mais son accueil est organisé comme un catalogue : solde, actions, services et publicité s'y disputent l'attention, et les transactions récentes, qui disent si l'argent est arrivé, sont reléguées tout en bas.
LA SOLUTION
Un accueil remis en ordre, et un assistant vocal : la voix prépare l'opération, l'utilisateur la valide.
MOOV ASSISTANT
Le bouton flottant ouvre l'assistant par-dessus l'accueil : suggestions en un geste, transcription affichée en direct, puis des propositions à choisir.
CONTEXTE
Une app utilisée tous les jours, qui veut tout montrer en même temps
Moov Money sert à envoyer de l'argent, payer, recharger et acheter des forfaits. L'audit de l'écran d'accueil révèle une interface propre mais organisée comme un catalogue, où le solde, les actions, les services et la publicité se disputent l'attention.
Le projet pose aussi une question plus large : comment intégrer un assistant vocal, Moov Assistant, dans une app financière, sans qu'il décide jamais à la place de l'utilisateur ?
« Mon argent est-il arrivé ? »
Mon rôle : Product / UX / UI Designer, seul sur ce projet conceptuel mené au Bénin en 2026, sur Figma. J'ai conduit l'audit UX, l'architecture, les user flows, les wireframes, le design system, les maquettes haute fidélité, le prototype interactif et le plan de tests.
À noter : projet réalisé à des fins de portfolio, non affilié à Moov Africa. Les données affichées sont fictives.
AUDIT UX
Ce que l'audit de l'accueil a révélé
J'ai évalué l'écran d'accueil actuel sur quatre critères, notés sur 10. La hiérarchie de l'information obtient la note la plus basse.
7/10
Expérience (UX)
7,5/10
Interface (UI)
6,5/10
Hiérarchie de l'information
7/10
Efficacité des tâches fréquentes
Trois problèmes, un point fort
Hiérarchie confuse
Bloc solde surdimensionné, 7 services au même poids visuel, publicité placée avant les transactions.
Informations critiques trop bas
« Mon argent est-il arrivé ? » est la question la plus fréquente, mais les transactions récentes sont tout en bas.
Libellés ambigus
« Plus » flou, noms tronqués, et « Mes services » en double entre l'accueil et la navigation.
À préserver : la navigation
Trois onglets simples (Accueil, Mes services, Mon profil) : un point fort à ne pas casser.
OBJECTIFS ET CONTRAINTES
Faire gagner du temps, sans jamais faire perdre le contrôle
Trois exigences ont guidé chaque décision :
- 1
Simplicité
Moins d'étapes pour les opérations fréquentes, libellés courts et explicites.
- 2
Accessibilité
Niveaux de lecture variés : phrases courtes, icônes toujours libellées, contrastes WCAG AA, zones tactiles de 44 px. La voix aide, mais n'est jamais obligatoire.
- 3
Confiance et sécurité
Montant, frais et bénéficiaire visibles avant paiement. Confirmation explicite et code PIN systématiques.
How Might We
Comment faire gagner du temps aux utilisateurs de Moov Money, à la voix comme au toucher, sans jamais leur faire perdre le contrôle de leur argent ?
ARCHITECTURE ET FLOWS
Garder les 3 onglets, ajouter un raccourci
Les 3 onglets de l'app actuelle sont conservés. Moov Assistant est un raccourci transverse, lancé depuis l'accueil : il accélère les parcours sans les remplacer. Les écrans non documentés dans la version de référence sont marqués comme hypothèses.
Trois user flows, erreurs comprises
Transfert vocal, transfert classique, achat de forfait : chaque flow décrit le parcours nominal et toutes ses issues. Le transfert vocal, le plus critique, se déroule en cinq temps :
- 1
Lancer
Le bouton flottant ouvre l'assistant par-dessus l'accueil.
- 2
Écouter
La transcription s'affiche en direct.
- 3
Clarifier
Intention floue ou plusieurs contacts : l'assistant pose une question.
- 4
Confirmer
Nom vérifié, montant, frais. Correction à la voix ou au crayon.
- 5
Valider
Le PIN valide ; seule la réponse de l'opérateur fixe l'issue.
EXPLORATION
Où placer l'assistant ?
Trois pistes testées en basse fidélité, selon trois critères : visibilité, effort d'accès et respect de la hiérarchie argent → action → vérification. Le bouton flottant l'emporte.
A · Onglet dédié
Écartée
Un 4e onglet sépare l'assistant du reste de l'app : il faut quitter l'accueil pour l'utiliser, et la navigation à 3 onglets disparaît.
B · Bouton flottant
Retenue
Un geste depuis l'accueil, à portée de pouce, sans casser la hiérarchie ni la navigation. Vigilance : ne pas masquer le contenu, d'où un bouton remonté en haute fidélité.
C · Barre de commande
Écartée
Reprend le défaut relevé à l'audit, une barre surdimensionnée en tête d'écran, et repousse le solde. Moins naturelle pour la voix.
Le parcours de l'assistant, en basse fidélité
De l'appui sur le micro à la confirmation, chaque écran suit la même règle : l'assistant comprend, propose, et l'utilisateur garde la décision.
WIREFRAME · 01 OUVERTURE
Bottom sheet par-dessus l'accueil : l'utilisateur garde son contexte. Suggestions en chips pour qui ne sait pas quoi dire, micro en action principale.
DESIGN
Un accueil organisé comme un tableau de bord financier
Argent → action → vérification → découverte → marketing. Même identité visuelle, nouvelle hiérarchie.
Avant
Après
- Barre de recherche retirée du haut d'écran, le solde passe en premier
- Actions principales en icônes simples au lieu d'illustrations chargées
- « Accès rapide » : 4 services prioritaires au lieu de 7, sans nom tronqué
- Transactions récentes visibles dès l'accueil
- Grande bannière publicitaire retirée de la zone principale
- Moov Assistant accessible en un geste depuis l'accueil
Un assistant intégré, pas un chatbot ajouté
Quatre décisions structurent Moov Assistant, chacune au service du contrôle de l'utilisateur :
Décision 1
Montrer ce que l'IA a compris
La transcription s'affiche en direct pendant l'écoute. L'utilisateur vérifie avant toute action, et l'assistant enchaîne seul, sans clic.
Décision 2
Proposer, pas imposer
« Un forfait à 100 francs » peut désigner plusieurs offres : la meilleure est mise en avant, les alternatives et le catalogue complet restent accessibles.
Décision 3
Lever l'ambiguïté par une question
Trois « Hervé » dans les contacts ? L'assistant demande lequel au lieu de deviner, avec la saisie manuelle toujours disponible.
Décision 4
Confirmer qui, combien, et pouvoir corriger
Le nom enregistré chez l'opérateur évite l'erreur de destinataire. Le montant se corrige au crayon ou à la voix, sans recommencer.
Seul le résultat réel fait foi
Un succès n'est affiché qu'après la réponse de l'opérateur. L'échec dit clairement que rien n'a été débité, et le PIN reste séparé de la voix.
Succès
Échec
- Confirmation explicite avant toute opération financière
- Code PIN systématique, jamais remplacé par la voix
- États prévus : chargement, succès, échec, solde insuffisant, en attente
- Demande ambiguë traitée par une question, jamais par une supposition
Des fondations pour passer à l'échelle
Tokens en deux niveaux (primitives et sémantiques) avec mode clair et sombre, composants à variants et propriétés, et un prototype testable couvrant les parcours nominaux et les erreurs.
Inter porte le texte et les montants, Manrope les titres et les libellés.
75+
variables : couleurs, espacements, rayons
13
styles de texte, plus 4 styles d'ombre
12
composants à variants et propriétés
9
flows de prototype testables
Couleurs
- Accent · accent-primary#FF6B00
- orange-50#FFF0E7
- gray-950#0E1222
- Texte · text-primary#111827
- text-tertiary#4B5563
- text-secondary#6B7280
- Bordure · border-default#EAECF0
- Fond · bg-secondary#F6F7F9
- Succès · green-500#10B981
- green-50#E7F9F2
- yellow-50#FFF5E7
- blue-50#EAF0FF
SPÉCIFICATIONS
Des règles d'interaction pour l'équipe de développement
J'ai documenté le comportement attendu de l'assistant. Les valeurs chiffrées sont des cibles de conception, à valider en test et avec les contraintes techniques.
Six principes non négociables
La voix prépare, le PIN valide
La reconnaissance vocale ne sert jamais d'authentification. Toute opération financière exige le code PIN.
Jamais d'exécution sur une transcription ambiguë
Si un paramètre manque ou si la confiance est faible, l'assistant pose une question fermée au lieu de supposer.
Montrer ce qui a été compris
La transcription et l'interprétation sont toujours affichées avant toute proposition d'action.
Toujours une sortie manuelle
Chaque écran de l'assistant offre un chemin classique : contacts, saisie, catalogue, annulation.
Seul le résultat réel fait foi
Un succès n'est affiché qu'après confirmation de l'opérateur. Sinon : échec, ou en attente avec notification.
La voix reste optionnelle
Tout ce qui se dit peut s'écrire ou se faire au toucher. Aucune fonction n'est réservée à la voix.
Intentions prises en charge (V1)
Les prix, soldes et offres viennent toujours du système de l'opérateur, jamais du modèle.
| Intention | Exemple | Si manquant ou ambigu | Confirmation |
|---|---|---|---|
| Transfert d'argent | « Envoie 5000 à Hervé » | « Combien ? » ou liste des contacts correspondants, plus saisie manuelle | Carte récap + PIN |
| Achat de forfait | « Forfait Internet à 100 francs » | Meilleure offre, alternatives et catalogue complet | Carte récap + PIN |
| Solde Internet | « Il me reste combien de data ? » | Sans objet | Aucune (lecture seule) |
| Recharge de crédit | « Recharge 500 sur mon numéro » | « Pour quel numéro ? » | Carte récap + PIN |
| Accès à un service | « Payer ma facture SBEE » | Liste des services proches | Ouvre le parcours classique |
Intention : Transfert d'argent
- Exemple
- « Envoie 5000 à Hervé »
- Si manquant ou ambigu
- « Combien ? » ou liste des contacts correspondants, plus saisie manuelle
- Confirmation
- Carte récap + PIN
Intention : Achat de forfait
- Exemple
- « Forfait Internet à 100 francs »
- Si manquant ou ambigu
- Meilleure offre, alternatives et catalogue complet
- Confirmation
- Carte récap + PIN
Intention : Solde Internet
- Exemple
- « Il me reste combien de data ? »
- Si manquant ou ambigu
- Sans objet
- Confirmation
- Aucune (lecture seule)
Intention : Recharge de crédit
- Exemple
- « Recharge 500 sur mon numéro »
- Si manquant ou ambigu
- « Pour quel numéro ? »
- Confirmation
- Carte récap + PIN
Intention : Accès à un service
- Exemple
- « Payer ma facture SBEE »
- Si manquant ou ambigu
- Liste des services proches
- Confirmation
- Ouvre le parcours classique
Cycle d'une demande et délais cibles
Repos → écoute → transcription → interprétation → clarification si besoin → proposition → confirmation → code PIN → traitement → résultat.
| Règle | Cible | Comportement |
|---|---|---|
| Fin d'écoute automatique | 1,5 s de silence | La transcription se fige et l'interprétation démarre sans action de l'utilisateur. |
| Écoute sans voix détectée | 8 s | Message « Je n'ai rien entendu », micro proposé à nouveau, champ texte mis en avant. |
| Réponse de l'assistant | < 2 s | Au-delà, indicateur « Je cherche… » pour éviter l'impression de blocage. |
| Traitement opérateur | < 10 s | Au-delà, écran « Transaction en attente » avec référence et notification à venir. |
| Correction vocale | Avant le PIN | La carte de confirmation se met à jour en place, sans recommencer le parcours. |
| Code PIN | 3 essais | Après 3 erreurs, blocage temporaire ; durée à définir avec l'opérateur (hypothèse). |
Règle : Fin d'écoute automatique
- Cible
- 1,5 s de silence
- Comportement
- La transcription se fige et l'interprétation démarre sans action de l'utilisateur.
Règle : Écoute sans voix détectée
- Cible
- 8 s
- Comportement
- Message « Je n'ai rien entendu », micro proposé à nouveau, champ texte mis en avant.
Règle : Réponse de l'assistant
- Cible
- < 2 s
- Comportement
- Au-delà, indicateur « Je cherche… » pour éviter l'impression de blocage.
Règle : Traitement opérateur
- Cible
- < 10 s
- Comportement
- Au-delà, écran « Transaction en attente » avec référence et notification à venir.
Règle : Correction vocale
- Cible
- Avant le PIN
- Comportement
- La carte de confirmation se met à jour en place, sans recommencer le parcours.
Règle : Code PIN
- Cible
- 3 essais
- Comportement
- Après 3 erreurs, blocage temporaire ; durée à définir avec l'opérateur (hypothèse).
PLAN DE TESTS
Valider l'assistant avant le développement
Les tests restent à mener. J'ai préparé un test modéré sur le prototype Figma, à Cotonou et Porto-Novo, pour vérifier une chose : l'assistant fait-il gagner du temps sans jamais faire perdre le contrôle ?
- 1
Ce qu'on veut apprendre
- Comprend-on qu'on peut parler à l'app ?
- Fait-on confiance au récapitulatif ?
- Sait-on corriger une erreur ?
- L'accueil est-il plus clair que l'actuel ?
- 2
8 participants, 18 à 55 ans
4 utilisateurs quotidiens de Moov Money, 4 moins à l'aise avec l'écrit. Cotonou et Porto-Novo, Android et iPhone.
- 3
30 min, en présentiel
Think-aloud sur prototype, tâches en ordre alterné, questionnaire SUS et note de confiance. Comparaison avec l'app actuelle sur 2 tâches.
Scénarios de test
| # | Scénario donné au participant | Parcours testé | Ce qu'on observe |
|---|---|---|---|
| T1 | « Votre cousin Hervé vous demande 5 000 F. Envoyez-les. » | Transfert vocal, contact ambigu | Choix du bon Hervé, lecture du nom vérifié, temps total |
| T2 | « Vous vous êtes trompé, c'était 10 000 F. Corrigez avant de payer. » | Correction vocale ou crayon | Méthode choisie, réussite sans recommencer |
| T3 | « Achetez un forfait Internet pour 100 F. » | Forfait vocal et suggestions | Compréhension de la meilleure offre face aux alternatives |
| T4 | « Faites la même chose sans parler. » | Forfait ou transfert classique | Découverte des sorties manuelles |
| T5 | « Le transfert n'est pas passé. Que s'est-il passé pour votre argent ? » | Écran d'échec | Compréhension que rien n'a été débité |
# : T1
- Scénario donné au participant
- « Votre cousin Hervé vous demande 5 000 F. Envoyez-les. »
- Parcours testé
- Transfert vocal, contact ambigu
- Ce qu'on observe
- Choix du bon Hervé, lecture du nom vérifié, temps total
# : T2
- Scénario donné au participant
- « Vous vous êtes trompé, c'était 10 000 F. Corrigez avant de payer. »
- Parcours testé
- Correction vocale ou crayon
- Ce qu'on observe
- Méthode choisie, réussite sans recommencer
# : T3
- Scénario donné au participant
- « Achetez un forfait Internet pour 100 F. »
- Parcours testé
- Forfait vocal et suggestions
- Ce qu'on observe
- Compréhension de la meilleure offre face aux alternatives
# : T4
- Scénario donné au participant
- « Faites la même chose sans parler. »
- Parcours testé
- Forfait ou transfert classique
- Ce qu'on observe
- Découverte des sorties manuelles
# : T5
- Scénario donné au participant
- « Le transfert n'est pas passé. Que s'est-il passé pour votre argent ? »
- Parcours testé
- Écran d'échec
- Ce qu'on observe
- Compréhension que rien n'a été débité
Critères de réussite
| Métrique | Mesure | Seuil |
|---|---|---|
| Réussite des tâches | Tâche terminée sans aide du modérateur | ≥ 85 % sur T1 à T4 |
| Opérations non voulues | Paiement validé par erreur | 0, critère bloquant |
| Temps d'un transfert vocal | Du tap sur le bouton flottant au succès | Inférieur au transfert classique actuel |
| Confiance avant paiement | « Je sais exactement à qui et combien j'envoie », note de 1 à 5 | Moyenne ≥ 4 |
| Utilisabilité globale | Questionnaire SUS | Score ≥ 75 |
| Compréhension de l'échec | Réponse correcte à « Avez-vous été débité ? » | 100 % |
Métrique : Réussite des tâches
- Mesure
- Tâche terminée sans aide du modérateur
- Seuil
- ≥ 85 % sur T1 à T4
Métrique : Opérations non voulues
- Mesure
- Paiement validé par erreur
- Seuil
- 0, critère bloquant
Métrique : Temps d'un transfert vocal
- Mesure
- Du tap sur le bouton flottant au succès
- Seuil
- Inférieur au transfert classique actuel
Métrique : Confiance avant paiement
- Mesure
- « Je sais exactement à qui et combien j'envoie », note de 1 à 5
- Seuil
- Moyenne ≥ 4
Métrique : Utilisabilité globale
- Mesure
- Questionnaire SUS
- Seuil
- Score ≥ 75
Métrique : Compréhension de l'échec
- Mesure
- Réponse correcte à « Avez-vous été débité ? »
- Seuil
- 100 %
CRITÈRE BLOQUANT
Zéro paiement validé par erreur. Un seul suffit à conclure que l'assistant n'est pas prêt.
Hypothèses à valider
Formulées pendant la conception, à confirmer ou invalider par les tests et avec l'opérateur.
H1 · Le bouton flottant est découvert
Sans explication, au moins 6 participants sur 8 identifient le bouton comme l'assistant.
H2 · Le nom vérifié rassure
Afficher le nom enregistré chez l'opérateur réduit les hésitations avant le paiement.
H3 · La voix est préférée pour le transfert
Les utilisateurs moins à l'aise avec l'écrit choisissent spontanément la voix.
H4 · Remonter les transactions est utile
Les participants vérifient un envoi récent plus vite que sur l'app actuelle.
H5 · Écrans non documentés
Contenu de l'onglet Profil et règles de blocage du PIN à confirmer avec Moov Africa.
H6 · Qualité de reconnaissance
Compréhension suffisante avec les accents locaux et le bruit de la rue, à mesurer techniquement.
Design final
RÉFLEXIONS FINALES
Dans une app financière, l'IA doit réduire l'effort, pas la vigilance.
Ce que j'ai appris : chaque raccourci vocal doit garder un point de contrôle humain : la voix prépare, le PIN valide. Le contexte local change le design : numéros au format béninois, homonymes fréquents dans les contacts, nom vérifié chez l'opérateur. Et placer l'assistant a été une décision d'architecture avant d'être une décision visuelle : un onglet dédié ou une barre de commande auraient cassé la hiérarchie que l'audit validait.
Prochaines étapes : mener le plan de tests avec son critère bloquant ; mesurer la qualité de reconnaissance vocale avec les accents locaux et le bruit ; explorer le Fon et le Yoruba, ainsi que la lecture vocale du récapitulatif ; valider avec l'opérateur les écrans non documentés (profil, blocage du PIN).
Limites : projet conceptuel, non affilié à Moov Africa, avec des données fictives. Aucun test utilisateur n'a encore été mené : les décisions et les délais cibles restent des hypothèses à valider.