Pourquoi les briefs courts produisent des designs génériques
« Fais-moi une belle landing pour mon SaaS. » Voilà le brief moyen envoyé à un AI designer. Le résultat est invariablement le même : hero centré, gradient violet, trois cards features. Pas parce que l'outil est mauvais, mais parce qu'on lui a donné zéro contrainte sur ce qui distingue ce projet des dix mille autres SaaS.
Un LLM en l'absence de contraintes converge vers la moyenne de son entraînement. Plus le brief est court, plus le résultat est moyen. Plus le brief contient de contraintes spécifiques (audience précise, ton, références, exclusions), plus le résultat sort du template par défaut.
La contre-intuition à intégrer : ce n'est pas le talent du modèle qui détermine la qualité du résultat, c'est la richesse du brief. Un designer humain expérimenté pose les questions qui manquent. Un AI designer ne pose rien — il accepte ce qu'on lui donne. Donc il faut donner ce qu'il faut.
Bloc 1 : l'audience, en termes concrets
Première erreur : « pour les startups ». C'est trop large. Trois startups peuvent vouloir trois designs radicalement différents.
Un brief utile sur l'audience nomme : le rôle dans l'entreprise, le secteur, la taille de la boîte, et le contexte d'usage. Exemple : « Head of growth d'une scale-up B2B SaaS entre 50 et 200 personnes, qui évalue des outils d'attribution marketing pendant un sprint quarterly review. Il arrive sur la page après un article de blog spécialisé, il a 4 minutes avant sa prochaine réunion. »
Cette précision change tout. Un head of growth en eval rapide ne lit pas, il scanne. Il veut un hero qui catégorise en 2 secondes, un screenshot produit qui montre l'UI, et un pricing visible sans clic. Si on avait écrit « startup founder », l'outil aurait probablement généré une landing inspirationnelle avec storytelling. Pas la même page.
Bloc 2 : le problème et la promesse, en une phrase
Le bloc problème répond à : qu'est-ce qui fait mal aujourd'hui chez l'utilisateur ? Pas « pas assez efficace », mais « passe 6h par semaine à reformatter manuellement les rapports d'attribution multi-touch parce que les outils existants ne donnent pas le bon niveau de granularité ».
La promesse en miroir : « rapport multi-touch lisible en 2 minutes, granularité ajustable, export Slack et Google Sheets automatique ». On nomme la situation initiale et la situation finale, sans bullshit intermédiaire.
L'avantage de cette précision : le AI designer peut adapter le ton (technique versus marketing-friendly), choisir la preuve visuelle (capture d'écran d'un rapport généré vs vidéo inspirationnelle), et hiérarchiser les bénéfices. Un brief vague sur le problème donne un design vague sur la solution.
Bloc 3 : le ton et les références
Le ton ne se décrit pas avec « moderne » ou « professionnel ». Tout site se prétend moderne et professionnel. Le ton se décrit par des références concrètes et des exclusions.
Références positives : « Linear pour la rigueur de l'UI et la palette froide, Stripe pour le rythme typographique du hero, Vanta pour la sobriété B2B sérieuse ». Trois sites suffisent, choisis dans des registres complémentaires. L'AI designer va extraire les qualités communes (sobriété, hiérarchie typographique forte, palette restreinte) et les appliquer.
Exclusions explicites : « pas de gradient violet, pas d'illustration 3D, pas de hero centré, pas d'Inter ». Les exclusions sont aussi importantes que les inclusions parce qu'elles éliminent les patterns par défaut qui sortent en l'absence d'instructions.
Bonus : un mot ou deux de ton (« sérieux mais pas corporate », « éditorial avec une pointe d'humour », « technique sans jargon ») pour ajuster le registre éditorial.
Bloc 4 : les contraintes structurelles
Le brief doit nommer les contraintes non-négociables. Combien de sections, quel CTA principal, quels assets sont déjà disponibles (logos clients, captures produit, vidéos), quelles intégrations sont nécessaires (formulaire HubSpot, widget Calendly, Stripe Checkout).
Exemple : « 6 sections max : hero, bénéfices, preuve, produit en action, pricing 3 tiers, FAQ. CTA principal = book a demo via Calendly inline. Logo client à inclure : Asana, Notion, Linear (vrais clients). Capture produit dispo en haute def en Figma. Pas de blog, pas de about page sur cette landing. »
Ce niveau de précision permet à l'AI designer de ne pas générer du contenu fantôme (sections inventées, témoignages fictifs, logos faux) et de se concentrer sur la qualité visuelle des éléments réels.
Bloc 5 : les success criteria
Le bloc le plus oublié dans les briefs : à quoi on saura que c'est réussi ? Sans critère de succès, l'évaluation du résultat est subjective, donc les itérations se prolongent à l'infini.
Critères concrets : « le hero doit communiquer la catégorie en moins de 2 secondes pour un non-initié », « un visiteur doit pouvoir trouver le pricing en moins de 5 secondes de scroll », « la page doit charger en moins de 1.5s sur mobile 4G », « le ton doit pouvoir être lu par un CTO sans qu'il lève les yeux au ciel ».
Ces critères jouent deux rôles : ils guident la génération (l'outil optimise pour eux), et ils servent de check-list au reviewer humain pour valider ou demander des révisions. Une landing évaluée contre quatre critères clairs converge en 2-3 itérations. Sans critères, on tourne en rond.
Template de brief à copier-coller
Voici la structure synthétique qu'on utilise et qu'on partage en interne.
Audience : [rôle exact, secteur, taille de boîte, contexte d'usage en 1-2 phrases]
Problème : [situation initiale concrète, mesurable si possible]
Promesse : [situation finale, mesurable, sans buzzword]
Ton : [3 références positives + 3 exclusions explicites + 1-2 mots de registre]
Structure : [nombre de sections, CTA principal, assets disponibles, intégrations]
Success criteria : [3-4 critères mesurables ou évaluables]
En moyenne, remplir ce template prend 20-30 minutes pour quelqu'un qui connaît son produit. Le résultat : un brief qui produit un design exploitable au premier passage, au lieu de 3-5 itérations sur des malentendus.