Krypto Whitepaper schreiben: Eine Anleitung, der Leser folgen können

Wo fängt man vor dem Schreiben an?

Beginnen Sie damit, zu entscheiden, wem das Whitepaper dient und was dieser Leser verstehen muss. Eine kurze Vorbereitungssequenz hält den ersten Entwurf fokussiert.

1. Benennen Sie den Leser. Wählen Sie die Hauptzielgruppe, z. B. Produktnutzer, Entwickler, Partner oder Token Holder.
2. Legen Sie den Zweck des Whitepapers fest. Notieren Sie, was jemand nach dem Lesen verstanden haben sollte.
3. Beschreiben Sie das Projekt klar. Nennen Sie das Problem, Ihren Lösungsvorschlag und die aktuelle Phase des Projekts.
4. Listen Sie die Fragen auf. Fügen Sie die Fragen zur Produktnutzung, zum Systemdesign und zur Token-Rolle hinzu, die für diesen Leser wichtig sind.
5. Finden Sie die Quellenverantwortlichen. Ordnen Sie jedem Thema eine Person oder ein Dokument zu, das es bestätigen kann.

Stellen Sie sich ein kleines Team für Austauschpartnerschaften am Abend vor einem AMA vor. Sie brauchen eine einfache Darstellung des Projekts, keinen Haufen zusammenhangloser Behauptungen. Wir würden ihnen helfen, aufzulisten, was das Whitepaper erklären muss, und dann markieren, welche Punkte vor der Veröffentlichung einer Teamprüfung bedürfen.

Wenn das Team das Projekt nicht in ein paar einfachen Sätzen erklären kann, halten Sie inne. Erarbeiten Sie die zentrale Idee gemeinsam, bevor Sie Kapitel verfassen. Diese kurze Pause kann wiederholte Erklärungen und ein Whitepaper verhindern, das gleichzeitig alle Zielgruppen bedienen will.

Geben Sie Lesern einen Pfad durch das Projekt

Eine nützliche Struktur führt vom Problem des Lesers zur Antwort des Projekts und erklärt dann das System und seine offenen Fragen. Platzieren Sie die Kernaussage früh, damit Leser nicht nach dem Zweck des Projekts suchen müssen.

Eine flexible Reihenfolge kann mit einer kurzen Zusammenfassung beginnen. Stellen Sie dann das Problem und die betroffenen Personen vor. Erklären Sie als Nächstes das Produkt und seine Hauptnutzerreise. Zeigen Sie, wie das System entworfen ist, und beschreiben Sie dann die Rolle des Tokens, sofern relevant. Schließen Sie mit dem Status, Abhängigkeiten und Risiken des Projekts. Fügen Sie Teamdetails, Quellen und Offenlegungen hinzu, wenn sie den Lesern bei der Bewertung des Materials helfen.

Stellen Sie sich vor, ein Leser sieht eine Token-Allokationstabelle, bevor er erfährt, was das Produkt tut. Er könnte Schwierigkeiten haben zu verstehen, warum diese Allokationen wichtig sind. Stellen Sie die Produkterklärung an den Anfang und verbinden Sie dann jede Token-Funktion mit einem echten Teil des Systems.

Behandeln Sie dies als eine Route, nicht als eine verbindliche Liste von Kapiteln. Lassen Sie Material weg, das dem Zweck des Whitepapers nicht dient, und erklären Sie eine Auslassung, wenn Leser sie verwirrend finden könnten. Ein Diagramm kann einen Ablauf verdeutlichen, wenn es beschriftet, wer handelt, was sich bewegt und was der Benutzer beobachten kann. Halten Sie es konsistent mit der schriftlichen Erklärung. Die Checkliste für den Token Launch kann Ihnen helfen zu prüfen, wie das Whitepaper zu anderen Launch-Materialien passt.

Was gehört in das Whitepaper und wann?

Nehmen Sie ein Thema auf, wenn es den Lesern hilft, das Projekt zu verstehen oder eine wichtige Behauptung zu prüfen. Die folgende Tabelle bietet einen praktischen Ausgangspunkt; passen Sie sie an Ihr Projekt und Ihre Zielgruppe an.

Sie müssen nicht jedem Thema den gleichen Raum geben. Ein technischer Leser benötigt möglicherweise eine detailliertere Darstellung von Komponenten und Abhängigkeiten. Ein breiteres Publikum benötigt möglicherweise die Produktreise und den Token-Zweck in einfacherer Sprache. Definieren Sie in beiden Fällen Fachbegriffe bei ihrem ersten Auftreten.

Sagen Sie, dass eine Funktion geplant und nicht live ist, wenn sie noch entwickelt wird. Geben Sie an, ob Token-Zahlen festgelegt oder vorgeschlagen sind. Wenn ein Detail außerhalb des Zwecks des Whitepapers liegt, sagen Sie dies klar, anstatt die Leser raten zu lassen. Auf unserer Seite Whitepaper und Litepaper schreiben wird erklärt, wie Schreibunterstützung bei der Gestaltung des Dokuments helfen kann.

Können Leser jede wichtige Behauptung überprüfen?

Leser können ein Whitepaper leichter bewerten, wenn seine wichtigen Aussagen einen klaren Status und eine Quelle haben. Markieren Sie während des Schreibens jede Behauptung als aktuelle Tatsache, Designabsicht, Annahme oder Plan. Diese einfache Unterscheidung hilft dem Team zu vermeiden, zukünftige Arbeiten als etwas darzustellen, das bereits genutzt werden kann.

Führen Sie neben dem Entwurf eine Arbeitsliste der Behauptungen. Notieren Sie für jeden Punkt die Formulierung, seinen Status, die Quelle und die Person, die sie bestätigen kann. Eine Aussage über eine Produktfunktion könnte auf eine Demo oder ein Produktdokument verweisen. Eine Aussage über das Systemverhalten sollte an den technischen Verantwortlichen gehen. Eine Token-Beschreibung sollte anhand der aktuell genehmigten Informationen des Teams geprüft werden.

Verwenden Sie dieselben Namen und Begriffe in Diagrammen, Tabellen und Fließtext. Wenn eine wichtige Behauptung keine Quelle hat, fragen Sie, ob das Team sie auf andere Weise stützen kann. Wenn sie nicht wesentlich ist, entfernen Sie sie. Wenn sie noch unsicher ist, beschreiben Sie die Unsicherheit und ihre Ursache in einfacher Sprache.

Für eine zweite Prüfung bitten Sie jemanden außerhalb der Schreibgruppe, das Projekt nach dem Lesen der Zusammenfassung zu erklären. Achten Sie darauf, wo sie innehalten oder eine andere Darstellung geben. Diese Momente zeigen, wo das Whitepaper eine klarere Erklärung braucht, nicht nur eine glattere Formulierung.

Kleine Stolperfallen beim Schreiben, die große Fragen hinterlassen

Die schwierigsten Probleme sind oft Lücken zwischen Abschnitten. Eine abschließende Überprüfung sollte nach Widersprüchen und fehlendem Kontext suchen, nicht nur nach Rechtschreibung und Layout.

• Ein unscharfer Zweck: Leser können nicht sagen, wem das Produkt dient oder was es ändert.
• Pläne als Tatsachen geschrieben: Zukünftige Funktionen klingen heute verfügbar.
• Token-Details ohne Beschriftung: Leser können nicht sagen, was eine Zahl beschreibt oder ob sie festgelegt ist.
• Behauptungen ohne Prüfung: Aussagen über Design, Sicherheit oder Leistung haben keine benannte Quelle.

Versuchen Sie einen einfachen Durchlesen. Bitten Sie eine Person, die neu im Projekt ist, zu erklären, was live ist, was geplant ist und wie der Token passt. Vergleichen Sie dann ihre Darstellung mit der beabsichtigten Erklärung des Teams. Beheben Sie die verwirrende Passage und prüfen Sie verwandte Abschnitte auf das gleiche Problem.

Ein Whitepaper kann ein Projekt erklären, aber es kann keine rechtliche Compliance herstellen oder die Akzeptanz einer Börse sichern. Diese Entscheidungen gehören zu den relevanten Beratern und Plattformen, deren Prüfungen und Anforderungen außerhalb der Kontrolle des Dokumentenautors bleiben.

Wenn Sie einen Schreibplan brauchen, vergleichen Sie den Aufwand mit dem Kostenleitfaden für das Whitepaper-Schreiben, bevor Sie entscheiden, welche Unterstützung passt.

Halten Sie das Whitepaper im Gleichschritt mit den Projektänderungen

Ein veröffentlichtes Whitepaper bleibt nützlich, wenn jemand es mit dem Projekt, das Leser sehen können, im Gleichschritt hält. Wählen Sie einen Verantwortlichen, der bemerken kann, wenn Produktfunktionen, Token-Details oder wichtige Abhängigkeiten geändert haben.

Halten Sie eine klare Versionsbezeichnung und notieren Sie, was sich bei jeder Überarbeitung geändert hat. Prüfen Sie Diagramme, Referenzen und definierte Begriffe zusammen mit dem Text. Wenn eine frühere Version verfügbar bleibt, geben Sie Leser eine kurze Notiz, die ihnen hilft zu verstehen, was sich zwischen Versionen geändert hat.

Stellen Sie sich vor, das Team aktualisiert einen Produktablauf nach der Veröffentlichung des Whitepapers. Der Verantwortliche kann den neuen Ablauf mit dem Whitepaper vergleichen und jede Passage finden, die ihn beschreibt. Dann bitten Sie den technischen Verantwortlichen, den Ersatztext zu bestätigen. Diese Prüfung macht die Wartung zu einem Teil des Schreibplans, nicht zu einem nachträglichen Gedanken.

Halten Sie die Website-Zusammenfassung, Token-Materialien und Launch-Kommunikation konsistent mit der Darstellung des Whitepapers. Wenn Sie eine zweite Meinung wünschen, senden Sie Brand Community Ihren aktuellen Entwurf oder Ihre Notizen. Fügen Sie den beabsichtigten Leser und die Namen der Personen hinzu, die Produkt-, technische und Token-Details bestätigen können. Wir beginnen mit der Überprüfung der Gliederung und der Identifizierung der Fragen, die vor dem Schreiben zu klären sind. Weitere praktische Lektüre finden Sie im Blog.

So funktioniert's

1. Legen Sie Leser und Zweck festNotieren Sie, für wen das Whitepaper ist und was sie verstehen sollen. Markieren Sie, was live, geplant oder unentschieden ist.
2. Sammeln Sie Quellen und VerantwortlicheSammeln Sie Produktnotizen, technisches Material und genehmigte Token-Details. Nennen Sie eine Person, die jedes Thema bestätigen kann.
3. Ordnen Sie die GliederungStellen Sie die Hauptfragen der Leser in eine klare Reihenfolge. Klären Sie fehlende Informationen vor dem Schreiben.
4. Schreiben und prüfen SieVerwenden Sie einfache Sprache und kennzeichnen Sie Annahmen. Bitten Sie die relevanten Teammitglieder, ihre Behauptungen anhand des Quellenmaterials zu prüfen.
5. Überarbeiten und pflegen SieBearbeiten Sie Kommentare, prüfen Sie Begriffe und dokumentieren Sie die genehmigte Version. Beauftragen Sie jemanden, das Whitepaper zu überprüfen, wenn sich Projektdetails ändern.