Cara buat whitepaper crypto yang mudah diikuti

Di mana Anda memulai sebelum menulis?

Mulailah dengan memutuskan siapa yang dilayani whitepaper dan apa yang perlu dipahami pembaca tersebut. Urutan persiapan singkat menjaga fokus draf pertama.

1. Sebutkan pembaca. Pilih audiens utama, misalnya pengguna produk, pengembang, mitra, atau token holders.
2. Tetapkan tugas whitepaper. Tuliskan apa yang harus dipahami seseorang setelah membacanya.
3. Jelaskan proyek secara sederhana. Nyatakan masalah, respons yang Anda usulkan, dan tahap proyek saat ini.
4. Daftar pertanyaan. Sertakan pertanyaan tentang penggunaan produk, desain sistem, dan peran token yang penting bagi pembaca ini.
5. Temukan pemilik sumber. Cocokkan setiap topik dengan orang atau dokumen yang dapat mengonfirmasinya.

Bayangkan tim kemitraan kecil malam sebelum AMA. Mereka membutuhkan penjelasan sederhana tentang proyek, bukan tumpukan klaim yang tidak terhubung. Kami akan membantu mereka mendaftar apa yang harus dijelaskan whitepaper, lalu menandai poin mana yang perlu diperiksa tim sebelum dibagikan.

Jika tim tidak dapat menjelaskan proyek dalam beberapa kalimat sederhana, berhentilah. Kerjakan ide inti bersama sebelum menulis bab. Jeda kecil itu dapat mencegah penjelasan berulang dan whitepaper yang mencoba melayani semua audiens sekaligus.

Berikan pembaca jalur melalui proyek

Struktur yang berguna bergerak dari masalah pembaca ke respons proyek, lalu menjelaskan sistem dan pertanyaan terbukanya. Tempatkan penjelasan inti di awal sehingga pembaca tidak perlu mencari tujuan proyek.

Urutan yang fleksibel dapat dimulai dengan ringkasan singkat. Kemudian perkenalkan masalah dan orang yang terkena dampak. Jelaskan produk dan perjalanan pengguna utamanya berikutnya. Tunjukkan bagaimana sistem dirancang, lalu jelaskan peran token jika relevan. Akhiri dengan status proyek, ketergantungan, dan risiko. Tambahkan detail tim, sumber, dan pengungkapan jika membantu pembaca menilai materi.

Misalnya, bayangkan pembaca melihat tabel alokasi token sebelum mempelajari apa yang dilakukan produk. Mereka mungkin kesulitan memahami mengapa alokasi itu penting. Tempatkan penjelasan produk terlebih dahulu, lalu hubungkan setiap fungsi token ke bagian nyata dari sistem.

Anggap ini sebagai rute, bukan daftar bab yang wajib. Tinggalkan materi yang tidak melayani tujuan whitepaper, dan jelaskan penghilangan jika pembaca bisa bingung. Diagram dapat memperjelas alur jika memberi label siapa yang bertindak, apa yang bergerak, dan apa yang dapat diamati pengguna. Jaga konsistensinya dengan penjelasan tertulis. Daftar periksa token launch dapat membantu Anda memeriksa bagaimana whitepaper cocok dengan materi launch lainnya.

Apa yang termasuk dalam whitepaper, dan kapan?

Sertakan topik jika membantu pembaca memahami proyek atau memeriksa klaim penting. Tabel di bawah memberikan titik awal yang praktis; sesuaikan dengan proyek dan audiens Anda.

Anda tidak perlu memberikan ruang yang sama untuk setiap topik. Pembaca teknis mungkin membutuhkan penjelasan lebih rinci tentang komponen dan ketergantungan. Audiens yang lebih luas mungkin membutuhkan perjalanan produk dan tujuan token dalam bahasa yang lebih sederhana. Dalam kedua kasus, definisikan istilah khusus saat pertama kali muncul.

Katakan fitur direncanakan, bukan sudah berjalan, jika masih dalam pembangunan. Nyatakan apakah angka token sudah final atau masih usulan. Jika detail di luar tujuan whitepaper, katakan secara langsung daripada membiarkan pembaca menebak. Halaman penulisan whitepaper dan litepaper kami menjelaskan bagaimana dukungan penulisan dapat membantu membentuk dokumen.

Bisakah pembaca memeriksa setiap klaim penting?

Pembaca dapat menilai whitepaper lebih mudah ketika pernyataan pentingnya memiliki status dan sumber yang jelas. Saat menulis draf, tandai setiap klaim sebagai fakta saat ini, niat desain, asumsi, atau rencana. Perbedaan sederhana itu membantu tim menghindari menyajikan pekerjaan masa depan sebagai sesuatu yang sudah dapat digunakan orang.

Simpan daftar klaim kerja di samping draf. Untuk setiap poin, catat redaksi, statusnya, sumbernya, dan orang yang dapat mengonfirmasinya. Pernyataan tentang fitur produk mungkin merujuk pada demonstrasi atau dokumen produk. Pernyataan tentang perilaku sistem harus mengarah ke pemilik teknis. Deskripsi token harus diperiksa terhadap informasi yang disetujui tim saat ini.

Gunakan nama dan istilah yang sama dalam diagram, tabel, dan teks isi. Jika klaim penting tidak memiliki sumber, tanyakan apakah tim dapat mendukungnya dengan cara lain. Jika tidak penting, hapus. Jika masih tidak pasti, jelaskan ketidakpastian dan penyebabnya dalam bahasa sederhana.

Untuk pemeriksaan kedua, minta seseorang di luar kelompok penulisan untuk menjelaskan proyek setelah membaca ringkasan. Perhatikan di mana mereka berhenti atau memberikan penjelasan yang berbeda. Momen itu menunjukkan di mana whitepaper membutuhkan penjelasan yang lebih jelas, bukan hanya redaksi yang lebih halus.

Kendala kecil dalam penulisan yang meninggalkan pertanyaan besar

Masalah paling sulit untuk ditemukan sering kali adalah celah antar bagian. Tinjauan akhir harus mencari kontradiksi dan konteks yang hilang, tidak hanya ejaan dan tata letak.

• Tujuan yang kabur: pembaca tidak dapat mengetahui siapa yang dilayani produk atau apa yang diubahnya.
• Rencana ditulis sebagai fakta: fitur masa depan terdengar tersedia hari ini.
• Detail token tanpa label: pembaca tidak dapat mengetahui apa yang dijelaskan suatu angka atau apakah itu sudah final.
• Klaim tanpa pemeriksaan: pernyataan tentang desain, keamanan, atau kinerja tidak memiliki sumber yang disebutkan.

Coba baca langsung sederhana. Minta seseorang yang baru mengenal proyek untuk menjelaskan apa yang sudah berjalan, apa yang direncanakan, dan bagaimana token cocok. Kemudian bandingkan penjelasan mereka dengan penjelasan yang dimaksud tim. Perbaiki bagian yang membingungkan dan periksa bagian terkait untuk masalah yang sama.

Whitepaper dapat menjelaskan proyek, tetapi tidak dapat menetapkan kepatuhan hukum atau mendapatkan penerimaan dari bursa. Keputusan itu milik penasihat dan platform yang relevan, yang tinjauan dan persyaratannya tetap di luar kendali penulis dokumen.

Jika Anda membutuhkan rencana penulisan, bandingkan pekerjaan yang terlibat dengan panduan biaya penulisan whitepaper sebelum memutuskan dukungan apa yang sesuai.

Jaga whitepaper tetap selaras saat proyek berubah

Whitepaper yang diterbitkan tetap berguna jika seseorang menjaganya tetap selaras dengan proyek yang dapat dilihat pembaca. Pilih pemilik yang dapat melihat kapan fitur produk, detail token, atau ketergantungan penting telah berubah.

Simpan label versi yang jelas dan catat apa yang berubah setiap kali Anda merevisi whitepaper. Periksa ulang diagram, referensi, dan istilah yang didefinisikan bersama prosa. Jika versi sebelumnya masih tersedia, berikan pembaca catatan singkat yang membantu mereka memahami apa yang berubah antar versi.

Bayangkan tim memperbarui alur produk setelah whitepaper diterbitkan. Pemilik dapat membandingkan alur baru dengan whitepaper dan menemukan setiap bagian yang mendeskripsikannya. Kemudian minta pemilik teknis untuk mengonfirmasi teks pengganti. Pemeriksaan itu menjadikan pemeliharaan sebagai bagian dari rencana penulisan, bukan renungan.

Jaga ringkasan situs web, materi token, dan komunikasi launch tetap konsisten dengan penjelasan whitepaper. Jika Anda menginginkan pendapat kedua, kirimkan Brand Community draf atau catatan Anda saat ini. Sertakan pembaca yang dituju dan nama orang yang dapat mengonfirmasi detail produk, teknis, dan token. Kami akan mulai dengan meninjau kerangka dan mengidentifikasi pertanyaan yang harus diselesaikan sebelum menulis. Anda dapat menemukan bacaan praktis lebih lanjut di Blog.

Cara kerja

1. Tetapkan pembaca dan tujuanTuliskan untuk siapa whitepaper dan apa yang harus mereka pahami. Tandai apa yang sudah berjalan, direncanakan, atau belum diputuskan.
2. Kumpulkan sumber dan pemilikKumpulkan catatan produk, materi teknis, dan detail token yang disetujui. Sebutkan orang yang dapat mengonfirmasi setiap topik.
3. Atur kerangkaTempatkan pertanyaan utama pembaca dalam urutan yang jelas. Selesaikan informasi yang hilang sebelum menulis draf.
4. Tulis draf dan periksaGunakan bahasa sederhana dan beri label asumsi. Minta anggota tim yang relevan untuk memeriksa klaim mereka terhadap materi sumber.
5. Revisi dan rawatSelesaikan komentar, periksa istilah, dan catat versi yang disetujui. Tunjuk seseorang untuk meninjau whitepaper saat detail proyek berubah.