đŹđ§ If you want to translate this checklist into your language, feel free to create a pull request with the translation !
Jâai conçu cette checklist, basĂ©e sur celle de David Dias, afin de de simplifier la collaboration entre les designers et les dĂ©veloppeur·euse·s. Il est primordial pour les designers de prendre en considĂ©ration lâaspect technique lors de la conception pour Ă©viter des problĂšmes dâintĂ©gration lors du dĂ©veloppement. Ces deux mĂ©tiers sont complĂ©mentaires et je suis convaincu que chacun·e doit connaĂźtre les contraintes de lâautre pour un rendu optimal.
Si vous ĂȘtes designer, je peux vous garantir quâen utilisant cette checklist les dĂ©veloppeur·euse·s vous seront trĂšs reconnaissant·e·s. Ă lâinverse, si vous ĂȘtes dĂ©veloppeur·euse, adaptez cette checklist Ă votre mĂ©thodologie et partagez lĂ aux designers avec qui vous travaillez.
Cette checklist est Ă©galement disponible sur Notion đ
Pour faciliter le workflow (export des assets, comprĂ©hension du design), je ne travaille plus quâavec Figma et Adobe XD qui selon moi sont les meilleurs du marchĂ© et disponible sur toutes les plateformes. Pour avoir essayĂ© les deux, je recommande Figma sans hĂ©siter.
Si tu fais partie des dinosaures qui nâutilise pas encore un de ces deux outils, comment procĂšdes-tu ?
- Tous les composants sont créés avec l'approche « Atomic Design ». Dans le cas contraire, des problÚmes peuvent survenir en termes de performance et de maintenabilité du projet.
- Un styleguide (aussi appelé « guide de style ») au format Figma ou Adobe XD est fourni : il regroupe tous les éléments, composants, styles et dimensions utilisés dans le design.
Ressources :
- đ Atomic Design : Complete Guide â Brad Frost
- đ Everything you need to know about Design Systems â Audreys Hacq
- đ How To Create a Complete Web Design Style Guide
- đ Styleguides.io â Ressources pour la crĂ©ation de styleguides (exemples, outils, articles, etc.)
- Pour les mises en page standard (colonnes et lignes), tous les éléments sont gérés via des « Auto Layout » sur Figma ou « Stacks » sur Adobe XD
- Pour les mises en page complexes, notamment des Ă©lĂ©ments qui se chevauchent, des grille standardisĂ©es sont utilisĂ©es. Tous les dĂ©tails de celles-ci (largeur, gouttiĂšres, nombre de colonnes, marges) doivent ĂȘtre spĂ©cifiĂ©s. Le standard actuel est dâutiliser un multiple de 8 pour les gouttiĂšres et un nombre pair de colonnes (4 pour mobile et 12 pour desktop).
Proposition de configuration de grille se basant sur les tailles dâĂ©crans standards
Exemple de l'utilisation dâune grille avec sa dĂ©clinaison mobile
Ressources :
- đ Responsive layouts grid guide for designers pour comprendre le fonctionnement dâune grille
- đ Grid Calculator pour calculer vos tailles de colonnes
- đ Guide : CrĂ©er et gĂ©rer ses grilles sur Figma
- đ Guide : CrĂ©er et gĂ©rer ses grilles sur Adobe XD pour crĂ©er et gĂ©rer ses grilles
- Toutes les couleurs utilisées dans les créations sont nommées en anglais de maniÚre cohérente.
gray-light, gray-dark, green
body-background, body-copy, text-paragraph - Le niveau de contraste pour tous les éléments graphiques est au minimum « AA »
Ressources :
- đ WCAG : Contrast Checker pour vĂ©rifier le niveau de contraste
- đ MDN : Contraste de la couleur - AccessibilitĂ©
- Deux polices de caractĂšres maximum (trois en cas dâapplication trĂšs complexe) sont utilisĂ©es pour le design et celles-ci sont optimisĂ©es pour le web.
- Les polices pour le bureau (TTF ou OTF en général) et les polices pour le web, au format WOFF et WOFF2 ont été fournies (toutes variantes comprises).
- Des polices de secours (aussi appelées « fallback fonts ») sont spécifiées.
- Le poids total de toutes les polices ne dépasse pas 1 à 2 Mo, toutes variantes comprises.
- Dans la mesure du possible, tous les textes sont fournis dans la langue appropriĂ©e au lieu de textes factices comme du Lorem Ipsum. Cela est encore plus important pour les applications multilingues car la longueur dâune section ou dâun titre peut varier dâune langue Ă lâautre.
Ressources :
- đ Les bases de la typographie web â Raidboxes
- đ Google Webfonts Helper pour tĂ©lĂ©charger les polices Google en local
- đ Transfonter pour convertir les polices au format web et gĂ©nĂ©rer le CSS appropriĂ©
- Toutes les images (JPEG, PNG) doivent ĂȘtre fournies en rĂ©solution 1x et 2x afin de supporter les Ă©crans Retina. Je mâoccupe ensuite de convertir les images en format « Next Gen » (WEBP, AVIF) avec Squoosh ou similaire.
- Une image de favicon d'au moins
512px*512pxest fournie au format PNG, JPG ou SVG. La gĂ©nĂ©ration de tous les autres favicons peut ĂȘtre facilement rĂ©alisĂ©e avec des Favicon Generator. - Une image « open graph » de
1200px*600pxest fourni au format JPEG. Elle sera utilisĂ©e par dĂ©faut lorsque le site sera partagĂ© sur les rĂ©seaux sociaux. - Toutes les icĂŽnes sont fournies au format SVG, chacune ayant le mĂȘme ratio, en noir et optimisĂ©s pour le web avec SVGOMG (tout cocher sauf les cases qui modifient le rendu final). Le nom de chaque icĂŽne commence par
icon-et est entiÚrement en minuscules (sans espace et en utilisant des tirets pour séparer chaque mot).
Ressources :
- đ Favicon Generator pour gĂ©nĂ©rer toutes les versions du favicon
- đ SVGOMG pour optimiser les SVG
- Tous les liens ont quatre Ă©tats dĂ©finis : lâĂ©tat par dĂ©faut, lâĂ©tat de survol, lâĂ©tat focus et lâĂ©tat inactif.
- Tous les Ă©lĂ©ments du menu ont six Ă©tats dĂ©finis : lâĂ©tat par dĂ©faut, lâĂ©tat actif (page courante) lâĂ©tat de survol, lâĂ©tat cliquĂ©, lâĂ©tat focus et lâĂ©tat inactif.
- Tous les liens externes (qui renvoient vers un autre site) sont identifiables par leur style. Je recommande lâutilisation dâun icĂŽne SVG comme celui utilisĂ© par Mozilla, Ă placer sur la droite du lien.
- Tous les champs de saisie ont cinq Ă©tats dĂ©finis : lâĂ©tat par dĂ©faut, lâĂ©tat de survol, lâĂ©tat focus, lâĂ©tat erreur et lâĂ©tat inactif.
- Tous les boutons ont cinq Ă©tats dĂ©finis : lâĂ©tat par dĂ©faut, lâĂ©tat de survol, lâĂ©tat cliquĂ©, lâĂ©tat focus et lâĂ©tat inactif.
- Les boutons primaires et secondaires sont clairement identifiables et sont utilisés selon les bonnes pratiques web.
- Les champs obligatoires sont identifiables par le style grĂące Ă une icĂŽne et/ou une couleur.
- Des exemples de messages dâerreurs sont fournis. Leur position et leur couleur sont clairement identifiables.
Ressources :
- đ Forms Need Validation â Andrew Coyle
- đ Primary & Secondary Action Buttons â UX Planet
- đ Design Better Forms â Andrew Coyle
- đ Design Better Input Fields â Andrew Coyle
- đ Designing Perfect Text Field: Clarity, Accessibility and User Effort â Nick Babich
- đ Button UX Design: Best Practices, Types and States â Nick Babich
- La version mobile de la conception est fournie avant ou en mĂȘme temps que la version de desktop.
Si l'équipe de création n'a pas suivi le principe du « mobile first », certaines irrégularités et incohérences peuvent apparaßtre entre la version mobile et la version de bureau. Vérifiez et signalez ces problÚmes avant de commencer le développement du projet.
- En cas de structure de page complexe ou dâanimations spĂ©cifiques, la version tablette du design doit Ă©galement ĂȘtre prĂ©vue.
- Pour tous les sites web, au moins 2 versions du design sont fournis (mobile, desktop et Ă©ventuellement tablette) ainsi que le styleguide.
- Les fichiers Figma ou Adobe XD sont nettoyĂ©s avant d'ĂȘtre livrĂ©s. Les calques vides et inutiles doivent ĂȘtre supprimĂ©s pour faciliter lâintĂ©gration.
- La page d'erreur 404 et éventuellement la page d'erreur 500 ont été conçues.
- Les pages Mentions légales et Politique de confidentialité ont été conçues (pages de texte simples).
- Tous les composants ont été validés par le·la développeur·euse comme réalisables techniquement et compatibles avec la stack technique qui sera utilisée
Ressources :
- Auteur : Benjamin Haeberli
- Contributeurs : Tous les contributeurs
- Inspirée de la Front-End-Design-Checklist
- License : GNU GPLv3