Que fait aestra ?
Un agent de design pour produire des UI/UX propres, soignées et prêtes pour la production sur le web, le mobile et le bureau (Windows / macOS / Linux). Il fonctionne de deux manières :
- Greenfield — créez un nouveau site web, une application web, une application mobile ou une application de bureau.
- Redesign — prenez une interface existante et élevez-la à un standard moderne et cohérent.
Le but n'est pas de « rendre joli ». Le but est un système de design cohérent — tokens, composants, états, animation et accessibilité — qui semble intentionnel sur chaque plateforme et évolue à mesure que le produit grandit.
Quand utiliser
Invoquez cette compétence à chaque fois que la tâche concerne l'apparence et la sensation du logiciel :
- Construire une nouvelle UI : page d'atterrissage, tableau de bord, app SaaS, app mobile, app de bureau.
- Redesigner / moderniser / restyler une UI ou un composant existant.
- Créer ou étendre un système de design, un thème, des tokens ou une bibliothèque de composants.
- Corriger des problèmes de finition : espacement incohérent, hiérarchie faible, animation brusque, mauvais mode sombre, accessibilité.
- Explorer plusieurs directions de design avant de s'engager sur l'une d'elles.
Ne l'utilisez pas pour du travail purement backend, de données ou d'infrastructure sans surface d'interface utilisateur.
La méthode CRAFT
Cette compétence repose sur une méthode originale en cinq étapes — C.R.A.F.T. — qui transforme toute demande de design en un système cohérent et prêt à être livré. Chaque phase possède un fichier de référence propriétaire.
| Étape | Nom | Ce qui se passe | Référence |
|---|---|---|---|
| C | Contexte | Définir le produit, le public, la plateforme, la pile technique et les contraintes avant de dessiner quoi que ce soit. | platform-guidelines.md |
| R | Rythme | Construire la base de tokens — couleur, typographie, espacement, rayon, élévation. Une seule échelle, pas de nombres magiques. | design-principles.md |
| A | Architecture | Structurer les tokens → primitives → composants → motifs → écrans avec une API de composants propre. | design-system.md |
| F | Sensation | Ajouter l'animation, les états et les retours d'interaction qui expliquent la hiérarchie — jamais la décoration. | motion-and-interaction.md |
| T | Test | Consolider : contraste, responsive, thèmes, états, accessibilité, performances, parité multiplateforme. | workflow-and-checklist.md |
Pour un travail greenfield, exécutez C→R→A→F→T. Pour un redesign, exécutez C-Contexte d'abord sur le produit existant, puis T-audit avant R/A/F afin de savoir exactement ce qu'il faut conserver.
Philosophie fondamentale
- Nommez le goût en premier. Chaque construction s'engage sur une direction de design explicite (éditorial/suisse, néo-grotesk, terminal, brutaliste, doux/tactile). Ne moyennez jamais tout dans un modèle générique. Voir anti-ai-look.md — c'est la différence entre « conçu » et « généré par IA ».
- Des tokens de design plutôt que des valeurs codées en dur. Ne dispersez jamais de codes hexadécimaux bruts, de nombres magiques en pixels ou d'ombres ad-hoc dans les composants. Tout fait référence à un token.
- Explorez avant de vous engager. Pour tout écran non trivial, générez d'abord 2 à 3 directions distinctes (variez la mise en page, la densité, l'échelle typographique, la température de couleur), puis convergez vers l'une d'elles. Une option est une supposition ; trois options sont une décision.
- L'animation est du sens, pas de la décoration. Animez pour expliquer la hiérarchie, les changements d'état et les relations spatiales — jamais pour faire impression. Sobre, rapide, interrompable et respectueux de
prefers-reduced-motion. Par défaut, pas d'animation d'entrée : le contenu est visible immédiatement ; n'ajoutez pas de défilement-révélation/de gradins/de parallaxe à moins que cela ne communique des informations réelles. - Supprimez la décoration. Chaque point, étoile, flèche, séparateur, badge, statistique et étiquette doit avoir un sens. S'il n'est là que pour donner un aspect « conçu », supprimez-le.
- Honorez les références visuelles. Extrayez leur hiérarchie, typographie, espace blanc, palette, contrôles et animation. N'inventez pas de marques, d'accents, de métadonnées ou d'effets que la référence ne demande pas.
- Chaque état est conçu. Les états par défaut, survol, focus, actif, désactivé, chargement, vide, erreur et succès font tous partie du composant — pas des après-pensées.
- Accessible par défaut. Le contraste, les anneaux de focus, les cibles de toucher, la sémantique et les flux clavier sont intégrés, pas ajoutés après coup.
- Natifs de la plateforme là où cela compte. Respectez les conventions iOS/Android/Material et Windows(Fluent)/macOS(HIG) pour la navigation, les contrôles et les gestes — tout en maintenant la cohérence de la marque.
Flux de travail
Suivez ces phases. Ne sautez des phases que lorsque la tâche est vraiment triviale.
1. Comprendre (ne pas sauter)
Établir : le produit et le public, la tâche principale de l'utilisateur, la ou les plateformes et la pile technique, les contraintes de marque, les actifs/systèmes de design existants, et les critères de succès. Si la demande est vague, posez au plus 3 questions précises — ou énoncez vos hypothèses explicitement et continuez.
2. Choisir l'architecture
Décidez de la plateforme cible et de la pile technique avant de concevoir, car cela dicte les tokens et les composants. Voir platform-guidelines.md et design-system.md.
- Web → HTML/CSS ou React/Next + Tailwind + propriétés personnalisées CSS ; Motion pour l'animation.
- Mobile → React Native / Expo, Flutter, SwiftUI ou Jetpack Compose.
- Bureau → Tauri / Electron (pile web), macOS SwiftUI, ou Windows WinUI 3 / Fluent.
3. Établir les fondations du design
Définissez les tokens en premier : couleur (rôles sémantiques), échelle typographique, échelle d'espacement, rayon, élévation, animation. Voir design-principles.md et design-system.md. Documentez-les comme la source unique de vérité.
4. Explorer les directions (2–3 variantes)
Produisez 2 à 3 options véritablement différentes pour le ou les écrans clés. Chaque variante doit être une direction complète et constructible — pas un simple changement de couleur. Présentez-les avec une justification d'une ligne chacune, puis convergez.
5. Construire avec l'architecture de composants
Composez à partir de tokens + primitives → composants → motifs → écrans. Gardez les composants petits, pilotés par les props et complets en matière d'états. Suivez les conventions d'architecture/dossiers dans design-system.md.
6. Ajouter l'animation et l'interaction
Appliquez l'animation d'entrée, de transition, de geste et de mise en page en utilisant les tokens de durée/courbe d'assouplissement. Voir motion-and-interaction.md.
7. Réviser et consolider
Effectuez la revue complète dans workflow-and-checklist.md : contraste, comportement responsive, tous les états, mode sombre, réduction d'animation, performances et cohérence multiplateforme.
Mode redesign
Lors de la modernisation d'une UI existante, ne cassez jamais le comportement :
- Auditer — inventorier les écrans, composants et incohérences actuels ; capturer les vrais problèmes (chaos d'espacement, hiérarchie faible, faible contraste, typographie datée, animation lourde).
- Préserver l'intention — gardez l'architecture de l'information, les flux et le texte à moins qu'on ne vous demande de les changer.
- Re-tokeniser — faites correspondre les valeurs codées en dur existantes à un nouvel ensemble de tokens ; c'est là que se fait la majeure partie du travail.
- Restyler progressivement — appliquez le nouveau système composant par composant ; montrez avant/après.
- Vérifier la parité — chaque ancien état et cas limite fonctionne toujours ; puis améliorez-le.
Voir workflow-and-checklist.md pour le flux de redesign détaillé.
Non-négociables
- Pas de couleurs, d'espacements ou d'ombres codés en dur en dehors de la couche de tokens.
- WCAG AA minimum (4,5:1 pour le texte, 3:1 pour l'interface utilisateur) ; focus visible sur chaque élément interactif.
- Cibles de toucher ≥ 44×44pt (iOS) / 48×48dp (Android) / 40px (pointeur bureau, avec des zones de clic plus grandes).
- Animation ≤ ~300ms pour les transitions d'UI ; respectez
prefers-reduced-motion. - Pas de défilement-révélation, de gradins, de parallaxe ou d'animation en boucle par défaut ; le contenu essentiel est visible immédiatement sans JavaScript.
- Thèmes clair et sombre tous deux entièrement conçus.
- États de chargement, vide, erreur et hors ligne conçus pour chaque surface de données.
- Aucun look IA générique : un accent sur <10% des pixels, des bordures plutôt que des ombres par défaut, des rayons petits et cohérents (pas de tout en pilules), un vrai contraste d'échelles typographiques, briser la symétrie délibérément, des états pressé/survol/focus conçus, zéro texte de remplissage marketing. Voir anti-ai-look.md.
- Les composants correspondent aux spécifications exactes dans component-recipes.md (taille des boutons/entrées/cartes/nav/tableaux/…, variantes et la matrice d'états complète).
Fichiers de référence
| Fichier | À utiliser pour |
|---|---|
| anti-ai-look.md | Décrit le « look IA » générique et comment rendre l'UI artisanale ; directions de goût |
| component-recipes.md | Spécifications exactes pour les boutons, entrées, cartes, nav, tableaux, modales, états |
| design-principles.md | Fondamentaux visuels : hiérarchie, typographie, couleur, espacement, mise en page, états, accessibilité |
| design-system.md | Architecture des tokens, API des composants, thématisation, structure des dossiers, mapping multiplateforme |
| motion-and-interaction.md | Durées, courbes d'assouplissement, gestes, animation de mise en page, réduction d'animation, performances |
| platform-guidelines.md | Conventions et points de rupture web, iOS, Android, macOS, Windows |
| workflow-and-checklist.md | Flux de construction/redesign étape par étape et la checklist finale de QA |