Préparer une transmission du design avec états et comportements
Une spécification traçable clarifie l’interface. Un exemple détaillé de recherche de projets illustre les textes, les états et les contrôles.
La transmission du design doit indiquer au développement quelle interface construire et comment elle se comporte dans le parcours convenu. Choisissez une tâche concrète. Le modèle suivant décrit une recherche de projets dans un portail client fictif ; il s’agit d’un plan, et non d’une interface déjà implémentée.
Consigner la tâche et la version du design
Dans l’exemple, la personne saisit « Portail » et lance la recherche. Le portail charge les projets correspondants couverts par ses droits existants. La conception ne modifie pas ces droits. Consignez le fichier source et la version approuvée qui font référence. Identifiez les composants avec leur version ; un ancien export d’image ne doit pas devenir à votre insu le modèle d’implémentation.
Relier les états aux textes et à l’utilisation
État de la spécification d’exemple | Retour prévu | Comportement convenu |
|---|---|---|
La recherche peut être lancée | Champ « Rechercher des projets », action « Rechercher » | Le terme saisi reste visible ; l’action lance le chargement. |
La recherche est en cours | « Chargement des projets. » | La recherche en cours est perceptible ; les anciens résultats ne sont pas présentés comme de nouveaux résultats. |
Recherche terminée avec résultats | « 2 projets trouvés. » et liens « Refonte du portail », « Aide du portail » | Les projets correspondants sont accessibles ; le terme de recherche est conservé. |
Recherche terminée sans résultat | « Aucun projet trouvé pour cette recherche. » | Le terme est conservé et peut être modifié. Il ne s’agit pas d’une erreur de connexion. |
Échec de récupération | « La liste des projets n’a pas pu être chargée. Réessayez. » | Le terme est conservé ; une nouvelle recherche est possible. L’erreur n’est pas présentée comme une liste vide. |
Les deux noms de projets sont des résultats supposés pour l’exemple. Précisez aussi ce qui se passe lorsqu’une nouvelle recherche commence avant la réponse précédente. Seuls les résultats correspondant au terme actuel doivent apparaître comme état courant.
Transmettre le nom technique et les retours
Le W3C recommande des libellés visibles adaptés et des noms accessibles vérifiés. Reliez donc clairement champ, action et nom prévu dans la conception. Les messages d’état peuvent informer les technologies d’assistance sans recevoir eux-mêmes le focus. La liste de résultats elle-même ne doit pas être confondue avec son court message d’état.
Convenez de l’emplacement du focus après la recherche et du moyen d’atteindre les résultats au clavier. Transmettez les questions ouvertes comme telles ; une conception manquante ne vaut pas accord pour un comportement arbitraire.
Valider avec la même tâche
Dans la version implémentée, vérifiez recherche, résultat vide et échec de récupération avec des données de test adaptées. Contrôlez les traductions longues, le parcours clavier et les retours avec la technologie d’assistance prévue. Comparez le résultat à la version convenue. Reportez les règles corrigées dans la documentation partagée afin que les modifications suivantes reposent sur la même base.
Sources
Écrit par
- Julia HoffmannRédactrice design et UXJulia Hoffmann est responsable chez ASES des contenus éditoriaux consacrés au design et à l’expérience utilisateur. Ses articles portent sur l’utilisation des sites web et des applications, la conception d’interfaces utilisateur et l’accessibilité numérique.
À lire aussi
Tous les articles
Votre projet avec ASES
Décrivez-nous votre projet. Nous revenons vers vous avec une première évaluation.