Après ma formation de développeur, je pensais avoir toutes les clés pour créer une bonne interface. Puis j’ai suivi une formation en UI Design. Je n’y ai pas appris à faire des interfaces plus jolies, mais à me poser les bonnes questions avant même de commencer à coder.
Le déclic
Comme je le racontais dans un article précédent, je suis sorti de formation dev en pleine période creuse côté embauche. Pas un seul contrat de junior à l’horizon. J’ai pris ce temps mort pour une formation complémentaire en UI Design, un peu par élimination au départ — autant faire quelque chose plutôt que d’enchaîner les candidatures dans le vide. Je pensais que ce serait la suite logique de mon parcours : coder une interface et la concevoir, ça devait être la même compétence, juste vue sous un autre angle.
Ça ne l’était pas. Personne ne m’a parlé de palettes de couleurs ou de typographie pendant cette formation. On m’a parlé de standards, d’accessibilité, de la façon dont une page est structurée avant même qu’on pense à son apparence. Sur le moment, je crois que ça m’a un peu déçu — je m’attendais à autre chose.
Avant, je codais et l’accessibilité suivait, ou pas
En sortie de formation dev, une interface se construisait dans un ordre assez simple : un besoin, un composant, du code qui tourne. Le focus au clavier, les contrastes, la taille des zones cliquables, ça n’était pas des sujets que j’ignorais complètement, mais des trucs qu’on regarde à la fin, si on a le temps. Et honnêtement, on n’a jamais vraiment le temps à la fin d’un projet.
Ce qui a changé, très concrètement
Il y a un exemple qui revient souvent chez moi maintenant : la taille des zones tactiles. Un bouton qui a l’air très bien dimensionné sur l’écran d’un designer peut devenir un calvaire à toucher du doigt une fois sur mobile. Les recommandations d’accessibilité encouragent des zones tactiles suffisamment grandes — souvent autour de 44 × 44 px — pour qu’elles restent faciles à utiliser. Avant, je voyais ça comme une contrainte esthétique un peu embêtante. Maintenant je la traite comme une contrainte de conception, au même titre qu’une contrainte technique.
Le focus visible, aussi. Avant la formation, l’outline bleu moche par défaut
du navigateur, je le voyais presque comme un bug visuel à corriger en CSS.
outline: none et on n’en parle plus. Sauf que le supprimer sans le
remplacer par autre chose, c’est rendre le site inutilisable au clavier pour
une partie des gens qui le visitent. Le focus doit rester visible, cohérent
avec l’interface, et accompagner naturellement la navigation au clavier.
Et puis les contrastes. Un texte gris clair sur fond blanc, ça peut être
illisible pour une personne malvoyante — et franchement, pour n’importe qui
en plein soleil avec son téléphone. Pareil pour une icône sans texte à côté :
sans un attribut aria-label bien pensé, un bouton « fermer » représenté par
une simple croix ne dit rien à une personne aveugle qui utilise un lecteur
d’écran.
On ne coche jamais toutes les cases, de toute façon. L’accessibilité couvre des besoins trop différents — visuel, moteur, auditif, cognitif — pour qu’on prétende avoir tout couvert un jour. Ce qu’on peut faire, c’est essayer de bien faire les choses dès le départ plutôt qu’en rattrapage : penser le contraste avant de choisir une couleur, penser le clavier avant de coder un menu, penser le texte alternatif au moment où on ajoute l’icône, pas trois semaines plus tard en relecture.
Ça se voit dans mon quotidien de code, maintenant. Le premier réflexe sur un nouveau composant n’est plus seulement esthétique — la navigation au clavier, le focus, les contrastes, la taille des zones tactiles, tout ça arrive en même temps que le reste, pas après.
Ce qui n’a pas changé
Cette formation ne m’a pas transformé en designer, et je ne prétends pas l’être. Ce qu’elle a déplacé, c’est le moment où je me pose ces questions dans un projet — avant d’écrire le code, plutôt qu’en le relisant. Il faut toujours un développeur pour transformer une intention de design en interface qui fonctionne réellement dans un navigateur, et il faut toujours un designer pour que cette interface serve l’utilisateur et pas seulement la faisabilité technique. Les deux métiers restent bien distincts.
Mais je ne regarde plus une interface comme un tas de composants à assembler. Je la vois comme un parcours que quelqu’un va devoir suivre, parfois au clavier, parfois du doigt, parfois avec un lecteur d’écran. Mon code n’a pas fondamentalement changé. C’est le regard que je pose dessus, en l’écrivant, qui a bougé.