Transfert design
La copie est approuvée. Ce dont un designer ou un générateur de wireframes a besoin, ce ne sont pas les mots — c'est ce que chaque bloc de mots doit faire au lecteur, dans quel ordre, et lesquels de ces éléments doivent survivre sur un téléphone. Cette compétence transforme l'un en l'autre, et ne décide rien que la copie n'ait déjà décidé.
La porte d'entrée : une copie approuvée, et un spec de section par section
Deux entrées. La seconde est celle qui manque souvent.
Copie approuvée, pas un brouillon. Une mise en page construite autour d'un paragraphe encore en discussion sera reconstruite, et la reconstruction est toujours pire, car il s'agit alors d'un rafistolage sur une forme choisie pour des mots différents. Si la copie est encore en mouvement, arrêtez-vous et dites-le.
Un spec de section par section. ../conversion-page-build/SKILL.md en produit un en même temps que la copie, sous son en-tête ## Le spec de section, et cette compétence le lit par cinq noms de clés et aucun autre : section_type, purpose, content_hierarchy, components, responsive_intent. Ce fichier possède la forme du spec et la raison pour laquelle il est écrit après la copie plutôt qu'avant.
Une copie qui arrive sans specs peut encore être transmise — rédigez d'abord les specs à partir de la copie, et marquez-les comme inférés dans la sortie. Un spec rétro-conçu à partir d'une copie finalisée enregistre ce que la copie semble faire, ce qui n'est pas la même chose que ce pour quoi elle a été construite. Là où les deux diffèrent, un designer mettra en page fidèlement la mauvaise intention, et rien en aval ne la rattrapera.
Le séquencement
Quatre étapes. Les trois premières sont toujours exécutées. La quatrième ne l'est généralement pas.
- Mapper chaque spec de section aux composants —
references/section-to-component.md. Transforme les cinq clés en une liste de composants par section, plus la seule chose à propos de cette section qui contraint une mise en page. - Rédiger le brief du wireframe —
references/relume-brief.md. Cadrage au niveau de la page, puis un bloc par section : structure et fonction du contenu, sans apparence. - Rédiger le spec de raffinement —
references/figma-refinement-spec.md. Hiérarchie visuelle, accent, priorité au-dessus de la ligne de flottaison et chemin de lecture : les quatre choses que le wireframe ne tranche pas. - Notes de plateforme, conditionnellement — voir ci-dessous.
Les étapes 2 et 3 restent intentionnellement des documents séparés, et dans cet ordre. La raison est énoncée dans l'ouverture de references/figma-refinement-spec.md et n'est pas répétée ici.
Le passage plateforme ne s'exécute que lorsque la plateforme a été nommée
N'ouvrez pas references/platform-notes-wordpress.md sauf si la cible de construction a été nommée et qu'il s'agit de WordPress. Une construction Webflow, une construction Framer, une construction codée à la main et une construction sans nom ne chargent rien ici.
Ce n'est pas une question de rangement. Une note de plateforme décrit une contrainte qui est réelle sur une plateforme et fausse sur une autre, donc un spec portant une contrainte qui ne s'applique pas fait résoudre au designer un problème qui n'existe pas — puis défendre la solution quand quelqu'un la remet en question. De mauvaises notes coûtent plus cher que pas de notes du tout.
Si la cible n'a pas été nommée, demandez. Si la réponse est « pas encore décidé », rédigez le transfert sans plateforme et enregistrez dans la sortie que le passage plateforme n'a pas été exécuté, afin que quiconque reprenne la construction sache qu'une vérification est en attente plutôt que de supposer qu'elle a été effectuée.
Chaque fichier plateforme a la même forme et rien d'autre : une note par comportement, chacune indiquant trois choses — le comportement de la plateforme, l'échec que ce comportement provoque, et le wording qui l'évite. Une plateforme sans fichier dans cette compétence ne reçoit aucune note ; jamais les notes WordPress par défaut, ce qui est l'erreur spécifique que le conditionnel existe pour empêcher.
Les noms des outils sont sur les portes, pas dans la méthode
Deux fichiers de référence sont nommés d'après des outils — references/relume-brief.md et references/figma-refinement-spec.md — parce que ce sont les noms que les gens demandent. Rien dans l'un ou l'autre ne dépend de l'outil, et aucun ne fait d'affirmation sur ce qu'un outil fait avec ce qu'on lui donne.
Cette retenue est délibérée. Une compétence qui dit « l'outil X accepte une description façonnée comme ceci » fait une affirmation sur le produit de quelqu'un d'autre qui devient obsolète en silence, et le lecteur n'a aucun moyen de distinguer une affirmation actuelle d'une affirmation vieille de deux ans. Ces fichiers décrivent donc ce que le document contient et pourquoi il est façonné ainsi. Lorsque quelque chose à propos d'un outil a été réellement vérifié, le fichier le dit avec la date de la vérification, et ne dit rien au-delà de ce que la vérification a couvert.
Le registre n'atteint le design qu'à un seul endroit
Le registre est hérité du Brief de Conversion et n'est jamais redécidé ici ; le raisonnement derrière cela appartient à ../audience-research/SKILL.md. Les cinq profils eux-mêmes se trouvent dans ../audience-research/references/register-profiles.md.
Il touche une décision dans cette compétence : combien d'accent la page est autorisée à dépenser. Tout le reste ici est structurel et voyage inchangé — la même section doit faire la même chose à un lecteur quel que soit ce lecteur. references/figma-refinement-spec.md porte cette unique intersection, et c'est le seul fichier de cette compétence qui lit une ligne de registre.
Ce que cette compétence ne fait pas
- Elle ne réécrit pas la copie. Si une section ne peut pas être mise en page parce que la copie ne dit jamais à quoi sert la section, c'est
../copy-sweeps/SKILL.mdquand le problème est la formulation et../conversion-page-build/SKILL.mdquand le problème est un argument manquant. Nommez lequel, et arrêtez-vous. - Elle ne choisit pas de style visuel. Pas de palette, pas d'échelle typographique, pas de valeurs d'espacement, pas de nombres de points de rupture. Elle définit le rang et la relation ; un système de design fournit les valeurs.
references/figma-refinement-spec.mdénonce le refus en détail et quoi faire lorsqu'il n'y a pas de système de design pour les fournir. - Elle ne travaille jamais à partir d'une page déjà en ligne. Cette compétence avance, de la copie approuvée vers une mise en page que personne n'a construite. Juger une mise en page existante va dans l'autre sens et nécessite des preuves que cette compétence n'a pas —
../conversion-page-audit/SKILL.md. - Elle ne construit pas. Les notes de plateforme existent pour qu'un spec ne demande pas quelque chose que la cible de construction ne peut pas faire à moindre coût. Ce ne sont pas des instructions de construction et cela ne fait pas de cette compétence une compétence de construction.
Éléments non résolus
Tout ce que le transfert ne peut pas trancher à partir de la copie et du brief est écrit NON ÉTABLI — <ce qui le résoudrait> dans le document plutôt que deviné. La discipline et son raisonnement sont énoncés une fois pour l'ensemble du plugin dans ../audience-research/SKILL.md et s'appliquent ici inchangés. Deux cas reviennent le plus souvent : un actif dont la mise en page dépend mais que personne n'a encore produit, et un élément de preuve que la copie promet mais qui n'existe pas.
Ce que cela produit
Un seul document de transfert. Selon le classement de ce coffre, il atterrit dans 03 Projets/<Projet>/<Page>/[C] Transfert Design — <Page>.md ; ailleurs, là où le projet conserve ses specs. Il contient, dans cet ordre : la carte des composants par section, le brief du wireframe, le spec de raffinement, et — uniquement si une plateforme a été nommée — les notes de plateforme qui s'y appliquent.
Dites où vous l'avez classé, et dites si le passage plateforme a été exécuté. Un transfert qui est silencieux sur la plateforme est lu comme un transfert où la plateforme a été vérifiée.