Que fait UX produit axée sur les tâches ?
Commencez par la situation de l'utilisateur et le résultat visé. Les systèmes de design, les recherches et les maquettes fournis sont des preuves ; ne les remplacez pas par un tableau de bord générique. Lisez les modèles et contre-exemples pour le type de tâche pertinent, pas tous les modèles.
Avant de construire un écran
Pour chaque rôle/tâche principal, identifiez le déclencheur, les informations déjà connues, les décisions à prendre, le résultat de l'achèvement et le chemin de récupération. Séparez les workflows spécifiques à un rôle lorsque leurs décisions diffèrent ; partagez les écrans lorsque la tâche et le contexte correspondent vraiment.
Produisez un flux compact et une maquette basse-fidélité proportionnels au changement. Pour chaque état de région visible :
- Quelle décision ou action de l'utilisateur en a besoin maintenant ?
- Est-ce principal, détail contextuel ou inutile dans cette vue ?
- Quelle exigence, source ou décision de conception explicite le justifie ?
Utilisez cela pour sélectionner les informations, pas pour générer plus de copie produit. N'ajoutez pas automatiquement de cartes d'aperçu, de graphiques, de bannières, de filtres, de navigation, d'explications IA ou de panneaux « à venir ». Une métrique a sa place lorsque quelqu'un prend une décision pertinente avec elle. La provenance technique peut avoir sa place lorsque nécessaire pour juger de la fraîcheur ou de la validité ; les journaux de débogage et le statut d'implémentation appartiennent généralement aux enregistrements de développement.
Ne minimisez pas aveuglément. Conservez les instructions d'accessibilité, les erreurs significatives, le contexte essentiel, les divulgations requises et les conséquences des décisions. Une action principale est un défaut utile, pas une limite arbitraire à un seul bouton. Évitez de cacher des actions importantes derrière des menus génériques uniquement pour réduire les contrôles visibles.
État et interaction
Modélisez les états pertinents : initial, chargement, vide, échec, succès, édition/non sauvegardé, résultat obsolète et contraintes de permission. Utilisez uniquement les états dont le produit a besoin. Faites en sorte que les entrées sélectionnées et les résultats affichés se réfèrent au même contexte. Préservez le travail de l'utilisateur sur les erreurs récupérables. Choisissez des actions explicites là où des changements silencieux surprendraient l'utilisateur.
Lors de la sélection d'une surface d'édition ou du changement de mises en page avec état, lisez sélection du motif d'interaction. Choisissez l'édition en ligne, une boîte de dialogue ou une page dédiée en fonction de la complexité de la tâche, de la fréquence, des besoins contextuels et de l'espace disponible ; n'utilisez pas de modale simplement pour cacher un bug de mise en page. Vérifiez la position avant/après, le défilement et le focus des contrôles significatifs. La divulgation intentionnelle peut déplacer du contenu ; les sauts accidentels ou les cibles qui disparaissent nécessitent une correction.
Utilisez les jetons, composants, langage et conventions d'accessibilité du projet. Inspectez une référence fournie via un outil pris en charge disponible ; l'absence de Figma MCP n'est pas en soi une raison d'arrêter. Ne qualifiez jamais une conception non inspectée de correspondante. N'introduisez pas une nouvelle bibliothèque de composants simplement pour un petit changement.
Vérifiez les noms et descriptions accessibles dans les états valide/erreur/récupéré, pas seulement la visibilité visuelle et le focus. Un message caché peut toujours être exposé lorsqu'il est référencé par une description accessible ; connectez le texte d'erreur uniquement lorsque l'erreur s'applique.
Réviser le flux rendu
Utilisez un outil de navigateur ou d'application disponible pour effectuer la tâche à partir de son point d'entrée réel. Inspectez la structure pour les étiquettes et les contrôles, et les captures d'écran rendues pour la hiérarchie, le recadrage, l'espacement et les états visuels. Les vérifications automatisées d'accessibilité ou DOM seules ne prouvent pas la qualité visuelle ou d'utilisabilité.
Pour les vérifications réactives, confirmez les dimensions réelles de la fenêtre du navigateur et inspectez l'image capturée finale. Recadrer une capture d'écran, modifier la largeur d'un élément ou vérifier le débordement horizontal seul n'est pas un test de fenêtre équivalent. Si l'outil ne peut pas définir ou vérifier la fenêtre, marquez cette couverture comme non vérifiée. Conciliez la capture d'écran avec le résultat rapporté : un contenu manquant, un retour à la ligne inutilisable ou des actions invisibles ne peuvent pas être appelés un succès visuel simplement parce qu'une vérification DOM a réussi.
Pour chaque constat, enregistrez : reproduction → comportement observé → impact utilisateur → plus petite correction utile → revérification. Séparez l'inférence de l'observation. Préférez supprimer, déplacer, consolider ou améliorer les valeurs par défaut avant d'ajouter des explications. Ne répétez pas une revue réussie à moins que des changements ou des préoccupations persistantes ne la justifient.
Si l'accès au navigateur n'est pas disponible, révisez les preuves de code/mise en page et marquez l'UX d'exécution comme non vérifiée ; continuez le travail indépendant. Ne fabriquez pas de captures d'écran, de clics ou de validation utilisateur. La revue du développeur ou de l'agent n'est pas une étude utilisateur.