[Checklist] 10 choses que les webdesigners oublient tout le temps

Au cours de la réalisation de mes propres projets ou bien après récupération d’autres fichiers, j’ai répertorié des exemples d’éléments ou informations indispensables et pourtant souvent manquantes lorsque l’on transmet, nous designers, nos fichiers pour le développement.

Comme on a toutes et tous à cœur de fournir un projet le plus complet possible (et d’être aimés par nos ami·e·s développeurs), je partage cette check-list, à garder sous le coude pour chaque projet !

Si vous connaissez un peu l’accessibilité web, vous savez de quoi il s’agit. Si ce n’est pas le cas, ce sont des liens qui sont proposés à l’utilisateur lors de sa première tabulation sur le site. Ces liens sont généralement destinés aux personnes qui “tabulent” (c’est à dire naviguent au clavier et non pas à la souris, par exemple pour une personne aveugle).

On retrouve souvent :

• Aller au contenu : en gros, on zappe le menu de navigation

• Aller au footer

• Aller à la recherche

• Contact

On peut aussi imaginer une entrée très spécifique à un projet si l’action est prioritaire. Par exemple “Aller à la connexion”

En tant que designers, notre rôle n’est pas tellement de rendre ces liens jolis, mais surtout de les prévoir en design pour qu’ils ne risquent pas d’être oubliés en développement.

Quand on crée une maquette, c’est bien de créer des variants de composants pour par exemple les boutons e champs de saisie. On retrouve souvent :

• Style par défaut

• Au hover

• Sélectionné / Actif

• Désactivé (disabled)

• En erreur

Et bien il faut aussi l’état au focus ! C’est tout simplement l’état du composant si le focus de l’utilisateur qui “tabule” (navigue avec le clavier) arrive dessus. Le plus souvent, c’est un contour qui s’applique autour de l’élément. J’en parle dans cet article sur comment créer la meilleure palette de couleurs pour un projet web !

C’est un critère d’accessibilité vraiment pratique car il permet d’éviter certaines erreurs de saisie : les aides à la saisie rattachées à un champ de formulaire. Ce sont des indications (souvent un sous-label) qui viennent en complément du label du champ pour apporter plus d’informations sur la donnée attendue par exemple :

• Date de naissance : aide à la saisie : “Au format JJ/MM/AAAA”
Cela aide l’utilisateur à savoir quel format de donnée lui est demandé. Son jour de naissance en 2 chiffres, le mois en 2 chiffres, et l’année en 4 chiffres.

• Code postal : aide à la saisie : “Exemple : 35000”
Cela permet de lever le doute si jamais la personne hésitait entre 35 ou 35000, par exemple.

On reste sur les formulaires une petite minute pour ce grand oublié des maquettes graphiques car c’est important ! L’info doit être claire pour l’utilisateur.

Le cas le plus standard est de marquer les champs obligatoires d’un (souvent rouge, attention au contraste 😉) et il fonctionne de paire avec la mention du style “Tous les champs marqués d’un sont obligatoire” qui doit être positionnée AVANT le bouton de soumission du formulaire. Voilà, maintenant, ce n’est plus la peine d’essayer de le cacher !

Il y a un élément qui est souvent oublié, ou alors travaillé au dernier moment avec un style “erreur” par défaut. Mais ça vaut le coup de travailler les erreurs correctement, car selon le contexte, ils nécessitent plus ou moins d’attention et surout, il y a parfois des opportunités à ne pas manquer. Exemple :

• Les champs de formulaires
On n’affichera pas le même message d’erreur si la personne a oublié un numéro dans un champ numéro de téléphone, ou si son mot de passe n’est pas correct. Il faut lister les variations d’erreur pour les rendre le plus facilement compréhensible possible, car l’option “ce champ contient une erreur”, n’est pas vraiment une option.

• La recherche ne conduit à aucun résultat
On informe l’utilisateur qu’aucun contenu ne correspond à sa recherche. Mais on peut peut-être lui proposer des alternatives, ou des suggestions ?

• Un produit en rupture de stock
L’ajout au panier n’est pas possible, on affiche un message d’erreur pour informer le client. On a aussi l’opportunité de lui proposer de s’inscrire par mail pour être informé de son retour en stock, par exemple !

On peut, selon les projets et les fonctionnalités, trouver des cas où informer l’utilisateur que son action a bien été prise en compte. Par exemple :

• Votre message à bien été envoyé

• La modification a bien été enregistrée

• Votre réservation est bien prise en compte

Ce qui implique qu’il faut non seulement le design des petites alertes contenant le message, mais aussi le wording et le comportement de l’alerte : pop-in, toast ou autre, avec ou sans action, qui s’efface automatiquement ou via un bouton fermer…
C’est un cas qui peut être géré directement en développement, mais le mieux pour garantir un parcours optimisé est de l’anticiper et de le prévoir en maquette.

Si vous avez déjà travaillé avec des personnes en SEO et/ou marketing, vous avez peut-être déjà reçu ce retour sur vos maquettes : il manque le fil d’ariane !

Le fil d’ariane, ce sont ces petits liens en haut de page, souvent séparés par une flèche (>) qui retracent le parcours de l’utilisateur de la home jusqu’à la page en cours.

C’est très pratique en e-commerce ! Imaginez, en arrivant sur la fiche produit d’un site via une recherche “pull tout doux pour l’hiver”,vous pourriez accéder au listing produit de la catégorie “Pulls” pour voir les autres pulls de cette boutique, sans passer par le menu de navigation habituel.

Quand on réalise une maquette, tant qu’à faire, on essaye de “remplir” les écrans avec des données réalistes. Mais quand on s’occupe du design d’un parcours complet (par exemple depuis la toute première inscription de l’utilisateur), on doit anticiper :

Ces états vides ne sont pas des erreurs, ils font partie de l’UX et sont là pour accompagner l’utilisateur dans l’utilisation de son application / site web. Cela permet souvent d’éviter une énniemme étape d’onboarding, puisqu’on invite l’utilisateur à naviguer dans son interface habituelle (et donc de déjà s’approprier la navigation), même encore vide.

Par exemple dans une application de messagerie, on peut imaginer un empty state en attentant qu’une première conversation soit créée. Par exemple avec le wording : “Hey, c’est ici que vous retrouverez vos conversations” > Créer un nouveau message

Les placeholders, eux, sont à anticiper si vous prévoyez des éléments facultatifs à renseigner. Par exemple une image de profil. Ce n’est pas un élément obligatoire mais recommandé, et si la personne ne l’a pas enregistrée, on peut imaginer un classique cercle gris ou des systèmes plus originaux, des illustrations selon le contexte, etc.

Toutes vos maquettes de pages principales sont validées par le client, mais avez-vous pensé à ces petites pages qu’il faut tout de même prévoir ?

Là encore, c’est possible que la personne en charge du développement s’en occupe elle-même. Mais même si ces pages n’ont pas besoin d’avoir un aspect graphique incroyable, mais c’est bien de les prévoir avec la bonne charte graphique, le bon wording et autres infos si besoin.

Généralement on a besoin de :

• La page 404

• Les pages “légales” : Mentions légales, Politique de Confidentialité…

• Le plan du site (nécessaire pour l’accessibilité !)

Vous avez terminé le webdesign de votre nouveau site ou du site de votre client ? Vraiment terminé ? Jusqu’au favicon ?

Le Favicon, c’est la petite image du site que l’on aperçoit dans les onglets du navigateur web. C’est une image de 16x16 px quoi doit tout de même être travaillée pour être reconnaissable et le plus lisible possible. Il s’agit souvent d’une version minimaliste du logo sur fond coloré qui est utilisée.

Petite confession : c’est vraiment l’asset que j’oubliais tout le temps (heureusement, plus maintenant !) ce qui menait à avoir un favicon par défaut ou au mieux un logo en tout petit sur fond blanc si la personne en charge du développement s’est dévouée pour le réaliser.

Il est possible de la créer sur Figma directement et/ou bien d’utiliser des outils tels que favicon Generator qui permet de décliner plusieurs formats, comme app icon, bien utile par exemple pour les Progressive Web Apps qui nécessitent d’enregistrer l’icône sur l’écran d’accueil d’un smartphone.

J’ai préparé un petit template Figma prêt à glisser dans votre projet, avec une checklist et tous ces éléments déjà prêts à cocher. Complétez à votre guise !