Ce qui se passe vraiment, et dans quel ordre

Un court appel ou un brief écrit, couvrant ce que fait le produit, à qui il s’adresse, ce qui est déjà décidé et à quoi ressemble le « terminé ». La partie la plus utile, ce sont généralement les contraintes : l’échéance qui est réelle, la personne qui doit approuver, la décision technique déjà prise.

Si un projet ne convient pas — le mauvais périmètre, la mauvaise stack, ou un travail qui demande un spécialiste que je ne suis pas — c’est ici que cela se dit. C’est un endroit moins coûteux pour s’en apercevoir que la troisième semaine, et cela arrive assez souvent pour valoir la peine d’être mentionné.

Le brief devient un périmètre écrit : ce qui est inclus, ce qui en est explicitement exclu, les phases, les points de revue, les jalons de paiement et le calendrier. Il est chiffré comme un prix fixe correspondant à ce périmètre, plutôt que comme une estimation horaire.

Les changements de périmètre sont normaux et sont traités comme une modification écrite portant à la fois sur le périmètre et sur le prix. L’autre solution — les absorber en silence et en débattre à la fin — est la façon dont les projets finissent mal pour la partie la moins disposée à avoir cette conversation.

Des parcours et des wireframes en basse fidélité avant de styliser quoi que ce soit. Dessiner chaque écran et chaque point de décision de bout en bout, c’est ce qui fait apparaître les branches que personne n’avait prévues : le paiement échoué, l’invitation expirée, les deux personnes qui modifient le même enregistrement.

Cette étape est délibérément grise et d’aspect inachevé, parce qu’une maquette soignée change la conversation. Montrez un écran fini et les retours porteront sur la couleur du bouton ; montrez un wireframe et les retours porteront sur la question de savoir si cette étape a lieu d’être.

Design en haute fidélité dans Figma, sur une grille, une échelle typographique et un système d’espacement, construit en composants avec des tokens dès le départ plutôt que rangé dans ceux-ci après coup.

Les états sont conçus ici, pas supposés : vide, en chargement, erreur, permission refusée, et la version de chaque écran où le contenu est deux fois plus long que le texte de substitution. La revue a lieu à chaque étape plutôt qu’en une seule fois à la fin, afin que les retours arrivent tant qu’il est encore peu coûteux d’y répondre.

Sur les projets qui se poursuivent jusqu’au code, le design approuvé est construit en front end responsive — React et Next.js, Webflow ou Framer, selon ce que le périmètre a arrêté. Le composant Figma devient le composant codé et le design token devient le token de code, de sorte qu’une décision reste une seule décision.

La performance et l’accessibilité font partie de la construction, et non d’une passe à la fin : rendu statique là où le contenu le permet, images dimensionnées et servies correctement, balisage sémantique, navigation au clavier, focus visible et contraste qui tient. Les rajouter après coup revient à réécrire le balisage.

Une QA multi-navigateurs et multi-appareils par rapport au design, un plan de redirections appliqué là où les URL ont changé, et une remise des fichiers, du code et des comptes — le tout vous appartenant, sans que rien ne dépende de ma présence continue.

La remise est documentée pour que votre équipe puisse maintenir et faire évoluer le site en confiance, avec des composants propres et une structure claire.