Partager via

Guide de style de conception et de texte de l’interface utilisateur de Windows Admin Center

  • S’applique à: ✅ Windows Admin Center, ✅ Windows Admin Center Preview

Cette rubrique décrit l’approche générale de l’écriture du texte de l’interface utilisateur de Windows Admin Center, ainsi que certaines de nos conventions et approches spécifiques.

Windows Admin Center et toutes les extensions doivent suivre les principes de langage de Microsoft pour que l’expérience soit facile à utiliser et conviviale. Ce guide de style s’appuie sur ces principes de langage ainsi que sur le Guide de style d’écriture Microsoft. Vous devez donc consulter ces deux ressources pour obtenir des informations sur, par exemple, l’accessibilité, les acronymeset le choix des mots, comme s’il vous plaît et désolé.

Boutons

  • Les boutons doivent contenir un seul mot si possible, en particulier si vous voulez localiser votre outil. Deux ou trois mots sont tolérés, essayez d’éviter plus long. Si vous avez quatre mots ou plus, utilisez plutôt un contrôle de lien.

  • Les étiquettes de bouton doivent être concises, spécifiques et explicites. Au lieu d’un bouton générique « Envoyer », utilisez un verbe correspondant à l’action utilisateur, comme « Créer », « Supprimer », « Ajouter », « Mettre en forme », etc.

  • Si un bouton suit une question, son étiquette doit correspondre clairement à la question (généralement « Oui » ou « Non »).

  • Quand vous lancez un flux de création, utilisez l’étiquette de bouton appropriée :

    Bouton Utilisation
    Créer Créer une ressource/un objet/etc.
    Ajouter Ajouter des ressources/un objet/etc. existants dans l’outil.
    Installer Installation de logiciels/extensions.

Mise en majuscules

Nous suivons le style Microsoft pour l’utilisation des majuscules : utilisez des majuscules en début de phrase pour à peu près tout.

Élément d'interface utilisateur Mise en majuscules Commentaires
Badges (par exemple, PRÉVERSION) Tout en majuscules
Tout le reste Type phrase Toutefois, il y a quelques exceptions quand nous exposons des propriétés d’objet WMI ou PowerShell qui échappent à notre contrôle.

Deux-points

Utilisez les deux-points pour introduire des listes. Par exemple :

Choisissez l’un des éléments suivants :

  • Chats
  • Chiens
  • Les Quokkas

N’utilisez pas les deux-points dans le texte de l’interface utilisateur quand l’étiquette est sur une autre ligne que l’objet auquel elle correspond, ou quand il y a une distinction claire entre l’étiquette et l’objet auquel elle correspond.

Utilisez les deux-points dans le texte de l’interface utilisateur quand l’étiquette est sur la même ligne que le texte auquel elle correspond et que vous devez empêcher les deux éléments de s’exécuter ensemble.

Messages de confirmation

Les boîtes de dialogue de confirmation sont utiles quand la suite peut avoir des résultats inattendus, comme une perte de données. Elles doivent contenir des informations utiles et analysables avec un résultat clair, en particulier pour les événements qui ne peuvent pas être annulés.

  • Vérifiez que la confirmation est nécessaire. S’il n’y a pas de nouvelles informations à proposer (par exemple, « Êtes-vous sûr ? »), un message de confirmation n’est peut-être pas nécessaire.
  • Vérifiez que le client veut poursuivre l’action.
  • Vérifiez que l’instruction principale (titre) et le texte explicatif (corps) ne sont pas redondants.
  • Dans le titre, définissez les résultats possibles sous forme de question ou d’énoncé décrivant ce qui va se passer. Par exemple, « Effacer toutes les données sur ce lecteur ? » ou « Vous êtes sur le point d’effacer toutes vos données ».
  • Ajoutez des détails dans le corps. S’il y a une variable, comme le nom de l’élément que vous allez changer, ajoutez-la ici.
  • Ajoutez une question simple (dans l’en-tête ou dans le corps) qui encadre un choix clair entre deux boutons d’action.
  • Pour un choix complexe, utilisez les boutons Oui/Non, qui encouragent une lecture attentive. Pour un choix plus simple, utilisez des boutons propres à l’action, comme Tout supprimer ou Annuler.

Expérience de première exécution

La première fois qu’un utilisateur visite une page, vous avez la possibilité de l’aider à démarrer avec votre outil. Il peut s’agir des points suivants :

  • Chaîne de texte dans une page vide avec de brèves instructions pour démarrer, par exemple, « Sélectionnez « Ajouter » pour ajouter une application ».
  • Lien vers le contrôle qui permet à l’utilisateur de démarrer : par exemple, « Ajouter une application pour commencer ».
  • Petite animation ou vidéo montrant à l’utilisateur comment commencer

Voici quelques conseils de notre guide de style Windows :

1. Être utile

  • Évitez le style et le langage marketing.
  • Quand vous faites une démo ou suggérez quelque chose, faites-en sorte que le résultat final soit clair. Le simple fait de montrer au client comment faire quelque chose n’est pas efficace s’il ne sait pas pourquoi il le fait.
  • Ne proposez pas de conseils si le client n’en a pas besoin.

2. Montrer, ne pas dire

Votre texte doit être aussi simple que possible (pensez aux petites animations ou vidéos).

3. Ne pas surcharger

  • Limitez les fenêtres contextuelles et les conseils à 4 par session d’utilisation combinée, y compris les notifications système et les notifications d’interpréteur de commandes.
  • Vérifiez que le minutage des fenêtres contextuelles est pertinent.
  • N’empêchez pas le client de faire quelque chose.
  • Vérifiez que les fenêtres contextuelles sont facilement ignorées.

4. Rester dans le contexte

  • Les apprentissages sont plus efficaces quand ils sont présentés au bon moment.
  • Si vous créez des tutoriels ou des diaporamas, les informations doivent être concrètes.
  • Pas de « blabla » marketing : concentrez-vous sur des conseils et astuces spécifiques.
  • Donnez aux clients un moyen de revenir au tutoriel par la suite, si cela est pertinent (les utilisateurs ne retiennent pas toujours les informations la première fois, mais les instructions de configuration peuvent être pertinentes seulement une fois).
  • Les messages d’état vide sont un endroit naturel pour apprendre et/ou sourire : ils doivent être simples et informatifs.

5. Réduire les configurations pénibles

Quand vous avez besoin que le client effectue une autre action pour aller jusqu’au bout de l’expérience (connexion à un service en ligne, etc.), rendez-la aussi agréable que possible.

  • Les messages doivent être courts et directs.
  • Évitez d’envoyer l’utilisateur trop loin. Si possible, donnez-lui un moyen de se connecter à partir de l’endroit où il se trouve.
  • Si vous le pouvez, donnez-lui l’option de le faire plus tard, puis rappelez-lui de le faire plus tard.
  • Si vous l’emmenez en dehors de l’expérience, donnez-lui un moyen de revenir rapidement et facilement.

Voici quelques conseils de notre guide de style Windows :

Presque jamais. Fournissez un lien d’aide uniquement quand :

  • Il y a une question évidente et importante que les clients sont susceptibles de poser quand ils sont dans l’interface utilisateur et que la réponse doit les aider à réussir la tâche d’interface utilisateur.
  • Il n’y a pas assez d’espace dans l’interface utilisateur pour donner la quantité d’informations nécessaires afin que les utilisateurs réussissent la tâche d’interface utilisateur.
  • Les liens de texte doivent s’afficher aussi près que possible de l’élément d’interface utilisateur concerné par l’aide.
  • Si vous devez fournir un lien de texte qui s’applique à tout un écran d’interface utilisateur, placez-le en bas à gauche de l’écran.
  • Si vous fournissez un lien au moyen d’un bouton d’aide (?), l’info-bulle doit indiquer « Aide ».

Quelle URL faut-il utiliser ?

Ne créez jamais de lien direct vers une adresse web. Utilisez plutôt un service de redirection.

Les développeurs Microsoft doivent utiliser un lien FWLink, sauf s’il s’agit d’un lien d’aide que les utilisateurs peuvent être amenés à taper manuellement, auquel cas utilisez un lien aka.ms (à condition que la cible de l’URL soit un site web qui reconnaît automatiquement les paramètres régionaux du navigateur, comme learn.microsoft.com).

Directives du texte

  • Utilisez des phrases complètes.
  • N’ajoutez pas de ponctuation de fin, sauf pour les points d’interrogation.
  • Vous n’avez pas besoin d’utiliser le même texte que le titre de la tâche. Utilisez du texte qui a du sens dans le contexte de l’interface utilisateur, mais vérifiez qu’il y a une connexion logique entre les deux. Par exemple :
    • Lien d’aide : Quels sont les risques liés à l’autorisation des exceptions ?
    • Titre de la rubrique d’aide : « Autoriser un programme à communiquer via le Pare-feu Windows »
  • Soyez aussi précis que possible sur le contenu de la rubrique d’aide.
    • Notre style
      • Comment le Pare-feu Windows aide-t-il à protéger mon ordinateur ?
      • Pourquoi les mises en surbrillance peuvent améliorer une image
    • Pas notre style
      • Plus d’informations sur le Pare-feu Windows
      • En savoir plus sur la gestion des couleurs
      • En savoir plus
  • Utilisez la phrase entière pour le texte du lien, pas seulement des mots clés.
  • Dans certains cas, vous pouvez utiliser un lien « En savoir plus » si le contexte indique clairement ce que l’utilisateur obtient quand il clique sur le lien.

Messages d’erreur

Voici quelques conseils adaptés tirés du Guide de style Windows :

Pour écrire un bon message, il faut trouver le juste milieu entre fournir suffisamment d’explications tout en évitant d’être trop technique, entre être décontracté et sympathique sans être ennuyeux ou offensant.

Recommandations générales

Utilisez un message par cas d’erreur.

En-têtes

  • Restez bref et expliquez de manière concise quel est le problème ou idéalement ce qu’il faut faire.
    Certaines surfaces d’interface utilisateur peuvent avoir des titres tronqués au lieu de les faire aller à la ligne quand ils sont trop longs, soyez attentif à ça.
  • Utilisez la solution dans le titre s’il s’agit d’une étape simple.
  • Vérifiez que le titre est directement lié au bouton si le lecteur ignore le texte du corps.
  • Évitez d’utiliser « Il y a eu un problème » dans les titres, sauf si vous n’avez pas d’autre choix. Soyez plus précis sur le problème.
  • Évitez d’utiliser des variables (comme des noms de fichier, de dossier et d’application) dans les titres. Mettez-les dans le corps.

Corps

  • Si le titre explique suffisamment le problème ou la solution, vous n’avez pas besoin de texte de corps.

  • Ne répétez pas le titre dans le message en utilisant une formulation légèrement différente.

  • Communiquez clairement et de manière concise pour décrire la solution.

  • Présentez les faits en premier.

  • Ne blâmez pas les utilisateurs pour l’erreur.

  • Si un code d’erreur est associé à l’erreur et que vous pensez qu’il pourrait aider le client ou le support Microsoft à rechercher le problème, ajoutez-le directement sous le texte du corps et écrivez-le de la façon suivante :

    Code d’erreur : ####

    Si le client a toutes les informations nécessaires pour résoudre l’erreur sans le code, vous n’avez pas besoin de l’ajouter.

Boutons

  • Écrivez le texte du bouton pour qu’il réponde spécifiquement à l’instruction principale. Si ce n’est pas possible, utilisez « Fermer » pour un bouton qui permet d’ignorer (au lieu de « Ok » ou « Terminé »).
  • Si vous avez plusieurs boutons, utilisez le bouton le plus à gauche pour l’action que l’utilisateur est invité à faire. Le bouton le plus à droite est destiné à l’action la plus conservatrice, comme « Annuler ».

Utilisez des liens d’aide seulement pour les messages d’erreur que vous ne pouvez pas rendre spécifiques et actionnables.

Texte d’état Null

Voici de l’aide tirée du Guide de style Windows.

L’état Null se produit quand les données ou le contenu du client sont absents d’une application ou d’une fonctionnalité, quand aucun résultat n’est retourné après une recherche ou quand les informations nécessaires sont manquantes dans un formulaire, comme les informations de facturation pour une transaction.

Consignes

  • Si possible, utilisez des situations d’état Null pour éduquer les utilisateurs sur la façon d’utiliser la fonctionnalité (par exemple, comment ajouter de la musique, où trouver des images, etc.)
    • Si vous avez un titre dans votre interface utilisateur, expliquez l’action à faire pour « corriger » l’état Null (par exemple, « Ajouter de la musique »)
    • Amusez-vous avec le texte. Cet espace peut être l’occasion de faire sourire puisque l’utilisateur n’aura probablement pas l’occasion de le voir plusieurs fois.
    • Évitez « Il n’y a pas beaucoup de monde par ici. » C’est triste et a été surutilisé.
    • Évitez les questions de type « Vous n’avez pas connecté votre imprimante ? » Vous pouvez l’utiliser une fois, mais ce format a tendance à être surutilisé, et les questions rajoutent du poids/une pression supplémentaire sur le client. Cela peut aussi sembler condescendant.
    • La variété dans le texte d’état null est une bonne chose.

Exemples

  • « Ajoutez quelqu’un à vos favoris pour le voir ici. »
  • « Vous avez des succès ou des extraits de jeu dont vous êtes particulièrement fier ? Ajoutez-les à votre vitrine. »
  • « Personne ne fait la fête. Lancez-en une ! »
  • « Quand quelqu’un vous ajoute comme ami, vous le voyez ici. »
  • « Quand vous déverrouillez des succès, enregistrez des extraits de jeu ou ajoutez des amis, tout s’affiche ici. »
  • « Vos amis préférés s’affichent ici, vous pouvez donc voir quand ils sont en ligne et ce qu’ils font. »

Ponctuation

  • Aucune ponctuation de fin (points, points d’interrogation) pour les titres ou les phrases incomplètes. L’exception est pour les boîtes de dialogue de confirmation, quand le titre pose une question
  • Utilisez les conseils du Guide de style Microsoft sur les points et les points d’interrogation.

Messages d'état

Les messages d’état se composent de messages contextuels (toast) et de notifications.

Type string Remarques
Pain grillé Cas de phrase avec ponctuation de fin, idéalement avec une variable d’objet pour que les utilisateurs puissent comprendre à quel objet le message s’applique au cas où ils s’en soient éloignés
Titre de notification Cas de phrase sans ponctuation de fin (il s’agit d’un titre), idéalement avec une variable d’objet
Détails de la notification Phrases complètes, idéalement avec un lien vers l’interface utilisateur qui affiche l’objet

Voici des recommandations détaillées pour les messages de notification :

Type string Remarques
Démarré Omettre si possible. Généralement, vous pouvez simplement passer au message de progression pour réduire le nombre de distractions.
En cours Commencez par le verbe de l’action que vous effectuez et terminez par des points de suspension pour indiquer une opération en cours. Voici un exemple :
Création du volume « Customer data »...

Quand il y a plusieurs variables, utilisez ce modèle :
Suppression de la machine virtuelle suivante : {0} ; Hôte : {1}
Succès Commencez par « Réussite » et terminez par ce que le logiciel vient de faire. Voici un exemple :
Le volume « Customer data » a été créé.
Échec Commencez par « Impossible » et terminez par ce que le logiciel n’a pas pu faire. Voici un exemple :
Impossible de créer le volume « Customer data ».

Info-bulles

Les bonnes info-bulles décrivent brièvement les contrôles sans étiquette ou fournissent un peu d’informations supplémentaires pour les contrôles étiquetés, quand cela est utile. Elles peuvent également aider les clients à naviguer dans l’interface utilisateur en offrant des informations supplémentaires (non redondantes) sur les étiquettes de contrôle, les icônes, les liens, etc.

Les info-bulles doivent être utilisées avec parcimonie ou pas du tout. Elles peuvent interrompre le client, donc n’ajoutez pas d’info-bulle qui répète simplement une étiquette ou indique une évidence. Elles doivent toujours ajouter des informations précieuses.

Contexte Comment écrire les info-bulles
Quand un contrôle ou un élément d’interface utilisateur n’est pas étiqueté... Utilisez une expression nominale simple et descriptive. Par exemple :
Surligneur
Quand un élément d’interface utilisateur est étiqueté, mais que son objectif doit être clarifié...
  • Décrivez brièvement ce que vous pouvez faire avec cet élément d’interface utilisateur.
  • Utilisez un verbe impératif. Par exemple, « Rechercher du texte dans ce fichier » (et non « Recherche du texte dans ce fichier »).
  • N’ajoutez pas de ponctuation de fin, sauf s’il y a plusieurs phrases complètes.
Quand une étiquette de texte est tronquée ou susceptible d’être tronquée dans certaines langues...
  • Indiquez l’étiquette non tronquée dans l’info-bulle.
  • Facultatif : sur une autre ligne, fournissez une description qui clarifie, mais uniquement si nécessaire.
  • Ne fournissez pas d’info-bulle si les informations non tronquées sont fournies ailleurs dans la page ou le flux.
Si un raccourci clavier est disponible...
  • Facultatif : indiquez le raccourci clavier entre parenthèses après l’étiquette ou l’expression descriptive, par exemple, « Imprimer (Ctrl+P) » ou « Rechercher du texte dans ce fichier (Ctrl+F) »
  • Vous pouvez ajouter un raccourci clavier utile à une info-bulle qui clarifie, mais évitez d’ajouter une info-bulle uniquement pour montrer un raccourci clavier.