Définissez des décisions, pas seulement une galerie de styles
Un système de design, ce n'est pas que des captures d'écran. Il enregistre les décisions récurrentes : l'espacement entre les sections, le traitement de l'action primaire, le fonctionnement d'une erreur de formulaire et le langage utilisé après un succès ou un échec. USWDS décrit les design tokens (jetons de design) comme des palettes distinctes pour des valeurs telles que la typographie, les espacements, la couleur, la hauteur de ligne et l'opacité. Documentez la règle, son objectif, les variantes approuvées et le responsable. Commencez par les fondations et les cinq à huit composants les plus utilisés dans les parcours importants ; standardiser chaque page d'un coup crée en général du bruit plutôt que de la clarté.
Enregistrez les rôles de couleur approuvés, la typo, les espacements, les bordures, les rayons, les points de rupture et les choix d'animation réellement utilisés sur votre site.
Privilégiez un motif pour une disposition de tâche répétable, comme la création de compte ou les résultats de recherche, plutôt que pour un simple effet visuel isolé.
Utilisez des tokens pour contrôler les valeurs répétées
Un design token est un nom lisible associé à une valeur. Le Design Tokens Community Group décrit les tokens comme une façon indépendante de la plateforme d'exprimer des décisions de design ; au minimum, un token est un nom et une valeur. Utilisez des noms d'usage comme color-action-primary ou space-section plutôt que de disperser des valeurs brutes dans les gabarits. Conservez un mappage documenté des tokens d'usage vers les valeurs de base. Les tokens facilitent les changements coordonnés, mais ils ne garantissent pas le contraste, l'identité visuelle ou une bonne hiérarchie. Validez chaque combinaison rendue et chaque état de page.
Créez des tokens pour les choix répétés, pas pour chaque exception ; sinon la liste de tokens ne fait que préserver l'incohérence.
Pour un token largement utilisé, listez les pages affectées, testez des écrans représentatifs et fournissez des directives de migration ou de retour arrière si nécessaire.
Construisez des composants avec comportement et limites
Un composant est une partie d'interface réutilisable avec un comportement, pas seulement une forme visuelle. Documentez la structure sémantique, les entrées obligatoires et optionnelles, les variantes, le comportement réactif et tous les états pertinents : chargement, désactivé, erreur, vide et succès. Incluez le comportement au clavier et les consignes de contenu. Ne forcez pas chaque mise en page dans un composant. GOV.UK évalue les composants partagés selon leur utilité, leur unicité, leur utilisabilité, leur cohérence et leur polyvalence ; c'est une discipline utile pour décider de ce qui mérite une maintenance partagée. Un composant largement réutilisé peut aussi propager un défaut à grande échelle, donc testez-le dans les pages où les gens l'utilisent.
Listez chaque état visible par l'utilisateur et montrez des libellés réels, des textes longs et des erreurs afin que les limites d'implémentation soient visibles.
Marquez clairement les anciennes variantes, nommez le remplacement et ne les supprimez qu'après examen des parcours affectés.
Faites de l'accessibilité une condition de mise en production
L'accessibilité doit être intégrée au système parce que les choix répétés peuvent répéter des barrières. WCAG 2.2 exige, au niveau A, l'opération au clavier pour les fonctionnalités sauf lorsque le trajet de mouvement est inhérent, et exige un ordre de focus signifiant lorsque la séquence importe. Faites des contrôles sémantiques, d'un focus visible, des labels, d'un mouvement logique du focus, de l'identification des erreurs et de l'exécution des tâches sans pointeur des éléments de guidance de composant. Utilisez des vérifications automatisées tôt, puis des tests manuels au clavier, en zoom, en responsivité et des tests de pages. USWDS met en garde que des composants accessibles ne garantissent pas un service accessible ; le code personnalisé, les textes, les intégrations et le contexte doivent toujours être revus.
Vérifiez que les personnes peuvent atteindre, utiliser, comprendre et quitter les contrôles sans souris et qu'il n'existe pas de piège de clavier.
Les obligations légales varient selon la juridiction et le contrat. Consultez des spécialistes accessibilité et juridiques qualifiés lorsque la conformité est importante.
Traitez les normes de contenu comme des normes d'interface
Les mots sont des entrées de composants, pas une décoration ajoutée après le design. Établissez des règles pour les libellés d'action, les étiquettes de formulaire, les messages d'erreur, les titres, les liens, la terminologie, les dates, les nombres et les abréviations. Les consignes GOV.UK favorisent la voix active et le tutoiement du lecteur lorsque c'est possible ; appliquez le principe d'un langage clair et cohérent, tout en adaptant la tonalité à votre public. Associez les règles à un modèle de contenu : indiquez quels champs sont obligatoires, des orientations de longueur raisonnables et ce qui se passe lorsque l'information fait défaut. Placez ces consignes dans la documentation des composants et les flux de travail du CMS, où les éditeurs peuvent s'en servir.
Indiquez ce qui a échoué, où cela s'est produit et l'action suivante quand il est sûr et utile de le faire.
Une limite est un signal pour repenser la conception ou la réécriture, pas une permission de supprimer un sens essentiel.
Gérez le système avant qu'il ne croisse plus vite que la confiance
La gouvernance est le processus léger pour la propriété, les demandes, la revue, les publications et la mise à la retraite. Nommez un propriétaire responsable et un groupe de revue capable d'apporter design, engineering, contenu et expertise accessibilité. Adaptez les preuves au rayon d'impact (blast radius). Un motif local peut nécessiter une problématique et un test de page. Un changement partagé de bouton ou de token devrait inclure les parcours affectés, des vérifications d'accessibilité, une comparaison visuelle, des notes de migration et des instructions de rollback. GOV.UK demande aux contributeurs de démontrer qu'un composant est utile pour de nombreuses équipes, qu'il n'est pas un doublon et qu'il a été testé avec des utilisateurs représentatifs ; utilisez cela comme modèle pratique plutôt que comme une règle universelle.
Sauvegardez le problème, les options, la décision, le propriétaire, la version affectée et la date de revue dans un endroit consultable par les équipes.
Étiquetez les changements comme patch, additive ou breaking afin que les consommateurs sachent quand une migration et une période de compatibilité sont nécessaires.
Prévenez les régressions avant la mise en production
Connectez le système à la livraison. Exigez qu'une modification identifie les tokens et composants touchés, puis testez les états affectés et des pages représentatives. La comparaison visuelle, les tests d'interaction, la revue de contenu et les vérifications d'accessibilité détectent des types de défauts différents. Priorisez les parcours à fort enjeu ainsi que ceux à fort trafic ; l'accès au compte et les formulaires de contact peuvent être importants même lorsque le trafic est modeste. Cela soutient le travail d'optimisation proactive et de remédiation de Status Is UP en réduisant le périmètre des défauts et en rendant plus simple la vérification d'une correction approuvée. Ce n'est pas de la surveillance de disponibilité ni un substitut à un plan d'incident.
Conservez la version du composant, les résultats de test, les conclusions, les approbations et tout risque accepté avec l'enregistrement de la publication.
Préservez la version stable antérieure et testez les étapes d'annulation et de vérification écrites pendant une maintenance à faible risque.