Réponse en bref
Les exemples de design d’interface les plus utiles arrivent avec leurs raisons. Des systèmes publics comme GOV.UK et USWDS documentent chaque motif : un bouton principal par page, des formulaires verticaux aux contrôles groupés, des messages d’erreur précis près du champ et des tableaux avec légende et en-têtes. WCAG 2.2 ajoute une règle mesurable pour les cibles tactiles. Transformez chaque exemple en règle et en raison avant de rédiger le brief.
Lisez la règle derrière chaque exemple de design d’interface
Les exemples de design d’interface sont le plus souvent des captures : un écran net, une jolie palette et une légende qui dit pourquoi il est bon. La capture ne dit pas ce que le designer a écarté ni ce qui s’est passé quand de vrais utilisateurs l’ont rencontrée. Un écran est facile à admirer et difficile à réutiliser, car le lecteur copie l’aspect et manque la raison.
Les systèmes de design publics donnent la raison par écrit. Le système de design GOV.UK et le système de design web américain, USWDS, publient chaque composant avec des consignes sur quand l’utiliser, quand ne pas l’utiliser et quoi écrire dedans. Ils ont été faits pour des services publics qui doivent fonctionner pour tous, leurs règles sont donc prudentes, et des règles prudentes forment un bon premier brouillon pour une application d’entreprise. On peut toujours assouplir une règle quand on a des données sur ses propres utilisateurs, mais il est plus difficile d’ajouter du soin à un écran conçu sans lui.
Boutons : une action principale et une étiquette honnête
Le système de design GOV.UK dit d’utiliser un bouton par défaut pour l’appel à l’action principal d’une page et d’en éviter plusieurs, car plus d’un appel principal réduit l’impact de chacun. Les boutons secondaires servent aux appels secondaires. La page avertit aussi que les pages à trop d’appels à l’action compliquent la compréhension de la suite.
Les étiquettes méritent le même soin. GOV.UK demande une majuscule seulement au premier mot et une description de l’action, avec des exemples comme Start now, Sign in, Save and continue et Sign out, et admet des mots supplémentaires pour la clarté, comme Add another address. Un bouton qui dit Envoyer n’explique rien de ce qui va se passer. Un bouton qui dit Enregistrer et continuer explique les deux.
Deux autres règles valent d’être reprises. Les boutons d’avertissement sont réservés aux actions aux conséquences destructrices graves que l’utilisateur ne peut pas facilement annuler, et GOV.UK dit qu’ils ne fonctionnent que s’ils sont utilisés très parcimonieusement. Et les boutons désactivés sont à éviter si possible, car leur contraste est faible et ils peuvent dérouter ; on ne les emploie que si la recherche montre qu’ils rendent l’interface plus compréhensible.
Formulaires : un schéma vertical aux contrôles groupés
USWDS donne ses consignes de formulaire en lignes brèves et vérifiables. Gardez les blocs du formulaire selon un schéma vertical, adapté aux personnes à vision limitée. Marquez les champs obligatoires d’un astérisque rouge et expliquez la marque par un texte en haut du formulaire. Étiquetez les champs facultatifs avec le mot optional entre parenthèses. Un formulaire à un seul champ n’a pas besoin de marqueur d’obligation.
La structure compte autant que l’apparence. USWDS dit de grouper chaque ensemble de contrôles thématiquement liés dans un fieldset à une légende, et d’afficher les contrôles dans le HTML dans le même ordre qu’à l’écran, car les lecteurs d’écran lisent dans l’ordre du HTML. Un designer qui le sait dessine le formulaire de sorte que le développeur le construise correctement du premier coup.
Messages d’erreur qui disent quoi faire ensuite
GOV.UK traite le message d’erreur comme un élément d’interface aux règles propres. Il s’affiche près du champ et dans un résumé des erreurs en haut de page, avec le même texte aux deux endroits. Il explique ce qui s’est mal passé et comment le corriger, en langage simple et en termes positifs. Il évite les phrases génériques comme An error occurred ou This field is required.
La page distingue deux cas. Pour un champ vide, donnez une instruction, comme Enter your first name. Pour une saisie erronée, donnez une description, comme Name must be 35 characters or less. Elle demande aussi aux rédacteurs d’éviter les mots please, sorry, valid, invalid et oops, car ils ajoutent du bruit ou accusent l’utilisateur.
L’emplacement fait partie de la règle : le message suit la question et le texte d’aide, en rouge, avec une bordure rouge qui le relie à la question. Et le formulaire ne doit pas effacer les champs. Gardez les réponses correctes et incorrectes, pour que l’utilisateur voie et modifie ce qu’il a saisi. Ce seul comportement distingue un formulaire poli d’un formulaire qui punit.
Tableaux de données : comparer en lignes et en colonnes
Le composant tableau de GOV.UK sert à laisser les utilisateurs comparer des informations en lignes et en colonnes, et la page dit de ne jamais l’utiliser pour mettre en page du contenu. Chaque tableau reçoit une légende, écrite comme un titre, et des en-têtes qui disent ce que représentent lignes et colonnes. L’attribut scope permet aux technologies d’assistance de distinguer en-têtes de ligne et de colonne.
Un détail est facile à manquer et facile à copier : quand on compare des colonnes de nombres, alignez les nombres à droite dans leurs cellules. L’œil compare alors les chiffres à la même position. Sur un téléphone, les tableaux larges tiennent rarement : décidez donc tôt si la version mobile est un tableau défilant ou une liste de cartes, et concevez les deux avant le développement. Un tableau qui paraît bien avec cinq lignes inventées peut échouer avec cinquante réelles.
Cibles tactiles : la seule règle mesurable
Le goût ne se mesure pas, mais la taille d’une cible, si. Le critère de succès 2.5.8 de WCAG 2.2, de niveau AA, dit que la taille de la cible pour les entrées de pointeur est d’au moins 24 par 24 pixels CSS, avec des exceptions. L’une couvre les cibles trop petites placées de sorte qu’un cercle de 24 pixels centré sur chacune ne croise aucune autre cible. Les autres sont équivalent, en ligne, contrôle de l’agent utilisateur et essentiel.
En pratique, les boutons d’icône ont besoin de marge et pas seulement d’un petit glyphe, et les liens serrés sur une ligne ont besoin d’espace entre eux. Le minimum est un plancher, non une recommandation, et une cible confortable pour le pouce est souvent plus grande. Inscrivez la taille de cible dans le système de design comme un nombre, pour que chaque composant l’hérite au lieu que chaque designer décide à nouveau. Un nombre donne aussi à celui qui teste l’application terminée quelque chose à vérifier.
Transformez chaque exemple en règle, raison et écran
Pour utiliser des exemples de design d’interface dans un brief, écrivez trois lignes pour chacun. D’abord la règle, en une phrase : un bouton principal par écran. Puis la raison, tirée de la source : plus d’une action principale réduit l’impact de chacune. Puis l’écran de votre produit où elle s’applique : le paiement, le formulaire de réservation, les réglages. Les exemples sans troisième ligne restent de la décoration.
Énumérez ensuite ce que l’application doit montrer au-delà du chemin heureux. Tout formulaire a un état d’erreur, toute liste un état vide, toute requête un état lent. Les systèmes publics en décrivent certains en détail, et vous écrivez le reste. Un designer qui reçoit les règles, les raisons et les états construit un prototype qui répond à de vraies questions, non un prototype qui ressemble seulement à la galerie.
Que préparer avant de commander le design UX et UI d’une application
Préparez les trois à cinq tâches qu’un utilisateur doit accomplir, les personnes qui les feront, les appareils qu’elles utilisent et les règles que vous avez tirées des exemples. Ajoutez le contenu de chaque écran, les messages d’erreur que vous pouvez écrire dès aujourd’hui et les intégrations dont dépendent les écrans. Décidez qui peut valider un écran et à quelle vitesse, car l’attente de retours est une cause fréquente de retard.
Si vous voulez confier le travail à un studio, App UX/UI design chez VITON13 Studio couvre jusqu’à 3 parcours utilisateur, 15 écrans principaux avec leurs états, 30 composants et un prototype cliquable. Il coûte à partir de $93 assisté par IA ou $113 mené par des humains, en 8–15 jours ouvrés. Plus vous apportez de règles et d’états, moins ce temps est consacré aux questions.
Checklist pratique
- Choisissez trois pages de systèmes de design publics et écrivez la règle et la raison de chacune en une phrase.
- Nommez l’action principale de chaque écran de votre application et donnez-lui une étiquette à verbe.
- Rédigez dès maintenant le texte d’erreur de chaque champ de formulaire : instruction ou description.
- Fixez dans le système de design une taille minimale de cible, à partir de 24 par 24 pixels CSS.
- Listez les états vide, d’erreur et lent de chaque liste et formulaire avant d’envoyer le brief.
Questions et réponses
Où trouver de bons exemples d’interface qui s’expliquent d’eux-mêmes ?
Dans les systèmes de design publics. GOV.UK et USWDS publient chaque composant avec des consignes sur quand l’utiliser, quoi écrire et quoi éviter, de sorte que vous voyez le raisonnement et pas seulement le résultat.
Une application d’entreprise peut-elle copier un système de design public ?
Copiez les règles, pas l’apparence. Vérifiez la licence et les conditions de chaque système avant de réutiliser du code ou des ressources. Les consignes sur étiquettes, erreurs et structure se transposent ; la marque et la couleur sont à vous.
Quelle taille un bouton doit-il avoir sur un téléphone ?
WCAG 2.2 fixe un minimum de 24 par 24 pixels CSS pour les cibles de pointeur au niveau AA, avec une exception d’espacement. Prenez-le comme plancher et testez avec de vrais pouces sur de vrais appareils.
Les boutons désactivés sont-ils toujours une erreur ?
GOV.UK conseille de les éviter à cause de leur faible contraste et du risque de confusion, et ne les admet que si la recherche montre qu’ils rendent l’interface plus compréhensible. Si vous devez en utiliser un, affichez la raison.
Que doit contenir un brief d’interface en plus des captures ?
Les tâches des utilisateurs, les règles et raisons à appliquer, le contenu, les états au-delà du chemin heureux et les appareils. Les captures montrent le goût ; le reste dit au designer ce que les écrans doivent faire.