User flow pour une tâche dans votre application ou votre site
Cartographiez les écrans et actions qu’un utilisateur traverse pour accomplir une tâche, avec vérifications de connexion, états d’erreur et retours arrière, chaque branche aboutissant quelque part.
Un logigramme d’une seule tâche utilisateur, du point d’entrée jusqu’à chaque succès ou sortie, en passant par vos écrans, actions et conditions. Écrans et vérifications système sont dessinés différemment. Comparez chaque branche, retour arrière et état d’erreur avec vos maquettes.
Réservation d’un cours de yoga avec vérification de connexion et liste d’attente
Point d’entrée
L’utilisateur touche Réserver un cours sur l’accueil de l’appli Yoga Eau Calme
Écrans et actions dans l’ordre
Écran - Liste des cours
Action - touche un cours
Écran - Détail du cours
Action - touche Réserver
Écran - Paiement
Action - paie avec la carte enregistrée
Écran - Réservation confirmée
Conditions et destination de chaque réponse
Connecté ? Non → écran de connexion, puis retour au Détail du cours. Oui → Réserver
Cours complet ? Oui → écran Liste d’attente. Non → Paiement
Points de succès et de sortie
Réservation confirmée ; Inscrit en liste d’attente ; Abandon au paiement
Tunnel de commande avec limite de nouvelles tentatives, retour arrière et noms d’écrans longs
Point d’entrée
Un client connu ouvre son panier depuis l’e-mail de relance sur son téléphone
Écrans et actions dans l’ordre
Écran - Panier avec articles enregistrés et estimation de livraison
Action - touche Commander
Écran - Adresse de livraison et choix du créneau
Action - choisit un créneau
Écran - Paiement avec cartes enregistrées et option nouvelle carte
Action - touche Payer
Écran - Confirmation de commande avec lien de suivi
Conditions et destination de chaque réponse
Adresse toujours valide ? Non → écran Modifier l’adresse, puis retour à Adresse de livraison. Oui → choix du créneau
Paiement accepté ? Oui → Confirmation de commande. Non → écran Échec du paiement, réessayer (deux nouvelles tentatives maximum, puis écran Contacter le support)
L’utilisateur touche Retour sur Paiement → revient à Adresse de livraison, créneau conservé
Points de succès et de sortie
Commande passée ; Renvoyé vers le support après des paiements refusés ; A quitté le parcours depuis n’importe quel écran
Notation ou mise en évidence
Laissé vide
Vérifie que la boucle de nouvelle tentative s’arrête après deux essais et sort vers Contacter le support, que le retour arrière revient au bon écran et que les longs noms d’écrans restent entiers.
Même tâche, trois approches
Choisissez une approche pour commencer.
01
Le chemin idéal d’abord
Le parcours de succès principal tracé en ligne droite, toutes les alternatives s’en détachant, pour une revue rapide avec les parties prenantes.
02
Erreurs et cas limites
La même tâche avec chaque échec, nouvelle tentative et impasse rendus visibles, pour préparer la recette ou une revue de design.
03
Nouveaux et anciens utilisateurs
Deux entrées qui se rejoignent sur un écran commun, pour les tâches où inscription et connexion se séparent avant le parcours principal.
Ce que le modèle conserve
Ce qui reste constant.
01
Écrans et actions bien distincts
Les écrans sont des cases et les actions légendent les passages entre eux : le schéma se lit comme une démonstration pas à pas.
02
Chaque branche a une sortie
Chaque chemin se termine sur une sortie listée ou revient à un écran précédent avec une légende qui explique pourquoi.
03
Vos noms d’écrans
Les noms correspondent à ceux de vos fichiers de design et de vos tickets.
Mode d’emploi
De vos informations au résultat.
01
Choisissez une tâche et son point d’entrée
Réserver un cours, réinitialiser un mot de passe, passer commande. Une tâche par schéma pour qu’il reste lisible.
02
Listez écrans et actions dans l’ordre
Commencez chaque ligne par Écran ou Action pour que le schéma distingue les lieux de ce que fait l’utilisateur.
03
Ajoutez les conditions
Formulez chaque vérification comme une question et indiquez où mène chaque réponse, retours arrière et nouvelles tentatives compris.
04
Nommez chaque sortie, puis relisez dans Vizify
Succès, abandon et erreur. Rien ne se lance avant que vous envoyiez le brief.
05
Comparez chaque branche avec vos maquettes
Suivez chaque chemin jusqu’à une sortie et vérifiez que les noms d’écrans correspondent à vos wireframes.
Limites du résultat
À vérifier avant de l’utiliser.
Le schéma montre le parcours, pas les écrans eux-mêmes. Wireframes, textes d’interface et mises en page ne sont pas dessinés.
Vizify ne teste pas votre application et ne trouve pas les cas limites manquants. Il signale les branches sans destination, pas les chemins que vous n’avez pas mentionnés.
Une tâche par schéma. Plusieurs tâches dans un même diagramme deviennent vite difficiles à suivre.
La mise en page est automatique. Les options d’export sont celles que l’app Vizify propose pour le diagramme.
QuestionsQuelle différence entre un user flow et un wireframe ?+
Un user flow montre l’ordre des écrans et des décisions pour une tâche. Un wireframe montre à quoi ressemble un écran. Utilisez le parcours pour valider le chemin avant de concevoir les écrans.
Comment montrer qu’un utilisateur peut revenir en arrière ?+
Ajoutez une ligne comme « L’utilisateur touche Retour sur Paiement → revient à Adresse de livraison ». Elle devient une flèche légendée vers l’écran précédent.
Ce modèle de user flow fonctionne-t-il pour un site web comme pour une appli ?+
Oui. Les écrans peuvent être des pages, des fenêtres modales ou des étapes de formulaire. Utilisez les noms déjà employés par votre équipe pour que le schéma corresponde à vos tickets.
Et si je ne sais pas ce qui se passe après une erreur ?+
Laissez la question dans le brief. Vizify demande où la branche doit mener au lieu d’inventer un écran d’erreur, ce qui permet de soulever facilement le point avec votre équipe.
