Ce avec quoi je conçois et développe
Les outils derrière le travail, et la raison pour laquelle chacun est toujours là. Rien dans cette liste n’est une recommandation pour qui que ce soit d’autre. C’est ce qui se trouve convenir à ma façon de travailler entre un fichier Figma et un front end déployé.
Design
Figma fait le plus gros du travail. Les autres sont là parce qu’un client ou un projet y vit déjà.
- Figma
- Là où commence et se termine pratiquement chaque projet. Les composants, les variantes et l’auto layout correspondent d’assez près à la façon dont un front end est réellement construit pour que le fichier reste utile après le handoff, au lieu de devenir une image du design.
- Framer
- Pour les sites où le design et la page publiée doivent être le même artefact, et pour les animations qu’il est plus facile de démontrer que de décrire dans une spécification.
- Webflow
- Quand un client doit ensuite modifier et publier du contenu lui-même, sans développeur dans la boucle. Choisi en fonction de qui maintient le site, pas de la façon dont il est construit.
- Sketch
- Uniquement quand un projet arrive dans cet outil. Beaucoup de produits de longue date ont encore leur source de vérité dans une bibliothèque Sketch, et en convertir une vaut rarement la perturbation que cela occasionne.
Front end
De quoi mener un design jusqu’en production, et savoir pendant la conception quelles idées sont peu coûteuses et lesquelles sont chères.
- React
- Le modèle de composants s’aligne sur la façon dont un design system est structuré, si bien que le composant Figma et le composant codé restent la même unité, plutôt que deux inventaires parallèles.
- Next.js
- App Router et server components par défaut. La plupart de ce que je construis est piloté par le contenu et devrait être livré en HTML statique, ce site compris.
- Tailwind CSS
- Les design tokens comme seule manière d’écrire une valeur. Cela rend visible en revue un choix d’espacement ou de couleur hors système, une contrainte qui vaut plus que la rapidité.
- TypeScript
- Surtout pour la couche de contenu. Typer la forme d’une étude de cas ou d’un service fait qu’un champ manquant devient une erreur de build, plutôt qu’un espace vide que quelqu’un remarque en production.
- HTML & CSS
- Reste la partie qui décide si une réalisation est bonne. La sémantique, l’ordre de focus et le contraste sont des décisions de design qui se trouvent être écrites dans le balisage.
- PHP
- Pour des projets sur des stacks PHP existants, généralement un front end qui doit s’insérer dans quelque chose déjà en service, plutôt qu’une réalisation partie de zéro.
Ce site
Puisqu’un portfolio devrait pouvoir répondre à la question qu’il invite à poser.
- GSAP
- ScrollTrigger et SplitText pour les apparitions des titres et les séquences pilotées par le défilement. Chaque primitive de mouvement vérifie prefers-reduced-motion et se dégrade en une mise en page statique et entièrement visible.
- Lenis
- Défilement fluide, piloté par le ticker de GSAP plutôt que par sa propre frame d’animation. Sur une boucle séparée, les éléments épinglés et en parallaxe accusent une frame de retard sur la position de défilement.
- three.js
- Le fond de particules, limité à un seul draw call. Un portfolio qui coûte sa batterie à un téléphone rien qu’à le regarder a fait le mauvais compromis.
Envie de voir comment tout cela s’utilise sur un vrai projet ?
Voir toutes les études de cas