Interface d'application confuse : repérez la rupture du parcours

Pour diagnostiquer une interface d’application confuse, examinez ses écrans, ses commandes et ses réponses pendant qu’une personne essaie d’accomplir une tâche prise en charge par l’application. Repérez le premier endroit où l’action suivante devient ambiguë. Comparez ce que la personne attend avec ce que l’application fait et signale. Un échec d’enregistrement ou une fonctionnalité manquante exige une correction différente de celle d’un libellé ou d’un parcours ambigu.

Imaginez qu’une personne essaie de modifier une réservation existante. Elle ouvre plusieurs menus, revient à l’écran d’accueil et demande de l’aide à un collègue. Cette séquence constitue le point de départ d’une observation. À elle seule, elle ne peut expliquer ni si la personne désinstallera ensuite l’application, ni quel écran doit être repensé.

Pourquoi perd-on l’étape suivante dans une interface d’application confuse ?

Une personne peut comprendre l’objectif tout en manquant une action ou une réponse ambiguë. Nous cherchons le premier décalage visible entre la tâche qu’elle souhaite accomplir et l’écran qu’elle rencontre. Ne concluez pas avant d’avoir vérifié l’opération. Ce qui ressemble à un problème de navigation peut aussi être une requête échouée ou un résultat que le produit ne prend pas en charge.

La formulation suggère une autre action. Après avoir appuyé sur Continuer, une personne peut s’attendre à voir un autre écran de vérification, alors que l’application envoie immédiatement une demande. Les recommandations d’Apple sur les boutons préconisent d’en clarifier la fonction. Comparez l’attente à l’effet réel avant de choisir un libellé de remplacement.

Le résultat reste incertain. Une personne appuie de nouveau parce qu’elle ne sait pas si l’application a accepté la demande. Examinez ce qui a réellement été enregistré et ce que l’écran a signalé. Une confirmation manquante et une opération échouée nécessitent des corrections différentes.

Les consignes de saisie arrivent après l’erreur. Vérifiez si le champ explique la valeur attendue.

Pour le contenu web, le critère du W3C relatif aux étiquettes ou instructions exige des étiquettes ou des instructions lorsque le contenu requiert une saisie. Utilisez cette référence pour les écrans web intégrés à une application. Les applications natives nécessitent un examen distinct propre à la plateforme.

Le parcours perd son contexte. Une personne revient d’un écran de détail et ne retrouve pas l’élément qu’elle modifiait. Consignez ce point de départ, l’action choisie et l’écran obtenu. Décrivez la première transition confuse assez précisément pour pouvoir la reproduire.

Comment diagnostiquer une interface d’application confuse ?

Commencez par un résultat pris en charge et un état initial comparable. Utilisez un compte de test et des données de test sûres pour les actions qui envoient, facturent, suppriment ou affectent quelqu’un d’autre. Formulez l’objectif sans nommer le menu ou la commande qui permet de l’atteindre. Vous cherchez à savoir ce que la personne peut trouver et comprendre avant de lui fournir une explication.

1. Définissez l’achèvement. Pour une modification de réservation, le résultat visé est-il une demande envoyée ou une nouvelle réservation confirmée ? Vérifiez le résultat que cette version et ce compte peuvent prendre en charge.
2. Consignez l’état initial. Notez la version de l’application, l’appareil, la langue, les autorisations et l’existence préalable de la réservation. Le compte d’un administrateur peut présenter un parcours différent de celui d’un client.
3. Observez sans nommer la commande. Demandez à la personne d’essayer d’atteindre l’objectif. Consignez l’écran qu’elle choisit, le libellé qu’elle lit et ce qu’elle attend. Si vous l’aidez, notez cette aide; un achèvement ultérieur ne l’efface pas.
4. Vérifiez le résultat séparément. Comparez la réponse visible à la réservation enregistrée. Rouvrez-la dans le compte de test ou consultez l’enregistrement de test du prestataire. Un appui ou un écran qui semble indiquer une réussite ne prouve pas que la mise à jour souhaitée a eu lieu.

Si vous examinez l’application seul, consignez ce que vous pouvez reproduire et rendez cette limite visible. Votre connaissance du produit modifie la tâche. Une observation ultérieure avec une personne qui ne le connaît pas fournit des éléments différents.

Examinez cette tâche de réservation fictive

Prenons une application fictive de réservation de cours qui permet de demander une autre séance. Le prestataire doit accepter cette demande avant que la réservation ne change. Les notes ci-dessous montrent comment examiner un malentendu. Nous n’avons utilisé ni application réelle, ni compte réel, ni participant pour cet exemple, et nous n’avons pas testé la formulation proposée.

Le décalage observé concerne le sens de l’action. Un autre libellé est une hypothèse à tester par rapport à l’opération réelle. Si la demande ne parvient jamais au prestataire, examinez également l’échec de l’opération. Si une confirmation immédiate est essentielle au produit, il s’agit d’une décision produit distincte, et non de quelque chose qu’un libellé de bouton peut fournir.

Consignez une observation avant son interprétation. “A ouvert la réservation, appuyé sur Modifier la réservation et attendu une confirmation” décrit un comportement dans cet exercice fictif. “L’interface est mauvaise” élude la question à laquelle vous devez encore répondre.

Apportez le plus petit changement qui répond à l’observation

Choisissez une correction qui traite le décalage consigné et préserve l’opération prévue. Commencez par la formulation, les instructions ou le retour d’information lorsque ce sont les éléments incertains. Une modification de la structure de navigation ou une refonte plus vaste doit être justifiée par la tâche. Gardez les défaillances fonctionnelles visibles afin qu’une explication plus claire ne masque pas une opération qui échoue toujours.

1. Essayez une maquette ciblée. Pour la réservation fictive, présentez un libellé d’action proposé et l’état qui en résulte dans une maquette cliquable. Nos audits UX et prototypes d’applications suivent cette progression de la tâche au prototype. Comparez ce que la personne attend avant d’appuyer avec l’état qu’elle reconnaît ensuite; ne présentez pas le libellé proposé comme une amélioration établie.

2. Vérifiez un parcours d’erreur. Pour le contenu web, le critère du W3C relatif à l’identification des erreurs exige qu’une erreur de saisie détectée automatiquement désigne l’élément concerné et décrive l’erreur sous forme de texte. Un contour coloré seul ne fournit pas cette explication. Les commandes natives et un examen complet de l’accessibilité exigent des vérifications spécifiques à la plateforme.

3. Vérifiez la réponse à l’écran et avec les technologies d’assistance. Pour le contenu web, le critère du W3C relatif aux messages d’état traite de la mise à disposition des changements d’état définis aux technologies d’assistance sans déplacer le focus de la commande actuelle. Vérifiez ce qui apparaît à l’écran et ce que les outils d’assistance peuvent détecter. Un lecteur d’écran, par exemple, est un logiciel capable de lire à voix haute le contenu d’une interface. Ce critère sélectionné ne certifie pas l’application, ne fixe pas d’objectif de temps de réponse et ne répare pas une opération lente.

4. Suivez la transition vers le web. Lorsque le même compte ou parcours de réservation mène à une page web, incluez cette transition dans le test. Le développement de sites et d’applications web doit préserver la formulation de la tâche et l’état réel de part et d’autre de cette frontière.

Que faut-il vérifier après le changement ?

Rejouez la même tâche visée à partir d’un état comparable et consignez ce qui s’est passé. Affichez la version de l’application, l’appareil, la langue et l’aide reçue à côté du résultat. Une comparaison utile porte sur la tâche observée: la personne a-t-elle trouvé l’action, compris son effet et reconnu le résultat réel ? Réservez toute conclusion commerciale plus large jusqu’à ce que vous disposiez des éléments nécessaires.

Consignez ensemble l’achèvement et l’aide, le premier mauvais détour, les erreurs de saisie que la personne n’a pas pu interpréter et toute confusion entre une demande et une confirmation. Répétez les vérifications pertinentes avec la langue et la configuration d’accessibilité examinées. Examinez les libellés plus longs et les informations disponibles avec cette configuration, au lieu de supposer que l’écran en anglais représente toutes les versions.

Si vous consignez déjà les actions dans l’application, comme le lancement d’une demande de modification de réservation ou son arrivée chez le prestataire, vérifiez que les enregistrements correspondent à ces états réels. Examinez l’évolution des questions adressées à l’assistance sur le même parcours. L’absence de téléchargements de l’application relève d’un problème d’acquisition distinct; notre guide sur une application qui n’obtient aucun téléchargement commence avant l’ouverture du produit.

Une répétition réussie peut décrire cette observation. Elle ne permet pas d’établir pourquoi des personnes désinstallent l’application ni d’attribuer une variation de la rétention à la correction. Consignez la prochaine question non résolue avec la personne chargée de la vérifier.

Notre intervention

Nous partons de la tâche prise en charge, de la première transition ambiguë et des éléments nécessaires pour choisir une correction. Nous pouvons les convertir en prototype, vérifier le parcours mis en oeuvre et inclure son équivalent web. Apportez une description de la tâche et du point où elle s’est arrêtée à une discussion de projet. Supprimez les noms de clients et les autres informations personnelles de tout exemple que vous partagez.

← Tous les articles