Définir une interface lisible, ses composants et leurs états.
Ces fiches décrivent des activités et des exercices pédagogiques. Elles ne constituent ni des offres d’emploi, ni des parcours certifiants, ni des promesses de recrutement.
Toutes les fiches métiers
Rendre les écrans et les composants lisibles, cohérents et utilisables. Le design UI organise hiérarchie visuelle, typographie, couleurs, espacements et états d’interaction dans la charte du produit.
Une maquette ne démontre pas à elle seule l’accessibilité ou la faisabilité. Le travail se confronte aux retours UX, aux contraintes de développement et aux tests de l’interface réelle.
Livrer un composant avec ses états, ses règles de contenu et ses critères de contrôle, plutôt qu’un écran idéal isolé.
Ce repère éditorial décrit des activités fréquentes. Les intitulés et périmètres varient selon les équipes ; il ne constitue pas un référentiel de certification.
W3C : organiser les responsabilités d’accessibilité dans une équipe
Concevoir la même fiche produit avec un nom long, une image absente et une erreur de sélection.
Travaillez sur une copie ou un environnement de démonstration. Définissez les données utilisées et le résultat attendu avant de commencer. Conservez vos décisions et les difficultés rencontrées afin de pouvoir expliquer la démarche.
Des écrans, une bibliothèque de composants et des spécifications d’états compréhensibles par l’intégration.
Des règles explicites et des composants qui restent compréhensibles dans leurs états moins favorables.
Pour chaque contrôle, notez le contexte, l’action, le résultat attendu et ce qui a été observé. Distinguez une vérification réussie d’une hypothèse restant à confirmer. Une autre personne doit pouvoir comprendre le livrable sans assister à toute sa fabrication.
Préparer les vérifications du siteUne maquette présentant uniquement le cas idéal ne décrit pas le fonctionnement de l’interface. Les textes traduits et les contenus incomplets doivent aussi être examinés.
Collaboration à explorer : Intégration web.
Précisez le partage des responsabilités : qui fournit les informations, qui tranche, qui vérifie et qui entretient le résultat. Un bon passage de relais conserve les contraintes et les décisions, pas seulement le fichier final.
Emploi, métiers et formationsPréparer un champ de formulaire qui reste compréhensible en cas d’erreur.
Une maquette visuelle doit être confrontée au composant développé avant de conclure sur son fonctionnement.
Pour présenter ce travail, précisez le contexte, votre rôle, les éléments fournis par d’autres et la version examinée. Un exemple de démonstration doit être identifiable comme tel. La personne qui relit doit pouvoir retrouver le besoin, comprendre la décision et reproduire le contrôle sans deviner les étapes manquantes.
Présentez un composant avec ses états normal, focus, erreur et indisponible, puis un écran avec contenu court et contenu long. Indiquez les informations nécessaires à l’intégration, y compris les libellés et les comportements attendus au clavier.
Une interface se juge dans ses états réels : chargement, erreur, sélection, absence de données et succès. Examinez les composants avec des textes longs et des traductions, pas seulement avec les libellés les plus courts.
| Compétence | Preuve à examiner | Erreur à repérer |
|---|---|---|
| États | Chaque champ possède libellé, aide et message d’erreur documentés. | La couleur seule indique l’erreur ou le composant actif. |
| Adaptation | Une vue étroite avec texte agrandi et contenus réalistes. | Une largeur fixe coupe une traduction ou masque un bouton. |
| Transmission | Les comportements, espacements et décisions sont identifiables. | La maquette montre un effet sans préciser son déclenchement. |
Choisissez un composant et ajoutez son état vide, son état d’erreur et un libellé deux fois plus long. Faites expliquer le comportement attendu par la personne chargée de l’intégration avant d’étendre le composant à d’autres pages.
Exercice approfondi : concevez les états d’un formulaire de demande, depuis la première saisie jusqu’au message de réception. Prévoyez le focus clavier, un champ invalide, un envoi en cours et une erreur de connexion. Travaillez avec un contenu réaliste et une traduction plus longue. Décrivez le rôle de chaque couleur et de chaque icône : une information indispensable doit aussi être exprimée par du texte. Le résultat à livrer est un système d’états cohérent, pas seulement une capture du formulaire vide.
Ces critères sont une base de travail à adapter au contexte. Pour chacun, notez l’action effectuée, le résultat attendu, le résultat observé et les informations restant à confirmer.
Livrez les composants avec leurs états, leurs textes et leurs contraintes. Indiquez ce qui relève d’une règle générale et ce qui répond à un cas particulier. Discutez des comportements avec la personne qui intègre l’interface, puis vérifiez le résultat dans le navigateur. Une maquette statique ne prouve pas à elle seule que le formulaire est utilisable au clavier ou que ses erreurs sont correctement annoncées.
Comparez une intervention sur un écran isolé et une évolution des composants partagés. Le choix dépend de la répétition du problème et des pages utilisant les mêmes éléments.
Le contraste et les tailles de police ne suffisent pas à valider l’accessibilité. Vérifiez aussi les libellés, états, relations et interactions dans l’interface réalisée.
Présentez l’écran avant et après avec la même tâche et les mêmes contenus. Vérifiez que l’amélioration reste cohérente sur une seconde page.
Il permet de montrer une démarche et ses limites. Il ne constitue ni un diplôme, ni une certification, ni la preuve d’une expérience de production.
Précisez qu’il s’agit d’un exercice, votre rôle, les contraintes, les décisions et les vérifications. Utilisez des données de test et des médias dont les droits sont établis.
Des règles explicites et des composants qui restent compréhensibles dans leurs états moins favorables. Ajoutez les difficultés rencontrées et ce qui reste à vérifier plutôt que de présenter une validation absolue.
Quand un besoin identifié ne peut pas être couvert sans rendre l’usage existant ambigu. Documentez la différence et les états concernés. Une préférence esthétique isolée ne justifie pas une variante difficile à maintenir sur toutes les pages.
