Construction de page de conversion
Rien n'est écrit avant qu'un Conversion Brief n'existe. Cherchez
03 Projets/<Projet>/_Recherche/[C] Conversion Brief — *.md — ou le dossier de recherche de votre projet si
vous ne l'exécutez pas dans cette configuration. Si aucun n'existe, arrêtez-vous et invoquez audience-research
plutôt que de deviner l'ICP, les objections classées ou le registre. Une page construite sur une audience
devinée n'est pas une version moins chère de cette compétence — c'est une compétence différente et peu fiable qui porte
la structure de celle-ci, et la section Register du brief est la seule entrée que rien en aval ne peut
récupérer si elle est erronée (../audience-research/SKILL.md — le registre, une fois défini, est hérité, pas
redécidé).
La procédure : deux passes d'écriture, puis un spec
Chaque section ci-dessous est écrite en deux passes, dans cet ordre, et la seconde ne fuit jamais dans la première. Un troisième résultat — le spec de section, couvert plus loin dans ce fichier — suit une fois le texte terminé :
- Décidez ce que la section doit accomplir, en utilisant la couche de framework — les leviers de l'Équation de Valeur, l'obstacle inversé en solution, l'objection mappée à l'objection cachée mappée au changement de croyance mappé à la preuve, la valeur empilée et ancrée par rapport au prix. Cette couche est structurelle. Un acheteur industriel allemand et un acheteur direct-response en libre-service ont besoin que la même chose soit prouvée dans la section Mécanisme — que cela fonctionne, spécifiquement, pour quelqu'un dans leur situation — même si rien dans la façon dont cette preuve est exprimée ne se ressemblera deux fois.
- Écrivez-la dans le registre spécifié par le brief. Le registre décide de l'intensité des affirmations, de ce qui compte comme preuve, si l'urgence est utilisable ou non, et à quel point la page demande directement — ce n'est pas un passage de ton appliqué après que le texte soit autrement terminé. Récupérez le registre nommé dans la section Register du brief et maintenez-le sur l'ensemble des onze sections sans le redécider en cours de page.
Sautez l'étape 1 et vous obtenez un texte fluide qui argumente la mauvaise chose à la bonne personne. Sautez l'étape 2 et vous obtenez un argument précis que personne dans ce registre ne finira de lire. Fusionnez-les en une seule passe et le résultat est un générateur de texte portant le nom de cette compétence — l'échec que cette compétence existe pour empêcher.
- Produisez le spec de section, une fois le texte de cette section écrit — voir
## Le spec de sectionci-dessous. Une exécution qui s'arrête après les étapes 1 et 2 a du texte mais aucun artefact de transfert ; le spec n'est pas une paperasse facultative, c'est le troisième résultat de cette compétence.
Les onze sections
Hero, Problème, Résultat, Solution, Mécanisme, Stack de Valeur, Preuve, Objections, Garantie, CTA, FAQ —
dans cet ordre, pour une page qui déroule l'argument complet. references/page-architecture.md contient cet ordre
et la raison pour laquelle il est cet ordre et pas un autre. references/section-playbooks.md contient ce que
chaque section doit accomplir et comment cela change selon les cinq registres — lisez la ligne Register du brief
une fois, puis lisez uniquement cette colonne pour chaque section, pas les cinq.
Toutes les pages n'ont pas besoin des onze sections, ou dans cette séquence — references/page-types.md couvre ce que
une page d'accueil, une page d'opt-in, une page de tarification, une page de fonctionnalité et une page de vente complète chacune gardent,
compressent ou suppriment, et pourquoi le travail que cette page fait dans l'entonnoir est ce qui le décide.
Deux sections portent suffisamment de leur propre raisonnement pour nécessiter un fichier dédié plutôt qu'une colonne de playbook :
- Objections —
references/objection-to-belief.mdparcourt objection de surface → objection cachée → changement de croyance → preuve, construite à partir de la section Objections classées du brief plutôt qu'une liste FAQ générique assemblée après que le texte soit déjà écrit. - Preuve —
references/proof-library.mdclasse les types de preuve par force et par ce que chacun coûte réellement à obtenir, de sorte que la section soit construite à partir de ce que le client peut produire cette semaine, pas de ce qu'il serait agréable d'avoir.
references/conversion-psychology.md est la couche de modèle mental sur laquelle le raisonnement du framework dans chaque section
s'appuie. Lisez-le une fois par projet, pas une fois par section — il explique pourquoi un levier fonctionne,
pas quoi écrire.
Le spec de section
Produisez un spec de section par section, en parallèle du texte, dans cette forme exacte — design-handoff
le consomme via ces cinq noms de clés et aucun autre :
section_type: <un des onze>
purpose: <ce que cette section doit accomplir, de la passe de framework>
content_hierarchy: <ce qu'un lecteur voit en premier, deuxième, troisième dans la section>
components: <les éléments concrets — titre, sous-titre, emplacement média, formulaire, tableau comparatif, badge…>
responsive_intent: <ce qui s'empile, se replie, se réordonne ou se cache en premier sur un viewport étroit>
Écrivez le spec après le texte, pas avant. Il décrit ce que le texte doit réellement contenir, et un spec écrit en premier a tendance à verrouiller une mise en page à laquelle le texte est ensuite plié plutôt que l'inverse.
Avant de livrer
Si une compétence humanizer est disponible dans cet environnement, faites passer le texte fini par celle-ci avant
de considérer la page terminée. Si elle n'est pas installée — une nouvelle installation de ce plugin n'a pas de coffre et pas
de humanizer — appliquez ../copy-sweeps/references/banned-vocabulary.md au brouillon directement à la place.
L'une des deux s'exécute toujours ; laquelle dépend de ce qui est installé, pas de l'importance de l'une ou l'autre étape.
Où va la page
Par convention dans ce coffre, le texte de page terminé atterrit à côté du brief à partir duquel il a été construit —
03 Projets/<Projet>/_Recherche/[C] Texte de Page — <Page> — <date>.md — ou là où votre projet
conserve les textes rédigés si vous n'exécutez pas cela dans cette configuration. Cette compétence produit deux choses :
le texte lui-même, et le spec de section par section que design-handoff consomme. Dites où vous avez
classé le texte ; une page que personne ne peut trouver n'est pas une page livrée.