Cara buat whitepaper crypto yang bisa diikuti pembaca skeptis

Apa yang harus bisa diputuskan oleh pembaca?

Tes cepat: Berikan draf Anda kepada seseorang di luar tim dan minta mereka menggarisbawahi setiap klaim yang tidak bisa mereka periksa. Anda akan langsung melihat bagian mana yang perlu bukti.

Whitepaper crypto harus membantu pembaca memahami apa yang diusulkan proyek, bagaimana cara kerjanya, dan apa yang masih belum pasti. Sebelum menulis, putuskan siapa yang membutuhkan dokumen dan apa yang harus bisa mereka evaluasi setelah membacanya. Pengembang mungkin membutuhkan detail arsitektur; calon pemegang token mungkin membutuhkan informasi utilitas dan distribusi yang jelas; mitra mungkin perlu memahami model operasi proyek.

Tulis ringkasan singkat untuk tim sebelum menulis draf. Sertakan:

• Pembaca utama dan pertanyaan yang mungkin mereka bawa.
• Masalah yang diatasi proyek, diungkapkan tanpa klaim promosi.
• Apa yang dicakup dokumen dan apa yang termasuk dalam makalah teknis, peta jalan, atau dokumen hukum terpisah.
• Tindakan yang dapat diambil pembaca selanjutnya, seperti meninjau dokumentasi atau menghubungi tim.

Ringkasan semacam itu berguna sebagai pemeriksaan rencana: jika bagian yang diusulkan tidak menjawab pertanyaan pembaca atau mendukung klaim proyek, hapus atau jelaskan mengapa bagian itu diperlukan. Whitepaper tidak boleh mencoba melayani semua audiens secara setara. Ketika proyek membutuhkan ikhtisar singkat untuk percakapan awal, litepaper mungkin menjadi pendamping yang lebih baik; kedua dokumen dapat memiliki peran yang berbeda daripada saling mengulang.

Struktur yang mudah diikuti

Struktur yang kuat bergerak dari masalah pembaca ke solusi yang diusulkan proyek, lalu memberikan detail yang cukup untuk menilai desain dan keterbatasannya. Tidak ada kerangka wajib untuk setiap proyek, tetapi urutan yang dapat diprediksi membantu pembaca menemukan informasi yang mereka butuhkan.

Pertimbangkan untuk mengatur dokumen dalam urutan ini:

• Ringkasan: nyatakan masalah, pendekatan yang diusulkan, dan pengguna yang dituju.
• Konteks dan kebutuhan: jelaskan kesulitan saat ini dan mengapa itu penting.
• Solusi dan produk: deskripsikan pengalaman pengguna dan komponen utama sistem.
• Desain teknis: jelaskan arsitektur yang relevan, dependensi, dan bagaimana komponen berinteraksi.
• Desain token: nyatakan apakah token ada, peran apa yang dimainkannya, dan bagaimana pasokan serta alokasi dijelaskan.
• Peta jalan dan tata kelola: bedakan kemampuan saat ini dari pekerjaan yang direncanakan dan jelaskan siapa yang membuat keputusan.
• Risiko dan asumsi: sebutkan dependensi penting, pertanyaan terbuka, dan kemungkinan kendala.

Sesuaikan kerangka dengan proyek, bukan sebaliknya. Makalah protokol membutuhkan penjelasan teknis yang lebih banyak daripada ikhtisar aplikasi konsumen. Tambahkan diagram hanya jika memperjelas hubungan atau proses, dan pastikan prosa menjelaskannya bagi pembaca yang tidak dapat menafsirkan visual secara sekilas. Untuk daftar periksa yang berfokus pada informasi token, lihat cara memverifikasi pasokan di CoinGecko; jaga pernyataan pasokan whitepaper tetap konsisten dengan catatan proyek.

Membuat klaim teknis dan token dapat diperiksa

Buat setiap klaim penting cukup spesifik sehingga pembaca dapat mengetahui apa yang mendukungnya. Pernyataan luas seperti "sepenuhnya terdesentralisasi" atau "aman sejak desain" tidak menjelaskan properti sistem mana yang dimaksud, bukti apa yang mendukungnya, atau trade-off apa yang tersisa.

Untuk setiap klaim material, catat sumber dan orang yang bertanggung jawab untuk mengonfirmasinya. Sumber itu bisa berupa fitur yang diimplementasikan, dokumentasi teknis, audit yang dipublikasikan, alokasi token yang disetujui oleh tim, atau asumsi yang diberi label dengan jelas. Jangan menyajikan rencana sebagai kemampuan yang sudah ada. Jika detail belum diputuskan, katakan demikian dan identifikasi siapa yang memiliki keputusan.

Berikan perhatian khusus pada area ini:

• Arsitektur: sebutkan komponen dan deskripsikan bagaimana informasi atau aset bergerak di antara mereka.
• Keamanan: nyatakan apa yang telah ditinjau dan apa yang belum; hindari menyiratkan bahwa tinjauan menghilangkan semua risiko.
• Peran token: jelaskan fungsi dalam produk daripada mengandalkan deskripsi abstrak.
• Pasokan dan alokasi: tunjukkan kategori, waktu, dan kondisi apa pun yang benar-benar telah disetujui tim.
• Tata kelola: identifikasi hak pengambilan keputusan dan deskripsikan bagaimana perubahan yang diusulkan ditangani.

Simpan tabel bukti dalam draf kerja dengan klaim, sumber, pemilik, dan status tinjauan. Tabel adalah alat bantu editorial, bukan bukti itu sendiri. Untuk versi yang menghadap publik, terjemahkan terminologi teknis jika memungkinkan dan definisikan istilah yang diperlukan pada penggunaan pertama. Pembaca harus dapat melacak klaim tanpa perlu menebak apa yang dimaksud tim.

Menulis dan meninjau makalah

Tulis dokumen dalam beberapa tahap, dengan pemilik subjek memeriksa klaim sebelum prosa dipoles. Ini mengurangi penulisan ulang yang tidak perlu: penulis dapat meningkatkan kejelasan, tetapi tidak dapat menyelesaikan keputusan token atau memverifikasi arsitektur yang belum ditetapkan tim.

Urutan yang praktis adalah:

1. Kumpulkan materi sumber. Kumpulkan dokumentasi produk, catatan arsitektur, informasi token yang disetujui, detail peta jalan, dan pernyataan publik yang ada.
2. Tetapkan kerangka. Petakan setiap pertanyaan pembaca ke bagian dan tandai topik apa pun yang tidak memiliki pemilik atau jawaban yang dikonfirmasi.
3. Tulis untuk makna. Tulis penjelasan langsung terlebih dahulu. Jaga konsistensi terminologi proyek dan definisikan istilah saat muncul.
4. Lakukan tinjauan subjek. Minta pemilik teknis, produk, dan desain token untuk memverifikasi bagian mereka terhadap keputusan dan sumber saat ini.
5. Edit dan setujui. Periksa struktur, konsistensi, diagram, detail versi, dan tinjauan hukum atau kepatuhan apa pun yang diperlukan oleh proyek.

Berikan permintaan yang terfokus kepada pengulas daripada meminta "lihat" secara umum. Misalnya, minta pimpinan teknik untuk memverifikasi deskripsi komponen dan minta pemilik desain token untuk memeriksa bahasa alokasi terhadap model yang disetujui. Simpan satu salinan master dan catat perubahan mana yang diterima, ditunda, atau tidak terselesaikan. Jika Anda membutuhkan dukungan penulisan eksternal, penulisan whitepaper dan litepaper dapat membantu mengubah materi proyek menjadi dokumen yang siap dibaca; siapkan paket sumber dan pemilik keputusan sebelum memulai.

Daftar periksa whitepaper 7 poin Anda

Periksa setiap draf terhadap 7 poin ini sebelum orang di luar tim Anda melihatnya. Jika makalah Anda lulus semua 7 poin, Anda akan lebih mudah mempertahankannya dalam tanya jawab dan lebih mudah memotongnya ke format lain.

• Nyatakan pembaca dan tujuan di halaman 1.
• Definisikan masalah dalam 3 kalimat atau kurang.
• Deskripsikan produk dan teknologi dengan kata-kata sederhana.
• Jelaskan fungsi, pasokan, dan distribusi token.
• Tambahkan bagian risiko yang jujur.
• Hubungkan setiap angka ke sumber atau kontrak.
• Minta 2 pengulas menandatangani: satu teknis, satu hukum.

Istilah dalam satu baris

Whitepaper (dengan kata sederhana: dokumen panjang yang menjelaskan teknologi, token, dan rencana proyek).

Litepaper berarti ringkasan singkat whitepaper untuk pembaca yang menginginkan intinya.

Kesalahan yang merusak kepercayaan

Kesalahan umum: Mencampur bahasa pemasaran ke dalam bagian teknis. Pisahkan klaim dan teks iklan, dan biarkan pembaca Anda memutuskan.

Kesalahan whitepaper yang paling merusak biasanya adalah inkonsistensi, kepastian yang tidak didukung, dan detail yang mengaburkan daripada menjelaskan proyek. Tata letak yang rapi tidak dapat memperbaiki klaim yang bertentangan dengan produk atau satu sama lain.

Perhatikan masalah ini selama tinjauan:

• Menyalin kerangka umum: bagian tentang fitur yang tidak dimiliki proyek membuat dokumen lebih sulit dipercaya. Hapus atau jelaskan relevansinya.
• Mencampur bentuk waktu sekarang dan masa depan: pisahkan dengan jelas apa yang tersedia, sedang dibangun, dan hanya diusulkan.
• Menggunakan istilah token tanpa mendefinisikannya: jelaskan bagaimana token terkait dengan penggunaan produk, tata kelola, atau fungsi lain yang dinyatakan.
• Membiarkan bahasa alokasi tidak jelas: pembaca membutuhkan kategori yang konsisten dan penjelasan tentang kondisi yang relevan, bukan singkatan promosi.
• Membuat klaim keamanan atau kinerja absolut: deskripsikan desain dan bukti, bukan mengklaim hasil yang tidak dapat ditetapkan dokumen.
• Mengulangi promosi: whitepaper harus menjawab pertanyaan substantif, bukan mengulang slogan di setiap bagian.
• Membiarkan diagram bertentangan dengan teks: tetapkan pemilik untuk memeriksa label, alur, dan versi terhadap penjelasan tertulis.

Pemeriksaan konsistensi akhir harus membandingkan whitepaper dengan situs web, dokumentasi, materi token, dan status produk saat ini. Jika detail berbeda, selesaikan sumber mana yang terkini dan perbarui yang lain. Untuk urutan peluncuran proyek yang lebih luas, gunakan daftar periksa pemasaran token launch bersama dengan tinjauan dokumen.

Apa yang bisa dibuktikan whitepaper, dan apa yang perlu tinjauan lebih lanjut?

Whitepaper dapat menjelaskan desain proyek dan mengungkapkan dasar klaimnya; whitepaper tidak dapat melengkapi desain yang belum diputuskan atau menggantikan tinjauan spesialis. Perlakukan sebagai dokumen proyek yang dipelihara, bukan pengganti validasi teknis, nasihat hukum, atau catatan produk yang akurat.

Keterbatasan dan risiko: Deskripsi teknis bisa menjadi usang saat implementasi berubah, sementara pertanyaan token dan kepatuhan memerlukan konfirmasi dari pemilik proyek yang bertanggung jawab dan penasihat yang berkualifikasi. Dokumen yang jelas membantu pembaca memeriksa informasi yang dinyatakan, tetapi tidak dapat mensertifikasi bahwa sistem akan berkinerja seperti yang dijelaskan atau menyelesaikan bagaimana pihak eksternal akan menafsirkannya.

Sebelum publikasi, tetapkan pemilik untuk memelihara dokumen dan atur pemicu tinjauan. Pemicu yang berguna termasuk perubahan material pada produk, arsitektur, desain token, tata kelola, atau peta jalan. Catat tanggal versi dan ringkas apa yang berubah sehingga pembaca dapat membedakan informasi saat ini dari draf sebelumnya. Simpan file sumber untuk diagram dan pertahankan bukti yang digunakan untuk menyetujui klaim.

Jika whitepaper mendukung aplikasi bursa atau platform data, jaga detail faktualnya selaras dengan materi yang diajukan proyek; dokumen itu sendiri tidak menentukan hasil tinjauan platform. Lihat panduan terpisah untuk listing CoinMarketCap dan listing CoinGecko untuk proses aplikasi tersebut. Dokumen sumber yang ringkas dan konsisten memudahkan tim untuk menjelaskan proyek, tetapi setiap platform menangani keputusannya sendiri.

Kapan litepaper menjadi pilihan yang lebih baik?

Litepaper lebih cocok ketika tujuan langsungnya adalah memberikan pengantar yang ringkas kepada pembaca, sementara whitepaper penuh berguna ketika pembaca membutuhkan penjelasan yang lebih dalam tentang desain dan asumsinya. Nama saja tidak mendefinisikan rencana: putuskan berdasarkan apa yang perlu dinilai pembaca dan seberapa banyak materi yang didukung yang telah disiapkan tim.

Litepaper dapat memperkenalkan masalah, produk, peran token, dan langkah selanjutnya tanpa mencoba mendokumentasikan setiap pilihan teknis. Whitepaper yang lebih lengkap dapat memperluas arsitektur, tata kelola, pasokan, dependensi, dan risiko. Format yang lebih pendek tidak boleh menyembunyikan peringatan material atau menyiratkan bahwa rencana yang belum terselesaikan sudah pasti. Jika kedua dokumen ada, putuskan mana yang menjadi sumber kebenaran untuk setiap detail dan perbarui bersama ketika keputusan berubah.

Gunakan pemeriksaan keputusan ini sebelum memilih format:

• Apakah pembaca yang dituju membutuhkan detail implementasi untuk memahami proposal?
• Apakah klaim sentral proyek didukung oleh materi sumber dan tinjauan pemilik?
• Apakah tim siap memelihara tingkat detail yang direncanakan untuk dipublikasikan?
• Apakah ikhtisar singkat lebih berguna sekarang, dengan dokumen yang lebih dalam menyusul?

Jika Anda sedang menyiapkan draf, kirimkan MarketingExtra versi saat ini, dokumentasi proyek, informasi token yang disetujui, dan nama orang yang dapat memverifikasi klaim teknis dan produk. Kami dapat meninjau materi untuk kesenjangan dan membantu membentuk rencana whitepaper atau litepaper yang jelas; mulailah dengan ikhtisar penulisan whitepaper.

Cara kerja

1. Tetapkan pembaca dan tujuanTulis siapa yang dilayani dokumen dan apa yang perlu mereka pahami. Gunakan ini untuk memutuskan apa yang termasuk dalam whitepaper.
2. Kumpulkan sumber proyek saat iniKumpulkan materi teknis, produk, token, peta jalan, dan tata kelola. Tandai keputusan yang hilang dan tetapkan pemilik untuk masing-masing.
3. Petakan klaim ke buktiCatat sumber dan verifikator untuk pernyataan penting. Pisahkan kemampuan yang diimplementasikan dari rencana dan asumsi.
4. Tulis, lalu lakukan tinjauan terfokusTulis dalam urutan yang ramah pembaca dan minta pemilik subjek yang relevan untuk memeriksa bagian yang mereka kendalikan.
5. Setujui dan pelihara dokumenPeriksa konsistensi, detail versi, diagram, dan tinjauan spesialis yang diperlukan sebelum publikasi. Tetapkan pemilik untuk pembaruan di masa mendatang.