Liste de contrôle de l’expérience utilisateur pour les applications de bureau

  • Article

Notes

Ce guide de conception a été créé pour Windows 7 et n’a pas été mis à jour pour les versions plus récentes de Windows. La plupart des conseils s’appliquent toujours en principe, mais la présentation et les exemples ne reflètent pas nos conseils de conception actuels.

Voici une collection de quelques-unes des instructions importantes dans UX Guide. Vous pouvez l’utiliser comme liste de contrôle pour vous assurer que l’interface utilisateur de votre programme obtient correctement ces éléments importants.

Windows

  • Prise en charge de la résolution effective minimale de 800 x 600 pixels pour Windows. Pour les interfaces utilisateur critiques qui doivent fonctionner en mode sans échec, prennent en charge une résolution effective de 640 x 480 pixels. Veillez à tenir compte de l’espace utilisé par la barre des tâches en réservant 48 pixels relatifs verticaux pour les fenêtres affichées avec la barre des tâches.
  • Optimisez les dispositions de fenêtre redimensionnables pour une résolution effective de 1024 x 768 pixels. Redimensionnez automatiquement ces fenêtres pour des résolutions d’écran inférieures d’une manière toujours fonctionnelle.
  • Veillez à tester vos fenêtres en mode 96 points par pouce (ppp) (à 800 x 600 pixels), 120 ppp (à 1024 x 768 pixels) et 144 ppp (à 1200 x 900 pixels). Vérifiez les problèmes de disposition, tels que le découpage des contrôles, du texte et des fenêtres, et l’étirement des icônes et des bitmaps.
  • Pour les programmes avec des scénarios d’utilisation tactile et mobile, optimisez pour 120 ppp. Les écrans à ppp élevés sont actuellement répandus sur les PC tactiles et mobiles.
  • Si une fenêtre est une fenêtre appartenant à elle, affichez-la « centrée » au-dessus de la fenêtre propriétaire. Jamais en dessous. Pour l’affichage suivant, envisagez de l’afficher à son dernier emplacement (par rapport à la fenêtre propriétaire) si cela est susceptible d’être plus pratique.
  • Si une fenêtre est contextuelle, affichez-la toujours près de l’objet à partir duquel elle a été lancée. Toutefois, placez-le hors du chemin (de préférence décaler vers le bas et vers la droite) afin que l’objet ne soit pas couvert par la fenêtre.

Layout

  • Dimensionner les contrôles et les volets d’une fenêtre pour qu’ils correspondent à leur contenu typique. Évitez le texte tronqué et les points de suspension associés. Les utilisateurs ne doivent jamais avoir à interagir avec une fenêtre pour afficher son contenu classique, en réservant le redimensionnement et le défilement pour du contenu inhabituellement volumineux. En particulier case activée :
    • Tailles de contrôle. Dimensionner les contrôles en fonction de leur contenu classique, ce qui rend les contrôles plus larges, plus grands ou multilignes si nécessaire. Contrôle de taille pour éliminer ou réduire le défilement dans les fenêtres qui ont beaucoup d’espace disponible. En outre, il ne doit jamais y avoir d’étiquettes tronquées ou de texte tronqué dans les fenêtres qui ont beaucoup d’espace disponible. Toutefois, pour faciliter la lecture du texte, envisagez de limiter la largeur des lignes à 65 caractères.
    • Largeurs de colonne. Assurez-vous que les colonnes d’affichage de liste ont un dimensionnement par défaut, minimal et maximal approprié. Choisissez les largeurs de colonne par défaut des affichages de liste qui n’entraînent pas de texte tronqué, en particulier s’il existe de l’espace disponible dans l’affichage de liste.
    • Équilibre de disposition. La disposition d’une fenêtre doit être à peu près équilibrée. Si la disposition semble lourde à gauche, envisagez d’élargir les contrôles et de déplacer certains contrôles plus vers la droite.
    • Redimensionnement de la disposition. Lorsqu’une fenêtre est redimensionnable et que les données sont tronquées, assurez-vous que les grandes tailles de fenêtre affichent plus de données. Lorsque les données sont tronquées, les utilisateurs s’attendent à ce que les fenêtres de redimensionnement affichent plus d’informations.
  • Définissez une taille de fenêtre minimale s’il existe une taille en dessous de laquelle le contenu n’est plus utilisable. Pour les contrôles redimensionnables, définissez les tailles minimales d’éléments redimensionnables sur leurs plus petites tailles fonctionnelles, telles que les largeurs minimales de colonnes fonctionnelles dans les affichages de liste.

Texte

  • Utilisez des termes ordinaires et conversationnels lorsque vous le pouvez. Concentrez-vous sur les objectifs de l’utilisateur, et non sur la technologie. Cela est particulièrement efficace si vous expliquez un concept ou une action technique complexe. Imaginez-vous regarder par-dessus l’épaule de l’utilisateur et expliquer comment accomplir la tâche.
  • Soyez poli, favorable et encourageant. L’utilisateur ne doit jamais se sentir condescendé, blâmé ou intimidé.
  • Supprimez le texte redondant. Recherchez du texte redondant dans les titres de fenêtre, les instructions main, les instructions supplémentaires, les zones de contenu, les liens de commande et les boutons de validation. En règle générale, laissez le texte intégral dans main instructions et les contrôles interactifs, et supprimez toute redondance des autres emplacements.
  • Utilisez la mise en majuscule de style titre pour les titres et la mise en majuscule de style phrase pour tous les autres éléments de l’interface utilisateur. Cela est plus approprié pour le ton Windows.
    • Exception: Pour les applications héritées, vous pouvez utiliser la majuscule de style titre pour les boutons de commande, les menus et les en-têtes de colonne si nécessaire afin d’éviter de mélanger les styles de mise en majuscule.
  • Pour les noms de fonctionnalités et de technologies, soyez prudent dans la capitalisation. En règle générale, seuls les composants principaux doivent être capitalisés (à l’aide d’une majuscule de style titre).
  • Pour les noms de fonctionnalités et de technologies, soyez cohérent dans la capitalisation. Si le nom apparaît plusieurs fois sur un écran d’interface utilisateur, il doit toujours apparaître de la même façon. De même, sur tous les écrans de l’interface utilisateur du programme, le nom doit être présenté de manière cohérente.
  • Ne capitalisez pas les noms des éléments d’interface utilisateur génériques, tels que la barre d’outils, le menu, la barre de défilement, le bouton et l’icône.
    • Exceptions: Barre d’adresse, barre de liens, ruban.
  • N’utilisez pas toutes les majuscules pour les touches de clavier. Au lieu de cela, suivez la majuscule utilisée par les claviers standard, ou en minuscules si la touche n’est pas étiquetée sur le clavier.
  • Les points de suspension signifient l’incomplétude. Utilisez des points de suspension dans le texte de l’interface utilisateur comme suit :
    • Les commandes. Indiquez qu’une commande a besoin d’informations supplémentaires. N’utilisez pas de points de suspension chaque fois qu’une action affiche une autre fenêtre, uniquement lorsque des informations supplémentaires sont requises. Les commandes dont le verbe implicite est d’afficher une autre fenêtre ne prennent pas de points de suspension, comme Avancé, Aide, Options, Propriétés ou Paramètres.
    • Données. Indiquez que le texte est tronqué.
    • Étiquettes. Indiquez qu’une tâche est en cours (par exemple, « Recherche... »).

Pointe: Le texte tronqué dans une fenêtre ou une page avec un espace inutilisé indique une disposition médiocre ou une taille de fenêtre par défaut trop petite. Recherchez des dispositions et des tailles de fenêtre par défaut qui éliminent ou réduisent la quantité de texte tronqué. Pour plus d’informations, consultez Disposition.

  • N’utilisez pas de texte bleu qui n’est pas un lien, car les utilisateurs peuvent supposer qu’il s’agit d’un lien. Utilisez gras ou une nuance de gris où vous utiliseriez sinon du texte de couleur.
  • Utilisez l’gras avec parcimonie pour attirer l’attention sur le texte que les utilisateurs doivent lire.
  • Utilisez l’instruction main pour expliquer de manière concise ce que les utilisateurs doivent faire dans une fenêtre ou une page donnée. De bonnes instructions main communiquent l’objectif de l’utilisateur plutôt que de se concentrer uniquement sur la manipulation de l’interface utilisateur.
  • Exprimez l’instruction main sous la forme d’une direction impérative ou d’une question spécifique.
  • Ne placez pas de points à la fin des étiquettes de contrôle ou des instructions main.
  • Utilisez un espace entre les phrases. Pas deux.

Commandes

  • Généralités
    • Étiquetez chaque contrôle ou groupe de contrôles. Exceptions :
      • Les zones de texte et les listes déroulantes peuvent être étiquetées à l’aide d’invites.
      • Les contrôles subordonnés utilisent l’étiquette de leur contrôle associé. Les contrôles de rotation sont toujours des contrôles subordonnés.
    • Pour tous les contrôles, sélectionnez la valeur la plus sûre (pour éviter la perte de données ou d’accès au système), la valeur la plus sécurisée par défaut. Si la sûreté et la sécurité ne sont pas des facteurs, sélectionnez la valeur la plus probable ou la plus pratique.
    • Préférez les contrôles contraints. Utilisez des contrôles contraints tels que des listes et des curseurs chaque fois que possible, au lieu de contrôles sans contrainte comme les zones de texte, pour réduire le besoin d’entrée de texte.
    • Reconsidérer les contrôles désactivés. Les contrôles désactivés peuvent être difficiles à utiliser, car les utilisateurs doivent littéralement déduire pourquoi ils sont désactivés. Désactivez un contrôle lorsque les utilisateurs s’attendent à ce qu’il s’applique et ils peuvent facilement déduire pourquoi le contrôle est désactivé. Supprimez le contrôle lorsqu’il n’existe aucun moyen pour les utilisateurs de l’activer ou s’ils ne s’attendent pas à ce qu’il s’applique ou le laisse activé, mais fournissez un message d’erreur lorsqu’il est utilisé de manière incorrecte.
      • Pointe: Si vous ne savez pas si vous devez désactiver un contrôle ou fournir un message d’erreur, commencez par composer le message d’erreur que vous pouvez fournir. Si le message d’erreur contient des informations utiles que les utilisateurs cibles ne sont pas susceptibles de déduire rapidement, laissez le contrôle activé et indiquez l’erreur. Sinon, désactivez le contrôle.
  • Boutons de commande
    • Préférez les étiquettes spécifiques aux étiquettes génériques. Dans l’idéal, les utilisateurs ne devraient pas avoir à lire autre chose pour comprendre l’étiquette. Les utilisateurs sont beaucoup plus susceptibles de lire des étiquettes de bouton de commande que du texte statique.
      • Exception: Ne renommez pas le bouton Annuler si la signification d’annuler est non ambiguë. Les utilisateurs ne doivent pas avoir à lire tous les boutons pour déterminer quel bouton annule une action. Toutefois, renommez Annuler s’il n’est pas clair quelle action est annulée, par exemple quand plusieurs actions sont en attente.
    • Lorsque vous posez une question, utilisez des étiquettes qui correspondent à la question. Par exemple, fournissez des réponses Oui et Non à une question oui ou non.
    • N’utilisez pas les boutons Appliquer dans les boîtes de dialogue qui ne sont pas des feuilles de propriétés ou des éléments du panneau de configuration. Le bouton Appliquer signifie appliquer les modifications en attente, mais laisser la fenêtre ouverte. Cela permet aux utilisateurs d’évaluer les modifications avant de fermer la fenêtre. Toutefois, seuls les feuilles de propriétés et les éléments du panneau de configuration ont ce besoin.
    • Étiqueter un bouton Annuler si l’annulation retourne l’environnement à son état précédent (sans effet secondaire) ; sinon, étiquetez le bouton Fermer (si l’opération est terminée) ou Arrêter (si l’opération est en cours) pour indiquer qu’il laisse intact l’état modifié actuel.
  • Liens de commande
    • Toujours présenter des liens de commande dans un ensemble de deux ou plusieurs. Logiquement, il n’y a aucune raison de poser une question qui n’a qu’une seule réponse.
    • Indiquez un bouton Annuler explicite. N’utilisez pas de lien de commande à cet effet. Bien souvent, les utilisateurs se rendent compte qu’ils ne veulent pas effectuer une tâche. L’utilisation d’un lien de commande pour annuler obligerait les utilisateurs à lire attentivement tous les liens de commande pour déterminer lequel signifie annuler. Le fait de disposer d’un bouton Annuler explicite permet aux utilisateurs d’annuler efficacement une tâche.
    • Si la fourniture d’un bouton Annuler explicite laisse un lien de commande unique, fournissez à la fois un lien de commande pour annuler et un bouton Annuler. Cela indique clairement que les utilisateurs ont le choix. Formulez ce lien de commande en termes de différences par rapport à la première réponse, au lieu de simplement « Annuler » ou d’une variante.
  • « Ne plus afficher cet <élément> » case activée zones
    • Envisagez d’utiliser l’option « Ne plus afficher cet <élément> » pour permettre aux utilisateurs de supprimer une boîte de dialogue périodique, uniquement s’il n’existe pas de meilleure alternative. Il est préférable de toujours afficher le dialogue si les utilisateurs en ont vraiment besoin, ou simplement de l’éliminer s’ils ne le font pas.
    • Remplacez <l’élément> par l’élément spécifique. Par exemple, ne réexécutez pas ce rappel. Lorsque vous faites référence à une boîte de dialogue en général, utilisez Ne plus afficher ce message.
    • Indiquez clairement quand l’entrée utilisateur sera utilisée pour les futures valeurs par défaut en ajoutant la phrase suivante sous l’option : Vos sélections seront utilisées par défaut à l’avenir.
    • Ne sélectionnez pas l’option par défaut. Si la boîte de dialogue ne doit vraiment être affichée qu’une seule fois, faites-le sans demander. N’utilisez pas cette option comme excuse pour ennuyer les utilisateurs. Assurez-vous que le comportement par défaut n’est pas ennuyeux.
    • Si les utilisateurs sélectionnent l’option et cliquez sur Annuler, cette option prend effet. Ce paramètre étant une méta-option, il ne suit pas le comportement d’annulation standard qui consiste à ne laisser aucun effet secondaire. Notez que si les utilisateurs ne souhaitent pas voir la boîte de dialogue à l’avenir, ils souhaitent probablement l’annuler également.
  • Liens
    • N’attribuez pas declé d’accès. Les liens sont accessibles à l’aide de la touche Tab.
    • N’ajoutez pas « Click » ou « Click here » au texte du lien. Cela n’est pas nécessaire, car un lien implique un clic.
  • Info-bulles
    • Utilisez des info-bulles pour fournir des étiquettes pour les contrôles sans étiquette. Vous n’avez pas besoin de fournir des info-bulles de contrôles étiquetés simplement pour des raisons de cohérence.
    • Les info-bulles peuvent également fournir plus de détails pour les boutons de barre d’outils étiquetés si cela est utile. Ne vous contentez pas de répéter ou de donner une reformaté wordy de ce qui se trouve déjà dans l’étiquette.
    • Évitez de couvrir l’objet que l’utilisateur est sur le point d’afficher ou d’interagir avec lui. Placez toujours la pointe sur le côté de l’objet, même si cela nécessite une séparation entre le pointeur et l’extrémité. Une certaine séparation n’est pas un problème tant que la relation entre l’objet et son conseil est claire.
      • Exception: Info-bulles de nom complet utilisées dans les listes et les arborescences.
    • Pour les collections d’éléments, évitez de couvrir l’objet suivant que l’utilisateur est susceptible d’afficher ou d’interagir avec lui. Pour les éléments disposés horizontalement, évitez de placer des pointes à droite; pour les éléments disposés verticalement, évitez de placer des conseils en dessous.
  • Affichage progressif
    • Utilisez plus/moins de boutons de divulgation progressive pour masquer les options avancées ou rarement utilisées, les commandes et les détails dont les utilisateurs n’ont généralement pas besoin. Ne masquez pas les éléments couramment utilisés, car les utilisateurs risquent de ne pas les trouver. Mais assurez-vous que ce qui est masqué a une valeur.
    • Si la surface affiche toujours des options, des commandes ou des détails, utilisez les paires d’étiquettes suivantes :
      • Plus/moins d’options. Utilisez pour les options ou un mélange d’options, de commandes et de détails.
      • Plus/moins de commandes. Utilisez uniquement pour les commandes.
      • Plus/moins de détails. Utilisez à des fins d’information uniquement.
      • Nom de l’objet Plus/Moins<.> Utilisez pour d’autres types d’objets, tels que les dossiers.
    • Sinon :
      • Afficher/Masquer les options. Utilisez pour les options ou un mélange d’options, de commandes et de détails.
      • Afficher/Masquer les commandes. Utilisez uniquement pour les commandes.
      • Afficher/masquer les détails. Utilisez à des fins d’information uniquement.
      • Afficher/Masquer le <nom> de l’objet. Utilisez pour d’autres types d’objets, tels que les dossiers.
  • Barres de progression
    • Utilisez des barres de progression précises pour les opérations qui nécessitent une durée limitée, même si cette durée ne peut pas être prédite avec précision. Les barres de progression indéterminées indiquent que des progrès sont en cours, mais ne fournissent aucune autre information. Ne choisissez pas une barre de progression indéterminée uniquement en fonction du manque de précision possible.
    • Fournissez une estimation du temps restant si vous pouvez le faire avec précision. Les estimations de temps restantes qui sont exactes sont utiles, mais les estimations qui sont loin de la marque ou rebondissent significativement ne le sont pas. Vous devrez peut-être effectuer un traitement avant de pouvoir fournir des estimations précises. Si c’est le cas, n’affichez pas d’estimations potentiellement inexactes pendant cette période initiale.
    • Ne redémarrez pas la progression. Une barre de progression perd sa valeur si elle redémarre (peut-être parce qu’une étape de l’opération se termine), car les utilisateurs n’ont aucun moyen de savoir quand l’opération se terminera. Au lieu de cela, toutes les étapes de l’opération partagent une partie de la progression et faites en sorte que la barre de progression soit terminée une fois.
    • Fournissez des détails utiles sur la progression. Fournissez des informations supplémentaires sur la progression, mais uniquement si les utilisateurs peuvent en faire quelque chose. Assurez-vous que le texte est affiché suffisamment longtemps pour que les utilisateurs puissent le lire.
    • Ne combinez pas une barre de progression avec un pointeur occupé. Utilisez l’un ou l’autre, mais pas les deux en même temps.
  • Invites
    • Utilisez une invite lorsque l’espace d’écran est si important que l’utilisation d’une étiquette ou d’une instruction n’est pas souhaitable, par exemple dans une barre d’outils.
    • L’invite sert principalement à identifier l’objectif de la zone de texte ou de la zone de liste modifiable de manière compacte. Il ne doit pas s’agir d’informations cruciales que l’utilisateur doit voir lors de l’utilisation du contrôle.
    • Le texte de l’invite ne doit pas être confondu avec du texte réel. Pour ce faire :
      • Dessinez le texte de l’invite en gris italique et le texte d’entrée réel en noir romain.
      • Le texte de l’invite ne doit pas être modifiable et doit disparaître une fois que les utilisateurs cliquent ou tabulation dans la zone de texte.
        • Exception: Si la zone de texte a le focus d’entrée par défaut, l’invite s’affiche et disparaît une fois que l’utilisateur commence à taper.
    • N’utilisez pas de ponctuation de fin ou de points de suspension.
  • Notifications
    • Utilisez des notifications pour les événements qui ne sont pas liés à l’activité utilisateur actuelle, ne nécessitent pas d’action immédiate de l’utilisateur, et les utilisateurs peuvent librement ignorer.
    • Ne pas abuser des notifications :
      • Utilisez les notifications uniquement si vous en avez besoin. Lorsque vous affichez une notification, vous risquez d’interrompre les utilisateurs, voire de les ennuyer. Assurez-vous que l’interruption est justifiée.
      • Utilisez des notifications pour les événements ou les situations non critiques qui ne nécessitent pas d’action immédiate de l’utilisateur. Pour les événements ou les situations critiques qui nécessitent une action immédiate de l’utilisateur, utilisez un autre élément d’interface utilisateur (par exemple, une boîte de dialogue modale).
      • N’utilisez pas de notifications pour les annonces de fonctionnalités !

Clavier

  • Affectez le focus d’entrée initial au contrôle avec lequel les utilisateurs sont le plus susceptibles d’interagir en premier, qui est souvent le premier contrôle interactif. Si le premier contrôle interactif n’est pas un bon choix, envisagez de modifier la disposition de la fenêtre.
  • Affectez des taquets d’onglets à tous les contrôles interactifs, y compris les zones d’édition en lecture seule. Exceptions :
    • Regroupez des ensembles de contrôles associés qui se comportent comme un seul contrôle, comme des cases d’option. Ces groupes ont un seul taquet de tabulation.
    • Contiennent correctement des groupes afin que les touches de direction se cheminent vers l’avant et vers l’arrière au sein du groupe et restent dans le groupe.
  • L’ordre de tabulation doit aller de gauche à droite, de haut en bas. En règle générale, l’ordre de tabulation doit suivre l’ordre de lecture. Envisagez d’effectuer des exceptions pour les contrôles couramment utilisés en les plaçant plus tôt dans l’ordre de tabulation. Tab doit parcourir tous les taquets de tabulation dans les deux directions sans s’arrêter. Dans un groupe, l’ordre de tabulation doit être séquentiel, sans exception.
  • Dans un taquet de tabulation, l’ordre des touches de direction doit aller de gauche à droite, de haut en bas, sans exception. Les touches de direction doivent parcourir tous les éléments dans les deux sens sans s’arrêter.
  • Présentez les boutons de validation dans l’ordre suivant :
    • OK/[Faire l’action]/Oui
    • [Ne pas faire l’action]/Non
    • Annuler
    • Appliquer (le cas échéant)

où [Faire] et [Ne pas le faire] sont des réponses spécifiques à l’instruction main.

  • Ne confondez pas les touches d’accès et les touches de raccourci. Bien que les touches d’accès et les touches de raccourci fournissent un accès clavier à l’interface utilisateur, elles ont des objectifs et des instructions différents.
  • Dans la mesure du possible, attribuez des clés d’accès uniques à tous les contrôles interactifs ou à leurs étiquettes.Les zones de texte en lecture seule sont des contrôles interactifs (car les utilisateurs peuvent les faire défiler et copier du texte), ce qui leur permet de bénéficier des clés d’accès. N’attribuez pas de clés d’accès à :
    • Boutons OK, Annuler et Fermer. Les touches Entrée et Échap sont utilisées pour leurs clés d’accès. Toutefois, affectez toujours une clé d’accès à un contrôle qui signifie OK ou Annuler, mais qui a une étiquette différente.
  • Affectez des touches de raccourci aux commandes les plus couramment utilisées. Les programmes et fonctionnalités rarement utilisés n’ont pas besoin de touches de raccourci, car les utilisateurs peuvent utiliser des touches d’accès à la place.
  • Ne faites pas d’une touche de raccourci la seule façon d’effectuer une tâche. Les utilisateurs doivent également pouvoir utiliser la souris ou le clavier avec tabulation, flèche et touches d’accès.
  • N’affectez pas de significations différentes aux touches de raccourci connues. Étant donné qu’ils sont mémorisés, les significations incohérentes pour les raccourcis connus sont frustrantes et sujettes aux erreurs.
  • N’essayez pas d’attribuer des touches de raccourci de programme à l’échelle du système. Les touches de raccourci de votre programme n’auront d’effet que lorsque votre programme a le focus d’entrée.

Souris

  • Ne jamais exiger que les utilisateurs cliquent sur un objet pour déterminer s’il est cliquable. Les utilisateurs doivent être en mesure de déterminer la cliquabilité par l’inspection visuelle seule.
    • L’interface utilisateur principale (comme les boutons de validation) doit avoir une affordance de clic statique. Les utilisateurs ne doivent pas avoir à pointer pour découvrir l’interface utilisateur principale.
    • L’interface utilisateur secondaire (par exemple, les commandes secondaires ou les contrôles de divulgation progressive) peut afficher leur affordance de clic lors du pointage.
    • Les liens texte doivent suggérer statiquement le texte du lien, puis afficher leur affordance de clic (soulignement ou autre changement de présentation, avec pointeur de la main) lors du pointage.
    • Les liens graphiques affichent uniquement un pointeur de main lors du pointage.
  • Utilisez le pointeur de la main (ou « sélection de lien ») uniquement pour les liens texte et graphique. Sinon, les utilisateurs doivent cliquer sur des objets pour déterminer s’il s’agit de liens.

Boîtes de dialogue

  • Les boîtes de dialogue modales nécessitent une interaction. Utilisez-les donc pour les éléments auxquels les utilisateurs doivent répondre avant de poursuivre leur tâche. Assurez-vous que l’interruption est justifiée, par exemple pour les tâches ponctuelles critiques ou peu fréquentes qui nécessitent une exécution. Sinon, envisagez des alternatives sans mode.
  • Les boîtes de dialogue sans mode ne nécessitent pas d’interaction. Utilisez-les donc lorsque les utilisateurs doivent basculer entre une boîte de dialogue et la fenêtre propriétaire. Ils sont mieux utilisés pour les tâches fréquentes, répétitives ou en cours. Toutefois, les rubans, les barres d’outils et les fenêtres de palette sont souvent de meilleures alternatives.

Feuilles de propriétés

  • Vérifiez que les propriétés sont nécessaires. N’encombrez pas vos pages de propriétés avec des propriétés inutiles simplement pour éviter de prendre des décisions de conception difficiles.
  • Présenter les propriétés en termes d’objectifs utilisateur plutôt que de technologie. Le simple fait qu’une propriété configure une technologie spécifique ne signifie pas que vous devez présenter la propriété en termes de cette technologie.
    • Si vous devez présenter des paramètres en termes de technologie (peut-être parce que vos utilisateurs reconnaissent le nom de la technologie), incluez une brève description de l’avantage utilisateur.
  • Utilisez des étiquettes d’onglet spécifiques et explicites. Évitez les étiquettes d’onglet génériques qui peuvent s’appliquer à n’importe quel onglet, par exemple Général, Avancé ou Paramètres.
  • Évitez les pages Général. Vous n’êtes pas obligé d’avoir une page Général. Utilisez une page Général uniquement si :
    • Les propriétés s’appliquent à plusieurs tâches et sont significatives pour la plupart des utilisateurs. Ne placez pas de propriétés spécialisées ou avancées sur une page Général, mais vous pouvez les rendre accessibles via un bouton de commande sur la page Général.
    • Les propriétés ne correspondent pas à une catégorie plus spécifique. Si c’est le cas, utilisez plutôt ce nom pour la page.
  • Évitez les pages avancées. Utilisez une page Avancé uniquement si :
    • Les propriétés s’appliquent à des tâches peu courantes et sont significatives principalement pour les utilisateurs avancés.
    • Les propriétés ne correspondent pas à une catégorie plus spécifique. Si c’est le cas, utilisez plutôt ce nom pour la page.
  • N’utilisez pas d’onglets si une fenêtre de propriétés n’a qu’un seul onglet et n’est pas extensible. Utilisez une boîte de dialogue normale avec OK, Annuler et un bouton facultatif Appliquer à la place. Toutefois, les fenêtres de propriétés extensibles (qui peuvent être étendues par des tiers) doivent utiliser des onglets.

Assistants

  • Envisagez d’abord des alternatives légères, telles que les boîtes de dialogue, les volets Office ou les pages uniques. Les Assistants sont une interface utilisateur lourde, mieux utilisée pour les tâches à plusieurs étapes et rarement exécutées. Vous n’avez pas besoin d’utiliser des Assistants : vous pouvez fournir des informations et une assistance utiles dans n’importe quelle interface utilisateur.
  • Utilisez Suivant uniquement lorsque vous passez à la page suivante sans engagement. Passer à la page suivante est considéré comme un engagement lorsque son effet ne peut pas être annulé en cliquant sur Précédent ou Annuler.
  • Utilisez Retour uniquement pour corriger les erreurs. En plus de corriger les erreurs, les utilisateurs ne doivent pas avoir à cliquer sur Précédent pour progresser dans une tâche.
  • Lorsque les utilisateurs valident une tâche, utilisez un bouton de validation qui est une réponse spécifique à l’instruction main (par exemple, Imprimer, Se connecter ou Démarrer). N’utilisez pas d’étiquettes génériques comme Suivant (qui n’implique pas d’engagement) ou Terminer (qui n’est pas spécifique) pour valider une tâche. Les étiquettes de ces boutons de validation doivent être logiques elles-mêmes. Toujours démarrer les étiquettes de bouton de validation avec un verbe. Exceptions :
    • Utilisez Terminer lorsque les réponses spécifiques sont toujours génériques, par exemple Enregistrer, Sélectionner, Choisir ou Obtenir.
    • Utilisez Terminer pour modifier un paramètre spécifique ou une collection de paramètres.
  • Utilisez des liens de commande uniquement pour les choix, pas pour les engagements. Les boutons de validation spécifiques indiquent que l’engagement est beaucoup mieux que les liens de commande dans un Assistant.
  • Lorsque vous utilisez des liens de commande, masquez le bouton Suivant, mais laissez le bouton Annuler.
  • Utilisez Fermer pour Follow-Up et les pages d’achèvement. N’utilisez pas Annuler, car la fermeture de la fenêtre n’abandonnera pas les modifications ou actions effectuées à ce stade. N’utilisez pas Terminé, car ce n’est pas un verbe impératif.
  • N’utilisez pas « Assistant » dans les noms de l’Assistant. Par exemple, utilisez « Se connecter à un réseau » au lieu de « Assistant Configuration du réseau ». Toutefois, il est acceptable de faire référence aux Assistants en tant qu’Assistants. Par exemple : « Si vous configurez un réseau pour la première fois, vous pouvez obtenir de l’aide à l’aide de l’Assistant Connexion à un réseau ».
  • Conservez les sélections des utilisateurs par le biais de la navigation. Par exemple, si l’utilisateur apporte des modifications, clique sur Précédent, puis suivant, ces modifications doivent être conservées. Les utilisateurs ne s’attendent pas à devoir entrer à nouveau les modifications, sauf s’ils ont explicitement choisi de les effacer.

Pages de l’assistant

  • Concentrez-vous sur la prise de décision efficace. Réduisez le nombre de pages pour vous concentrer sur les éléments essentiels. Regroupez les pages associées et excluez les pages facultatives du flux de main. Le fait que les utilisateurs cliquent complètement sur Suivant dans votre Assistant peut sembler une bonne expérience au premier abord, mais si les utilisateurs n’ont jamais besoin de modifier les valeurs par défaut, les pages sont probablement inutiles.
  • N’utilisez pas les pages d’accueil : rendez la première page fonctionnelle dans la mesure du possible. Utilisez une page Prise en main facultative uniquement dans les cas suivants :
    • L’Assistant a des prérequis qui sont nécessaires pour terminer l’Assistant correctement.
    • Les utilisateurs peuvent ne pas comprendre l’objectif de l’Assistant en fonction de sa première page Choix, et il n’y a pas de place pour une explication supplémentaire.
    • L’instruction main pour Prise en main pages est « Avant de commencer : ».
  • Sur les pages dans lesquelles les utilisateurs sont invités à faire des choix, optimisez pour les cas les plus probables. Ces types de pages doivent présenter des choix réels, pas seulement des instructions.
    • Si vous n’utilisez pas de page Prise en main, expliquez l’objectif de l’Assistant en haut de la première page de choix.
  • Utilisez les pages de validation pour indiquer clairement quand les utilisateurs s’engagent pour la tâche. En règle générale, la page Valider est la dernière page de choix, et le bouton Suivant est réétiqueté pour indiquer la tâche en cours de validation.
    • N’utilisez pas de pages résumées qui résument simplement les sélections précédentes de l’utilisateur, sauf si la tâche est risquée (impliquant la sécurité, la perte de temps ou d’argent) ou s’il y a de bonnes chances que les utilisateurs ne comprennent pas leurs sélections et aient besoin de les examiner.
  • N’utilisez pas les pages Félicitations qui ne font que mettre fin à l’Assistant. Si les résultats de l’Assistant sont clairement visibles pour les utilisateurs, fermez simplement l’Assistant sur le bouton de validation final.
    • Utilisez Follow-Up pages lorsqu’il existe des tâches connexes que les utilisateurs sont susceptibles d’effectuer en tant que suivi. Évitez les tâches de suivi familières, telles que « Envoyer un message électronique ».
    • Utilisez les pages d’achèvement uniquement lorsque les résultats ne sont pas visibles et qu’il n’existe pas de meilleur moyen de fournir des commentaires pour l’achèvement de la tâche.
    • Les Assistants qui ont des pages de progression doivent utiliser une page d’achèvement ou Follow-Up page pour indiquer l’achèvement de la tâche. Pour les tâches de longue durée, fermez l’Assistant sur la page Valider et utilisez des notifications pour envoyer des commentaires.

Messages d’erreur

  • Ne donnez pas de messages d’erreur lorsque les utilisateurs ne sont pas susceptibles d’effectuer une action ou de modifier leur comportement en tant que résultat du message. S’il n’y a aucune action que les utilisateurs peuvent entreprendre, ou si le problème n’est pas significatif, supprimez le message d’erreur.
  • Dans la mesure du possible, proposez une solution afin que les utilisateurs puissent résoudre le problème. Toutefois, assurez-vous que la solution proposée est susceptible de résoudre le problème. Ne perdez pas de temps aux utilisateurs en suggérant des solutions possibles, mais improbables.
  • Être précis. Évitez les formulations vagues, telles que les erreurs de syntaxe et les opérations non conformes. Fournissez des noms, des emplacements et des valeurs spécifiques des objets impliqués.
  • N’utilisez pas de formulation qui blâme l’utilisateur ou implique une erreur de l’utilisateur. Évitez d’utiliser vous et votre dans la formulation. Bien que la voix active soit généralement préférée, utilisez la voix passive lorsque l’utilisateur est l’objet et peut se sentir responsable de l’erreur si la voix active a été utilisée.
  • N’utilisez pas OK pour les messages d’erreur. Les utilisateurs ne considèrent pas les erreurs comme étant correctes. Si le message d’erreur n’a pas d’action directe, utilisez Fermer à la place.
  • N’utilisez pas les mots suivants :
    • Erreur, échec (utiliser le problème à la place)
    • Échec (utilisez impossible de le faire à la place)
    • Illégal, non valide, incorrect (utilisez incorrect ou non valide à la place)
    • Abandonner, tuer, arrêter (utiliser stop à la place)
    • Catastrophique, fatal (utiliser grave à la place)

Ces termes sont inutiles et contraires au ton encourageant de Windows. Au lieu de cela, une icône d’erreur, lorsqu’elle est utilisée correctement, indique suffisamment qu’il y a un problème.

  • N’accompagnez pas les messages d’erreur avec des effets sonores. Il est inutile de le faire.

Messages d’avertissement

  • Les avertissements décrivent une condition susceptible de provoquer un problème à l’avenir. Les avertissements ne sont pas des erreurs ou des questions. Par conséquent, ne posez pas de questions de routine en tant qu’avertissements.
  • N’envoyez pas de messages d’avertissement lorsque les utilisateurs ne sont pas susceptibles d’effectuer une action ou de modifier leur comportement en tant que résultat du message. S’il n’y a aucune action que les utilisateurs peuvent entreprendre, ou si la condition n’est pas significative, supprimez le message d’avertissement.

Confirmations

  • N’utilisez pas de confirmations inutiles. Utilisez les confirmations uniquement dans les cas suivants :
    • Il y a une raison claire de ne pas continuer et une chance raisonnable que parfois les utilisateurs ne le feront pas.
    • L’action a des conséquences importantes ou ne peut pas être facilement annulée.
    • L’action a des conséquences que les utilisateurs peuvent ne pas connaître.
    • La poursuite de l’action nécessite que les utilisateurs fassent un choix qui n’a pas de valeur par défaut appropriée.
    • Étant donné le contexte actuel, les utilisateurs sont susceptibles d’avoir effectué une action par erreur.
  • Les confirmations de phrases sous la forme d’une question oui ou non, et fournissent des réponses oui ou non. Contrairement à d’autres types de boîtes de dialogue, les confirmations sont conçues pour empêcher les utilisateurs de prendre des décisions rapides. Si les utilisateurs ne réfléchissent pas à leur réponse, une confirmation n’a aucune valeur.

Icônes

  • Toutes les icônes doivent respecter les recommandations relatives aux icônes de style Aero. Remplacez toutes les icônes de style Windows XP.
  • Choisissez des icônes standard en fonction de leur type de message, et non de la gravité du problème sous-jacent :
    • Erreur. Erreur ou problème qui s’est produit.
    • Avertissement. Condition susceptible de provoquer un problème à l’avenir.
    • Information. Informations utiles.

Si un problème combine différents types de messages, concentrez-vous sur l’aspect le plus important sur lequel les utilisateurs doivent agir.

  • Les icônes doivent toujours correspondre à l’instruction main ou à tout autre texte correspondant.
  • Les icônes d’erreur ne sont pas nécessaires pour les problèmes d’entrée utilisateur non critiques. Toutefois, les icônes sont nécessaires pour les erreurs sur place, car sinon, ces commentaires contextuels seraient trop faciles à ignorer.
  • N’utilisez pas d’icônes d’avertissement pour « atténuer » les erreurs non critiques. Les erreurs ne sont pas des avertissements ; appliquez plutôt les instructions relatives aux icônes d’erreur.
  • Pour les boîtes de dialogue de question, utilisez les icônes d’avertissement uniquement pour les questions ayant des conséquences importantes. N’utilisez pas d’icônes d’avertissement pour les questions de routine.

Aide

  • Lien vers des rubriques d’aide spécifiques et pertinentes. Ne créez pas de lien vers la page d’accueil de l’aide, la table des matières, la liste des résultats de la recherche ou une page qui renvoie simplement vers d’autres pages. Évitez de lier des pages structurées sous la forme d’une liste volumineuse de questions fréquemment posées, car cela oblige les utilisateurs à rechercher celui qui correspond au lien sur lequel ils ont cliqué. Ne créez pas de lien vers des rubriques d’aide spécifiques qui ne sont pas pertinentes et utiles pour la tâche en cours. Ne créez jamais de lien vers des pages vides.
  • Ne placez pas de liens d’aide sur chaque fenêtre ou page par souci de cohérence. Fournir un lien d’aide au même endroit ne signifie pas que vous devez les fournir partout.
  • Dans la mesure du possible, l’expression Aide lie le texte en fonction de la question principale répondue par le contenu de l’aide. N’utilisez pas la formulation « En savoir plus sur » ou « Obtenir de l’aide sur ce ».
  • Utilisez l’intégralité du lien d’aide pour le texte du lien, pas seulement pour les mots clés.
  • Utilisez des phrases complètes.
  • N’utilisez pas de ponctuation ou de points de suspension de fin, à l’exception des points d’interrogation.
  • Si le contenu de l’aide est en ligne, indiquez-le clairement dans le texte du lien. Cela permet de rendre le résultat des liens prévisible.