La vitesse vient de ce qu'on retire,pas de ce qu'on précipite.
philosophie design_
Ma façon de travailler n'a qu'un objectif : le moins d'étapes possible entre un problème et une décision. J'esquisse avant de prototyper, je fais de la recherche avant de wireframer, j'écris avant de peaufiner. Chaque étape doit mériter sa place, et tout ce qui ne fait pas avancer le produit saute.
Les outils, le rythme et les principes derrière ma façon de travailler
Passez la souris sur un outil pour voir quand et comment je l'utilise.
Figma · FigJam · Make
DESIGN + SYSTEMSVS Code
FRONT-END + CODEClaude + MCPs
CORE WORKFLOWMaze
RESEARCH + TESTINGNotion
DOCUMENTATIONGit / Vercel
DEPLOY + REVIEWLe reste de ma stack
rythme de sprint_
Une semaine dans mon flux de travail
Chaque projet ne suit pas ce rythme à la lettre, mais la cadence tient.
Aligner & planifier
Réviser les objectifs du sprint, relire les notes de recherche de la semaine précédente, synchroniser avec l'équipe. Écrire un brief approximatif avant de toucher à un fichier de design. Faire remonter les risques tôt, avant qu'ils ne coûtent un sprint.
Concept & structure
Croquis d'architecture de l'information et premiers flows. Parfois générer un aperçu HTML pour s'aligner avec l'ingénierie avant d'ouvrir Figma. Permet de valider le modèle d'interaction en premier.
Design & travail système
Sessions Figma approfondies. Audits de tokens, états des composants, cohérence des patterns. Si quelque chose ne s'intègre pas au système, je corrige le système avant de livrer l'exception.
Prototyper & valider
Construire des prototypes interactifs, tester avec de vrais utilisateurs ou des parties prenantes internes. Déployer sur Vercel pour une revue asynchrone. Pas besoin de réunion pour obtenir du feedback.
Livraison & documentation
Rédiger les spécifications de livraison aux développeurs. Documenter les décisions, pas seulement les résultats. Capturer ce qui a changé et pourquoi pour que le prochain sprint commence avec du contexte, pas de la confusion.
principes_
Ma façon de penser le travail
Ce à quoi je me range par défaut, et ce sur quoi je ne transige jamais.
Cadrer ce qui est exclu, pas seulement ce qui est inclus
Un brief de sprint qui ne liste que ce qui va être construit invite au scope creep. J'écris ce qu'on ne touche explicitement pas ce cycle, et pourquoi.
Déployer avant de présenter
Un retour sur un fichier Figma, c'est un retour sur un fichier Figma. Je pousse sur une preview live avant de montrer quoi que ce soit, pour que la réaction porte sur la vraie chose.
Une décision, un seul endroit
Si une décision n'existe que dans un fil Slack ou dans la mémoire de quelqu'un, elle n'a pas eu lieu. Chaque décision est écrite là où la prochaine personne qui construit dessus ira vraiment la chercher.
Asynchrone par défaut, réunion par exception
Les reviews se font sur un lien déployé avec des commentaires écrits. Une réunion live est réservée à ce qui a vraiment besoin d'une conversation, pas à un point de statut.
Chaque exception est tracée, pas juste rafistolée
Quand un écran doit casser le système, ce n'est pas un à-côté silencieux. C'est un ticket, pour que le système l'absorbe au cycle suivant ou que l'exception reste visible.
L'IA gère la recherche et la doc, jamais le design lui-même
Claude et les MCPs accélèrent la synthèse, les notes et les specs - la partie qui relève des mots, pas des pixels. Chaque interface, chaque flow, chaque décision visuelle reste la mienne, du début à la fin.
La rétro a lieu même quand rien n'a cassé
Un sprint propre a quand même droit à quinze minutes de ce que je ferais différemment. Les retours d'expérience ne sont pas réservés aux incendies.