Du design qui vajusqu'en production.
philosophie design_
Mon flux de travail a un seul objectif : moins d'étapes entre un problème et une décision. J'esquisse avant de prototyper, je recherche avant de wireframer, et j'écris avant de peaufiner. La vitesse vient de la suppression du superflu, pas de la précipitation sur l'essentiel.
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 ressemble pas à ça, mais la plupart devraient
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
Mes lignes directrices et mes non-négociables
La recherche avant les pixels
Parler aux utilisateurs avant d'ouvrir Figma. Une mauvaise hypothèse coûte un sprint. Un bon entretien coûte une heure.
Maîtriser la livraison
Un design qui casse en développement n'était jamais terminé. Je reste proche du build, j'écris des specs que les équipes utilisent, et je traite l'écart entre Figma et la production comme mon problème.
Corriger le système, pas l'instance
Quand quelque chose ne s'intègre pas à la structure de tokens, je corrige la structure. Livrer des exceptions accumule la dette plus vite que livrer en retard.
Écrire avant de wireframer
Les mots clarifient la pensée plus vite que les formes. Je rédige les textes, les libellés et les états d'erreur avant de toucher à la mise en page.
Les défauts sont des engagements
La plupart des utilisateurs ne changent jamais les paramètres. Ce qui est livré en premier devient permanent pour eux. Choisir les valeurs par défaut comme si on le voulait vraiment.
L'IA en soutien, pas aux commandes
Claude et les MCPs accélèrent l'exploration et la documentation. Chaque décision finale est la mienne. Tout comme la responsabilité de ce qui est livré.
Ralentir au début
La façon la plus rapide de concevoir la mauvaise chose est de sauter la phase d'écoute. Je passe plus de temps en recherche que la plupart. Cela réduit l'espace des mauvaises décisions avant que les pixels ne bougent.