designdifferently/design-differently

Design Differently (édition gratuite)

Vous examinez un frontend qui a très probablement été construit avec un agent IA. Votre travail consiste à identifier ce qui le fait ressembler et se sentir comme généré, et à le corriger dans le code. Vous modifiez la présentation, le texte et l'interaction. Vous ne modifiez pas la logique métier, les données, le routage ou le backend.

Sommaire

1. Workflow : étapes 1 à 6
2. Règles : Typographie, Texte, Visuel, Mouvement et effets, Superpositions, Infobulles, Clavier, Composants, Images, Page d'accueil, Suggestions pour le propriétaire, Zones de clic
3. Modèles de détection
4. Pièges
5. Rapport

Degré de suivi de chaque partie :

• Exact : modèles de détection, la question de l'étape 3, le format du rapport et son pied de page. Ne les modifiez pas.
• Strict : les règles. Appliquez-les telles qu'écrites ; n'en sautez une que si elle ne correspond pas au projet, et expliquez pourquoi dans le rapport.
• À votre jugement : choix des polices de remplacement, formulation des corrections légères de texte, quel mouvement conserver.

Copiez cette liste de contrôle dans votre réponse et cochez-la au fur et à mesure :

- [ ] 1. Cartographier le projet
- [ ] 2. Scanner et capturer "avant"
- [ ] 3. Lister les correctifs et laisser l'utilisateur choisir
- [ ] 4. Corriger les éléments choisis
- [ ] 5. Vérifier et capturer "après"
- [ ] 6. Verrouiller les règles dans le dépôt et faire rapport

---

1. Cartographier le projet

Avant de toucher à quoi que ce soit, déterminez :

• Framework et approche de style (Tailwind, CSS Modules, styled-components, CSS pur, une bibliothèque d'UI comme shadcn ou MUI).
• Où vivent les tokens de design (variables CSS, config Tailwind, fichier de thème). S'il n'y en a pas, notez-le.
• Où vivent les composants partagés (Button, Dialog, Tooltip, Dropdown, Badge, Banner). Listez les doublons que vous remarquez.
• Si le projet est une application (outils, tableaux de bord, éditeurs) ou un site (page d'accueil, marketing, blog). Certaines règles ne s'appliquent qu'à l'un d'eux.
• Comment l'exécuter et comment exécuter ses vérifications (lint, typecheck, tests, build).
• Si vous pouvez prendre des captures d'écran ici (Playwright, un outil de navigateur, un volet d'aperçu) et si vous pouvez montrer des images dans ce chat.

Utilisez ce que le projet a déjà et respectez son style de code. N'ajoutez pas de bibliothèques dans cette édition, à l'exception des fichiers de polices.

2. Scanner et capturer "avant"

Exécutez les recherches dans Modèles de détection et lisez les écrans principaux. Si votre environnement ne peut pas exécuter de commandes shell (constructeurs hébergés comme Lovable, v0, Bolt), ouvrez les fichiers et recherchez les mêmes modèles en lisant. Pour chaque résultat, enregistrez le fichier, la ligne et la règle qu'il enfreint. Un résultat est un candidat, pas un verdict : lisez le contexte avant de le compter.

Si vous pouvez prendre des captures d'écran, capturez les écrans principaux maintenant, avant tout changement : la page d'accueil ou d'atterrissage, l'écran d'application le plus chargé, un dialogue, un formulaire. Utilisez 1440×900 et 375×812. Enregistrez-les dans .design-differently/before/ avec des noms comme home-1440.png. Notez la route et l'état exacts de chacun, afin de pouvoir les reproduire plus tard. Ne validez pas ce dossier.

3. Lister les correctifs et laisser l'utilisateur choisir

Ne modifiez aucun fichier avant que cette étape n'ait reçu de réponse.

Présentez les résultats sous forme d'une liste numérotée, regroupée sous des titres de domaine (Typographie, Texte, Visuel, Mouvement, Superpositions, Infobulles, Clavier, Composants, Images, Page d'accueil). Les numéros se succèdent d'un groupe à l'autre. Une ligne par élément : ce qui ne va pas, où, et ce que vous allez changer. Omettre les domaines sans résultat.

### Typographie
1. Inter utilisé comme seule police (app/layout.tsx). Remplacer par un sans-sérif moins courant.
### Texte
2. 14 tirets cadratins dans le texte de la page d'accueil (components/Hero.tsx, Features.tsx). Remplacer par des points, virgules ou deux-points.
3. Ligne de séparation "Rapide · Privé · Open source" dans le hero (components/Hero.tsx). Transformer en une rangée FUD avec des icônes.
4. Les descriptions d'options répètent leurs libellés dans les Paramètres (settings/page.tsx). Supprimer.

Terminez la liste exactement par cette question :

Répondez "all" pour appliquer tous les correctifs, ou listez les numéros que vous voulez (par exemple 1, 3, 5-9).

Arrêtez-vous alors et attendez la réponse.

4. Corriger les éléments choisis

Appliquez uniquement les éléments que l'utilisateur a choisis, un domaine à la fois, dans cet ordre : Composants, Superpositions, Typographie, Visuel, Mouvement, Infobulles, Clavier, Images, Texte, Page d'accueil.

Modifiez d'abord les composants partagés et les tokens, afin qu'une correction répare chaque écran qui les utilise.

Après chaque domaine, exécutez les vérifications du projet (lint, typecheck, tests, build). Si une vérification échoue, corrigez-la avant de passer au domaine suivant. Si la correction nécessite des modifications du backend ou de la logique, annulez cet élément et marquez-le comme ignoré.

5. Vérifier et capturer "après"

Votre premier passage est un brouillon. Vérifiez-le par rapport à des preuves externes, pas de mémoire de ce que vous avez changé :

• Si vous pouvez prendre des captures d'écran, répétez chaque prise de vue "avant" avec la même route, le même état et la même taille, et enregistrez-la dans .design-differently/after/ sous le même nom. Prenez également des captures de tout autre écran que vous avez touché. Regardez chacune. Si quelque chose est coupé, en chevauchement, illisible ou saute, revenez à l'étape 4 pour ce domaine.
• Exécutez à nouveau les modèles de détection. Si un modèle correspond encore en dehors d'une exception autorisée, revenez à l'étape 4.
• Relisez chaque chaîne que vous avez éditée par rapport aux règles de texte. Si l'une d'elles enfreint encore une règle, ou si vous avez modifié plus que ce que la règle exigeait, revenez à l'étape 4.

6. Verrouiller les règles dans le dépôt et faire rapport

Les correctifs doivent survivre au futur vibecoding. Tout agent qui éditera ce projet plus tard doit voir les règles avant d'écrire du code, sinon il ramènera les artefacts.

1. Créez DESIGN_RULES.md à la racine du projet. Rédigez-le pour un agent IA, court et impératif, de moins de 150 lignes. Incluez uniquement ce qui s'applique à ce projet :
   • Les polices choisies, leurs fichiers et où elles sont déclarées, et le chemin de la police du logo (A ou B) si applicable.
   • Où vivent les tokens et la règle selon laquelle les couleurs, rayons, espacements, ombres et tailles de police proviennent uniquement d'eux. Les couleurs primaire, secondaire et optionnelle d'accent par nom de token, et la règle selon laquelle les couleurs destructives et de succès sont uniquement pour ces états.
   • Où vivent les composants partagés (Button, Dialog, Tooltip, Dropdown, Badge, Banner) et la règle de les réutiliser, jamais de les dupliquer.
   • Chaque règle de cette compétence que vous avez appliquée, en une ligne chacune, avec le détail concret de ce projet (par exemple "Infobulles : utiliser components/ui/Tooltip.tsx, 2 ou 3 mots plus raccourci").
   • La liste des interdits : polices, émojis, tirets cadratins, séparateurs décoratifs, guillemets pour emphase, verre sur de grandes surfaces, fondu et flou par défaut, boîtes d'icônes teintées, encarts avec barre d'accent, sourcils en majuscules espacées, points d'état en direct, contrôles et barres de défilement par défaut du navigateur.
   • Une dernière ligne : "Avant de terminer toute modification d'UI, vérifiez-la par rapport à ce fichier."
2. Pointez chaque fichier d'instructions d'agent du projet vers ce fichier. Ajoutez une ligne, Suivez DESIGN_RULES.md pour toute modification d'UI, de texte ou de style., à chacun de ceux-ci qui existe : CLAUDE.md, AGENTS.md, .cursorrules, .cursor/rules/*.mdc, .windsurfrules, .github/copilot-instructions.md, replit.md. Si aucun n'existe, créez AGENTS.md et CLAUDE.md avec cette ligne. Ne modifiez rien d'autre dans ces fichiers.
3. Si DESIGN_RULES.md existe déjà d'une exécution antérieure, mettez-le à jour au lieu d'en créer un nouveau. Conservez les règles que l'utilisateur a ajoutées à la main.

Puis postez le rapport de Rapport comme votre dernier message dans le chat.

Si l'utilisateur corrige l'un de vos correctifs pendant la session, ajoutez une ligne à Pièges dans ce fichier décrivant la correction, afin que la prochaine exécution ne la répète pas.

---

Règles

Typographie

Les outils IA utilisent les mêmes quelques polices, donc ces polices à elles seules font lire un projet comme généré. N'utilisez aucune police de cette liste, dans aucun rôle, à moins qu'elle ne fasse partie d'une charte graphique que l'utilisateur vous a donnée ou que les règles de police de logo ci-dessous ne s'appliquent :

Rôle	Polices interdites
Sans	Inter, Inter Tight, Geist, Roboto, Open Sans, Poppins, Montserrat, Lato, Manrope, DM Sans, Plus Jakarta Sans, Outfit, Figtree, Urbanist, Sora, Lexend, Nunito, Nunito Sans, Raleway, Work Sans, Rubik, Onest, Space Grotesk, Satoshi, General Sans, Cal Sans, Bricolage Grotesque, Syne, IBM Plex Sans, Source Sans 3, Arial, Helvetica en tant que police choisie
Serif	Playfair Display, Instrument Serif, Fraunces, DM Serif Display, Lora, Merriweather, Cormorant Garamond, EB Garamond, Libre Baskerville
Mono	JetBrains Mono, Geist Mono, Fira Code, Fira Mono, Space Mono, Roboto Mono, IBM Plex Mono, Source Code Pro, Ubuntu Mono
Par défaut	Un system-ui nu ou la pile par défaut de Tailwalk utilisée parce que rien n'a été choisi

Police primaire. La police primaire est la police définie dans le logo, ou une police définie par l'utilisateur. Le reste du système typographique en découle.

Police du logo. Si le logo est défini dans une police (un logo texte, un composant wordmark, ou une police nommée dans le CSS ou SVG du logo), cette police reste dans le logo même si elle est sur la liste interdite. Choisissez ensuite l'un des deux chemins et dites lequel dans le rapport :

• A. Suivre le logo. La police du logo devient la police primaire du site et vous devez utiliser exactement cette police.
  • Logo en sérif : utilisez exactement le même sérif pour les titres. Le corps du texte est en sans.
  • Logo en sans : les titres peuvent utiliser un sérif uniquement si le caractère de la marque le justifie clairement, ce qui est un choix risqué. Sinon, les titres restent en sans, idéalement exactement la police du logo ou une très proche.
• B. Logo uniquement. La police du logo reste uniquement dans le logo et vous choisissez les polices pour le reste. La police du logo compte toujours dans la limite de polices ci-dessous.

Les règles de police du logo s'appliquent uniquement à un logo conçu intentionnellement. Si le logo est généré par code (voir Suggestions pour le propriétaire), son texte est simplement la police par défaut, donnez-lui donc votre nouvelle police de titres et ajoutez le logo à la section Pour vous.

Règles d'appariement.

• Une ou deux polices sur tout le site, logo inclus. Jamais plus.
• Jamais deux sérifs.
• Police primaire en sérif : chaque sérif du site est ce même sérif, et le corps du texte est un sans. Deux polices au maximum.
• Police primaire en sans : chaque texte du site utilise ce même sans. Vous ne pouvez ajouter un second sans que comme distinction pour certains titres.
• Les blocs de code, si le produit en a, utilisent la pile monospace du système (ui-monospace, SFMono-Regular, Menlo, monospace), qui ne compte pas comme police choisie.

Choisir les polices. Lorsqu'il n'y a pas de police de logo ni de police de la part de l'utilisateur, choisissez vous-même la police primaire et appliquez les règles d'appariement :

• Lisez d'abord le produit : ce qu'il fait, qui l'utilise, quel ton a le texte. Choisissez un caractère qui correspond à cela, et écrivez une phrase dans le rapport sur pourquoi.
• Évitez le deuxième choix évident. Si une police est la première à laquelle vous pensez pour ce type de produit, elle est probablement en route vers la liste interdite. Choisissez une face moins courante avec le même travail.
• La licence doit permettre une utilisation commerciale gratuite sur le web (SIL Open Font License ou similaire). Sources : Google Fonts au-delà des premiers résultats, Fontshare, Velvetyne, Collletttivo, The League of Moveable Type, familles gratuites des fonderies.

Pour chaque police du site :

• Au maximum trois graisses par famille.
• Les polices vivent dans le dépôt. Téléchargez les fichiers woff2 dans le projet (par exemple public/fonts/) et chargez-les avec @font-face, next/font/local ou des paquets @fontsource/* regroupés au moment de la construction. Ne chargez jamais les polices à l'exécution depuis Google Fonts, Adobe Fonts, Bunny ou tout autre hébergeur externe, car chaque vue de page envoie alors les données du visiteur à cet hébergeur. Supprimez tous les liens fonts.googleapis.com, fonts.gstatic.com, use.typekit.net, les @import et les imports next/font/google, y compris pour les polices que vous conservez. Utilisez font-display: swap.
• Conservez une pile de remplacement sensée après le visage choisi.
• Définissez les polices à un seul endroit (tokens, fontFamily de Tailwind, CSS racine) et supprimez toute autre déclaration de police.

Texte

Éditez le texte avec une main légère. Ne réécrivez pas les textes, ne changez pas leur sens, ton ou longueur, et n'ajoutez pas de nouvelles phrases. Supprimez les marques d'IA listées ci-dessous et lissez la syntaxe uniquement là où la suppression la laisse cassée. Si une phrase se lit correctement une fois la marque supprimée, arrêtez-vous là.

Ce qu'il faut supprimer :

• Tirets cadratins et tirets en espaces (—, –). Remplacez par un point, une virgule ou deux-points, selon ce qui garde la phrase la plus proche de l'original.
• Guillemets utilisés pour l'emphase, l'ironie ou la paraphrase. Supprimez-les et gardez les mots. Les guillemets ne restent qu'autour d'une citation exacte, mot pour mot.
• Séparateurs décoratifs comme ·, •, | ou / utilisés pour enchaîner des expressions. Supprimez-les complètement. Ne les remplacez jamais par des points ou d'autres ponctuations. Ce qui arrive aux expressions dépend de l'endroit où elles se trouvent :
  • Hero, cartes de prix, lignes de vente clés : transformez les expressions en un rangée FUD, une rangée horizontale d'éléments courts, chacun avec une petite icône avant son libellé. Utilisez le jeu d'icônes du projet, ou un SVG en ligne s'il n'en a pas. Une taille et une couleur unie pour toutes les icônes, pas de boîte d'arrière-plan derrière elles (voir règles Visuelles). La rangée s'enroule proprement sur mobile.
  • Paragraphes secondaires, texte d'aide, légendes, pieds de page : supprimez les séparateurs. Ne conservez les expressions que si elles se lisent encore comme du texte brut sans eux ; sinon, gardez l'expression la plus importante et supprimez le reste.
• Constructions "Pas seulement X, mais Y" et leurs parentes : "Ce n'est pas X, c'est Y", "Plus que X", "X, sans le Y". Gardez la moitié positive.
• Descriptions qui répètent le libellé, et descriptions sous des options qui n'en ont pas besoin. Supprimez-les.
• Descriptions commerciales ou suggestives sur l'UI fonctionnel. Rendez-les courtes et neutres, comme dans macOS ou Photoshop : dites ce que c'est ou ce que ça fait.

Exemples :

Avant	Après
Conçu pour les équipes — pas seulement pour les individus.	Conçu pour les équipes.
Hero : Rapide · Privé · Open source	Rangée FUD de trois éléments : icône d'éclair + Rapide, icône de cadenas + Privé, icône de code + Open source. Icônes SVG du jeu du projet, jamais d'émojis
Aide : Mis à jour quotidiennement · Lecture de 2 min	Mis à jour quotidiennement
Votre "deuxième cerveau" pour les notes	Votre deuxième cerveau pour les notes
Ce n'est pas une application de tâches, c'est un système.	Un système pour vos tâches.
Mode sombre — Passez à un thème plus sombre qui est plus doux pour vos yeux la nuit.	Mode sombre sans description
Sauvegarde automatique : ne perdez plus jamais votre travail avec une sauvegarde automatique transparente !	Sauvegarde automatique : enregistre les modifications au fur et à mesure que vous tapez.

Visuel

Couleur des tokens. Toutes les couleurs de l'UI proviennent des tokens du projet (variables CSS, config Tailwind, objet theme). Les couleurs hexadécimales brutes, les valeurs rgb ou hsl en ligne ne sont autorisées que dans les images et les blobs de fond décoratifs non interactifs. Si vous en trouvez ailleurs, remplacez-les par un token de couleur sémantique existant, ou ajoutez un nouveau token si aucun token existant ne correspond à l'intention (par exemple, si le projet a une couleur d'accent violette non définie).

Boîtes d'icônes teintées. Les icônes ne se trouvent jamais dans des boîtes à fond coloré rondes ou à coins arrondis. Les icônes sont placées sur l'arrière-plan de la page ou de la carte, à une taille cohérente avec le texte environnant. Si une boîte sert à rendre une icône cliquable, l'icône est le bouton et la boîte disparaît.

Verre. L'effet de verre (fond flouté, arrière-plan semi-transparent, surbrillance de bordure) n'est jamais utilisé sur de grandes surfaces : pas de barres de navigation entières, de panneaux latéraux entiers, de sections de page d'accueil entières, ni de cartes pleine largeur. Le verre est limité aux surbrillances de survol sur les boutons, au brouillon d'un élément glissé, aux petites info-bulles et aux menus déroulants (pas plus larges que le bouton qui les déclenche).

Encarts avec barre d'accent. Les encarts avec une barre colorée sur le côté gauche ne contiennent pas une citation ni un extrait de code. Supprimez la barre et intégrez le texte à la mise en page normale.

Bordures et séparateurs. Utilisez les bordures avec parcimonie. Aucune bordure autour de cartes, de champs de formulaire, de lignes de tableau ou d'éléments de navigation, sauf si cela est nécessaire pour l'accessibilité, la compréhensibilité ou le focus. Utilisez l'espacement, le remplissage et la couleur de fond pour séparer les zones. Si un composant a besoin d'une bordure, elle vient des tokens (rayon, épaisseur, couleur).

Surbrillance de survol. Tous les éléments interactifs…

[Suite du texte tronquée pour la traduction]