Décisions clés
- La version acceptée est identifiable.
- Sources et exports sont distincts.
- Conditions d’usage et crédits sont présents.
- Les états requis sont inclus.
Identifier la source approuvée
Listez fichiers éditables, exports et document qui désigne la version acceptée. Expliquez qui modifie la source et où conserver les révisions. Le mot ‘final’ dans un nom ne suffit pas quand plusieurs versions circulent. Gardez conditions des polices, photos et ressources. Posséder un fichier ne donne pas un usage illimité. Le destinataire doit distinguer résultat courant et variantes qui ne sont plus approuvées.
Montrer les comportements du design
Incluez états normal, sélectionné, vide, chargement et erreur lorsqu’ils appartiennent au projet. Pour une identité, montrez tailles et fonds utiles. Expliquez les décisions apparemment arbitraires, comme un libellé plus long traduit. MDN apporte un contexte de planification avant développement. Cette structure est une recommandation éditoriale, pas un ensemble contractuel universel. Les états volontairement exclus doivent être explicitement nommés.
Expliquer les exports
Dites quel fichier va au web, lequel reste éditable et lequel exige une préparation supplémentaire. Gardez noms descriptifs et liste des ressources. Le texte alternatif d’une image dépend de son rôle ; W3C explique cette distinction. Le designer décrit l’usage prévu et le propriétaire de page confirme le contexte réel. Une même étiquette ne devrait pas être copiée mécaniquement dans tous les emplacements.
Essayer une tâche en aval
Demandez au destinataire de construire ou placer un élément avec le seul dossier. Observez ses demandes d’explication et ajoutez la réponse à la note commune. Corrigez les fichiers si nécessaire. Séparez décisions ouvertes et travail approuvé. La transmission est complète dans son périmètre quand chacun sait quoi utiliser et quoi résoudre. Elle ne change pas automatiquement les livrables d’une commande déjà convenue.
Essayez l’exercice
Préparez un bouton fictif d’inscription : état normal, erreur et écran étroit, liste d’exports et question de texte ouverte.
Résultat attendu
Un petit dossier et une note permettant d’identifier la version approuvée sans deviner. Les livrables d’une commande existante restent ceux de son accord.
Votre liste de preuves
Cochez seulement ce que vous avez vérifié. Cette liste décrit votre progression, pas un audit indépendant ni une prévision. Il n’y a pas d’enregistrement automatique ; téléchargez la note pour la conserver.
0 / 6 vérifiés
Questions et réponses
Le fichier source termine-t-il la transmission ?
Il termine une partie. Le destinataire doit aussi connaître version approuvée, conditions et décisions ouvertes. Essayez une tâche représentative pour découvrir le contexte manquant avant de considérer la transmission complète. Un fichier éditable n’explique pas seul sa bonne utilisation.
Faut-il concevoir tous les états imaginables ?
Accordez les états liés aux tâches réelles et couvrez les erreurs importantes avant les variantes spéculatives. Nommez ce qui est exclu. L’équipe de développement ne devrait pas prendre une absence pour un comportement approuvé ni deviner une exigence jamais décidée.
Prochaine étape
Transmettez les fichiers et le raisonnement qui les rend utilisables dans la prochaine tâche.
Sources et vérification
- W3C WAI — Images tutorial ↗
Vérifié:
- MDN — Thinking before coding ↗
Vérifié: