Sur cette page
Pendant des années, notre passation tenait en un fichier et un espoir. Le design se terminait, un lien partait vers le développeur, et trois semaines plus tard nous découvrions lesquelles de nos décisions avaient survécu. La plupart, en général, mais jamais celles qui comptaient le plus pour nous.
Aujourd’hui, notre développeur assiste à la première revue de croquis de chaque projet web. Pas pour valider le design, mais pour poser les questions qui, sinon, arriveraient trop tard. Voici ce qui a changé chez Fernlow, entre nos bureaux de Rotterdam et de Montréal, et ce que nous transmettons désormais.
Poser les questions qui fâchent dès le croquis
Un croquis est l’endroit le moins cher pour découvrir qu’une mise en page dépend d’un texte qui ne sera jamais aussi court, ou d’une photo que le client n’a pas. Les développeurs repèrent vite ces pièges, parce qu’ils voient une page comme un contenu qui coule dans une structure, pas comme une image.
La mise en page la moins chère à corriger, c’est un croquis qu’un développeur a déjà remis en question.
Notre règle est simple : aucun écran ne passe en haute fidélité avant qu’un développeur l’ait vu sous forme de dessin au crayon ou de maquette grise, et ait dit ce qui l’inquiète.
Dessiner des états, pas des écrans
Une page d’accueil n’est pas une image. C’est un ensemble d’états : vide, en chargement, pleine, trop pleine, en erreur. Nous dessinons le nom de produit trop long, la photo manquante, l’erreur après l’envoi d’un formulaire, et la page en français, environ un cinquième plus longue que l’anglaise. Nos clients montréalais publient dans les deux langues, et un bouton calibré pour « Book » casse le jour où il doit afficher « Réserver ».
Nommer les choses une seule fois
Couleurs, pas d’espacement, tailles de texte et rayons d’angle reçoivent un nom dans une liste partagée avant que la moindre page soit dessinée. Les mêmes noms se retrouvent dans le fichier de design et dans le code. Quand un client veut des titres « un peu plus petits », nous changeons une valeur, sous un seul nom, et toutes les pages suivent.
Pour le site de Ravel & Hue, les 96 couleurs du nuancier tenaient dans un seul fichier de données. Notre développeur a proposé de générer chaque page de teinte à partir de ce fichier plutôt que de les mettre en page une à une. Le développement a gagné une semaine, et le nuancier, les emballages et le site ne pouvaient plus jamais diverger.
Transmettre un système, pas des images
Notre passation, c’est un document court et un prototype qui fonctionne, jamais un dossier d’images à plat. La liste que nous joignons à chaque site :
- la liste nommée des couleurs, espacements, tailles de texte et rayons, avec leurs valeurs
- chaque composant dans tous ses états, y compris vide et en erreur
- le texte réel le plus long pour chaque titre, bouton et entrée de menu, dans chaque langue
- des notes d’animation en mots simples : ce qui bouge, de combien, pendant combien de temps, et ce qui se passe quand les animations sont réduites
- les images dans leur cadrage final, avec un texte alternatif rédigé par nous, pas laissé pour plus tard
- la liste des questions ouvertes, chacune avec un nom en face
Relire le site, pas le fichier
La revue de design se fait dans le navigateur, sur de vrais appareils, aux vraies tailles. Nous vérifions sur un grand écran, un petit portable et un téléphone tenu d’une main. Chaque problème est consigné avec une capture, l’appareil et une courte note sur ce que nous attendions. « Ça ne va pas » n’est pas un problème ; « le titre passe sur quatre lignes à 375 pixels » en est un.
Ce que ça coûte, et ce que ça épargne
Faire entrer un développeur tôt ajoute quelques heures aux deux premières semaines. Cela retire la plupart des surprises des deux dernières, là où elles coûtent cher et où la patience s’use vite. Après neuf ans et plus de 260 projets, c’est le changement que nous ferions en premier si nous devions refonder le studio.
