Comment rédiger un guide de livre blanc crypto que les lecteurs peuvent suivre

Par où commencer avant d'écrire ?

Commencez par décider à qui s'adresse le document et ce que ce lecteur doit comprendre. Une courte séquence de préparation permet de garder le premier brouillon ciblé.

1. Nommez le lecteur. Choisissez le public principal, comme les utilisateurs du produit, les développeurs, les partenaires ou les détenteurs de tokens.
2. Définissez le rôle du document. Écrivez ce que quelqu'un devrait comprendre après l'avoir lu.
3. Décrivez le projet simplement. Énoncez le problème, votre réponse proposée et le stade actuel du projet.
4. Listez les questions. Incluez les questions sur l'utilisation du produit, la conception du système et le rôle du token qui importent à ce lecteur.
5. Trouvez les responsables des sources. Associez chaque sujet à une personne ou un document qui peut le confirmer.

Imaginez une petite équipe de partenariats d'échange la veille d'un AMA. Ils ont besoin d'un compte rendu simple du projet, pas d'un tas d'affirmations déconnectées. Nous les aiderions à lister ce que le document doit expliquer, puis à marquer les points qui nécessitent une vérification par l'équipe avant d'être partagés.

Si l'équipe ne peut pas expliquer le projet en quelques phrases simples, faites une pause. Élaborez ensemble l'idée centrale avant de rédiger les chapitres. Cette petite pause peut éviter des explications répétées et un document qui essaie de servir tous les publics à la fois.

Offrir aux lecteurs un chemin à travers le projet

Une structure utile passe du problème du lecteur à la réponse du projet, puis explique le système et ses questions ouvertes. Placez l'explication centrale tôt pour que les lecteurs n'aient pas à chercher l'objectif du projet.

Un ordre flexible peut commencer par un résumé court. Présentez ensuite le problème et les personnes concernées. Expliquez le produit et son parcours utilisateur principal. Montrez ensuite comment le système est conçu, puis décrivez le rôle du token le cas échéant. Terminez par le statut du projet, ses dépendances et ses risques. Ajoutez les détails de l'équipe, les sources et les divulgations lorsqu'ils aident les lecteurs à évaluer le contenu.

Par exemple, imaginez qu'un lecteur voie un tableau d'allocation de tokens avant d'apprendre ce que fait le produit. Il pourrait avoir du mal à comprendre pourquoi ces allocations sont importantes. Mettez l'explication du produit en premier, puis reliez chaque fonction du token à une partie réelle du système.

Considérez cela comme un itinéraire, pas une liste de chapitres obligatoires. Laissez de côté le contenu qui ne sert pas l'objectif du document et expliquez une omission si les lecteurs pourraient la trouver déroutante. Un diagramme peut clarifier un flux lorsqu'il étiquette qui agit, ce qui se déplace et ce que l'utilisateur peut observer. Gardez-le cohérent avec l'explication écrite. La checklist de lancement de token peut vous aider à vérifier comment le document s'intègre avec les autres supports de lancement.

Qu'est-ce qui appartient au document, et quand ?

Incluez un sujet lorsqu'il aide les lecteurs à comprendre le projet ou à vérifier une affirmation importante. Le tableau ci-dessous donne un point de départ pratique ; ajustez-le en fonction de votre projet et de votre public.

Vous n'avez pas besoin de donner à chaque sujet un espace égal. Un lecteur technique peut avoir besoin d'un compte rendu plus détaillé des composants et des dépendances. Un public plus large peut avoir besoin du parcours produit et de l'objectif du token dans un langage plus simple. Dans les deux cas, définissez les termes spécialisés là où ils apparaissent pour la première fois.

Dites qu'une fonctionnalité est planifiée, pas opérationnelle, si elle est encore en développement. Indiquez si les chiffres du token sont définitifs ou proposés. Si un détail est en dehors de l'objectif du document, dites-le clairement plutôt que de laisser les lecteurs deviner. Notre page rédaction de livre blanc et litepaper explique comment le soutien à la rédaction peut aider à façonner le document.

Les lecteurs peuvent-ils vérifier chaque affirmation importante ?

Les lecteurs peuvent évaluer un document plus facilement lorsque ses déclarations importantes ont un statut clair et une source. Pendant la rédaction, marquez chaque affirmation comme un fait actuel, une intention de conception, une hypothèse ou un plan. Cette simple distinction aide l'équipe à éviter de présenter un travail futur comme quelque chose que les gens peuvent déjà utiliser.

Conservez une liste de travail des affirmations à côté du brouillon. Pour chaque point, notez le libellé, son statut, la source et la personne qui peut le confirmer. Une déclaration sur une fonctionnalité du produit pourrait renvoyer à une démonstration ou à un document produit. Une déclaration sur le comportement du système devrait aller au responsable technique. Une description du token doit être vérifiée par rapport aux informations approuvées actuelles de l'équipe.

Utilisez les mêmes noms et termes dans les diagrammes, les tableaux et le texte du corps. Si une affirmation importante n'a pas de source, demandez si l'équipe peut la soutenir d'une autre manière. Si elle n'est pas essentielle, supprimez-la. Si elle est encore incertaine, décrivez l'incertitude et sa cause en langage clair.

Pour une deuxième vérification, demandez à quelqu'un d'extérieur au groupe de rédaction d'expliquer le projet après avoir lu le résumé. Notez où il s'arrête ou donne un compte rendu différent. Ces moments montrent où le document a besoin d'une explication plus claire, pas seulement d'un libellé plus fluide.

Petits pièges de rédaction qui laissent de grandes questions

Les problèmes les plus difficiles à repérer sont souvent les écarts entre les sections. Une révision finale devrait rechercher les contradictions et le manque de contexte, pas seulement l'orthographe et la mise en page.

• Un objectif flou : les lecteurs ne peuvent pas dire à qui le produit s'adresse ou ce qu'il change.
• Des plans écrits comme des faits : les fonctionnalités futures semblent disponibles aujourd'hui.
• Des détails sur le token sans étiquettes : les lecteurs ne peuvent pas dire ce qu'un chiffre décrit ou s'il est définitif.
• Des affirmations sans vérification : les déclarations sur la conception, la sécurité ou les performances n'ont pas de source nommée.

Essayez une simple lecture. Demandez à une personne nouvelle au projet d'expliquer ce qui est opérationnel, ce qui est planifié et comment le token s'intègre. Comparez ensuite son compte rendu avec l'explication prévue par l'équipe. Corrigez le passage confus et vérifiez les sections connexes pour le même problème.

Un livre blanc peut expliquer un projet, mais il ne peut pas établir la conformité légale ou garantir l'acceptation par un exchange. Ces décisions appartiennent aux conseillers et plateformes concernés, dont les examens et les exigences restent en dehors du contrôle du rédacteur du document.

Si vous avez besoin d'un plan de rédaction, comparez le travail impliqué avec le guide des coûts de rédaction de livre blanc avant de décider quel soutien convient.

Garder le document aligné à mesure que le projet évolue

Un document publié reste utile lorsque quelqu'un le maintient aligné sur le projet que les lecteurs peuvent voir. Choisissez un responsable qui peut remarquer quand les fonctionnalités du produit, les détails du token ou les dépendances importantes ont changé.

Conservez une étiquette de version claire et enregistrez ce qui a changé à chaque révision du document. Revérifiez les diagrammes, les références et les termes définis en même temps que le texte. Si une version antérieure reste disponible, donnez aux lecteurs une courte note qui les aide à comprendre ce qui a changé entre les versions.

Imaginez que l'équipe met à jour un flux de produit après la publication du document. Le responsable peut comparer le nouveau flux avec le document et trouver chaque passage qui le décrit. Demandez ensuite au responsable technique de confirmer le texte de remplacement. Cette vérification fait de la maintenance une partie du plan de rédaction, pas une réflexion après coup.

Gardez le résumé du site web, les supports du token et les communications de lancement cohérents avec le compte rendu du document. Si vous souhaitez un deuxième avis, envoyez à Brand Community votre brouillon ou vos notes actuels. Incluez le lecteur visé et les noms des personnes qui peuvent confirmer les détails du produit, techniques et du token. Nous commencerons par examiner le plan et identifier les questions à régler avant la rédaction. Vous pouvez trouver d'autres lectures pratiques sur le Blog.

Comment ça marche

1. Définir le lecteur et l'objectifÉcrivez à qui s'adresse le document et ce qu'ils doivent comprendre. Marquez ce qui est opérationnel, planifié ou indécis.
2. Rassembler les sources et les responsablesCollectez les notes produit, le matériel technique et les détails approuvés du token. Nommez une personne qui peut confirmer chaque sujet.
3. Organiser le planMettez les principales questions du lecteur dans un ordre clair. Résolvez les informations manquantes avant de rédiger.
4. Rédiger et vérifierUtilisez un langage simple et étiquetez les hypothèses. Demandez aux membres concernés de l'équipe de vérifier leurs affirmations par rapport au matériel source.
5. Réviser et maintenirRésolvez les commentaires, vérifiez les termes et enregistrez la version approuvée. Assignez quelqu'un pour réviser le document lorsque les détails du projet changent.