Cách viết sách trắng crypto mà mọi người có thể theo dõi

Bạn bắt đầu từ đâu trước khi viết?

Hãy bắt đầu bằng cách quyết định sách trắng phục vụ ai và người đọc đó cần hiểu điều gì. Một chuỗi chuẩn bị ngắn giúp bản nháp đầu tiên tập trung.

1. Xác định người đọc. Chọn đối tượng chính, chẳng hạn như người dùng sản phẩm, nhà phát triển, đối tác hoặc token holders.
2. Đặt nhiệm vụ của sách trắng. Viết ra điều ai đó nên hiểu sau khi đọc nó.
3. Mô tả dự án một cách đơn giản. Nêu vấn đề, phản hồi được đề xuất và giai đoạn hiện tại của dự án.
4. Liệt kê các câu hỏi. Bao gồm các câu hỏi về cách sử dụng sản phẩm, thiết kế hệ thống và vai trò token mà người đọc này quan tâm.
5. Tìm chủ sở hữu thông tin. Ghép mỗi chủ đề với một người hoặc tài liệu có thể xác nhận nó.

Hãy tưởng tượng một nhóm quan hệ đối tác nhỏ vào tối trước một AMA. Họ cần một bản tường trình đơn giản về dự án, không phải một đống tuyên bố rời rạc. Chúng tôi sẽ giúp họ liệt kê những gì sách trắng phải giải thích, sau đó đánh dấu những điểm cần kiểm tra với nhóm trước khi chia sẻ.

Nếu nhóm không thể giải thích dự án trong vài câu đơn giản, hãy dừng lại. Cùng nhau tìm ra ý tưởng trung tâm trước khi soạn thảo các chương. Khoảng dừng nhỏ đó có thể ngăn chặn việc giải thích lặp đi lặp lại và một sách trắng cố gắng phục vụ mọi đối tượng cùng một lúc.

Tạo một lộ trình cho người đọc xuyên suốt dự án

Một cấu trúc hữu ích di chuyển từ vấn đề của người đọc đến phản hồi của dự án, sau đó giải thích hệ thống và các câu hỏi mở của nó. Đặt phần giải thích cốt lõi ở đầu để người đọc không phải tìm kiếm mục đích của dự án.

Một thứ tự linh hoạt có thể bắt đầu bằng một bản tóm tắt ngắn. Sau đó giới thiệu vấn đề và những người bị ảnh hưởng. Tiếp theo, giải thích sản phẩm và hành trình người dùng chính của nó. Trình bày cách hệ thống được thiết kế, sau đó mô tả vai trò của token nếu có liên quan. Kết thúc với tình trạng, sự phụ thuộc và rủi ro của dự án. Thêm chi tiết về nhóm, nguồn và công bố khi chúng giúp người đọc đánh giá tài liệu.

Ví dụ, hãy tưởng tượng một người đọc nhìn thấy bảng phân bổ token trước khi biết sản phẩm làm gì. Họ có thể gặp khó khăn để hiểu tại sao những phân bổ đó lại quan trọng. Hãy đặt phần giải thích sản phẩm lên trước, sau đó kết nối mỗi chức năng token với một phần thực tế của hệ thống.

Coi đây là một lộ trình, không phải một danh sách chương bắt buộc. Bỏ qua tài liệu không phục vụ mục đích của sách trắng và giải thích sự thiếu sót nếu người đọc có thể thấy khó hiểu. Một sơ đồ có thể làm rõ một luồng khi nó ghi nhãn ai hành động, cái gì di chuyển và người dùng có thể quan sát được gì. Giữ nó nhất quán với phần giải thích bằng văn bản. Danh sách kiểm tra launch token có thể giúp bạn kiểm tra cách sách trắng phù hợp với các tài liệu launch khác.

Nội dung nào thuộc về sách trắng và khi nào?

Bao gồm một chủ đề khi nó giúp người đọc hiểu dự án hoặc kiểm tra một tuyên bố quan trọng. Bảng dưới đây đưa ra một điểm khởi đầu thực tế; hãy điều chỉnh nó cho phù hợp với dự án và khán giả của bạn.

Bạn không cần phải dành không gian bằng nhau cho mọi chủ đề. Một người đọc kỹ thuật có thể cần một bản tường trình chi tiết hơn về các thành phần và sự phụ thuộc. Một đối tượng rộng hơn có thể cần hành trình sản phẩm và mục đích token bằng ngôn ngữ đơn giản hơn. Trong cả hai trường hợp, hãy định nghĩa các thuật ngữ chuyên ngành khi chúng xuất hiện lần đầu.

Nói rõ một tính năng là đang lên kế hoạch, chưa hoạt động, nếu nó vẫn đang được xây dựng. Nêu rõ các con số token là đã được xác định hay chỉ là đề xuất. Nếu một chi tiết nằm ngoài mục đích của sách trắng, hãy nói thẳng thay vì để người đọc phải đoán. Trang dịch vụ viết sách trắng và litepaper của chúng tôi giải thích cách hỗ trợ viết có thể giúp định hình tài liệu.

Người đọc có thể kiểm tra từng tuyên bố quan trọng không?

Người đọc có thể đánh giá một sách trắng dễ dàng hơn khi các tuyên bố quan trọng của nó có trạng thái và nguồn rõ ràng. Trong quá trình soạn thảo, hãy đánh dấu mỗi tuyên bố là một thông tin hiện tại, một ý định thiết kế, một giả định hoặc một kế hoạch. Sự phân biệt đơn giản đó giúp nhóm tránh trình bày công việc tương lai như thứ mà mọi người đã có thể sử dụng.

Giữ một danh sách tuyên bố đang làm việc bên cạnh bản nháp. Đối với mỗi điểm, ghi chú cách diễn đạt, trạng thái, nguồn và người có thể xác nhận nó. Một tuyên bố về tính năng sản phẩm có thể chỉ đến một bản demo hoặc tài liệu sản phẩm. Một tuyên bố về hành vi hệ thống nên được chuyển đến chủ sở hữu kỹ thuật. Một mô tả token nên được kiểm tra dựa trên thông tin đã được phê duyệt hiện tại của nhóm.

Sử dụng cùng tên và thuật ngữ trong sơ đồ, bảng biểu và văn bản chính. Nếu một tuyên bố quan trọng không có nguồn, hãy hỏi liệu nhóm có thể hỗ trợ nó theo cách khác không. Nếu nó không cần thiết, hãy loại bỏ nó. Nếu nó vẫn chưa chắc chắn, hãy mô tả sự không chắc chắn và nguyên nhân của nó bằng ngôn ngữ đơn giản.

Để kiểm tra lần hai, hãy nhờ một người bên ngoài nhóm viết giải thích dự án sau khi đọc bản tóm tắt. Chú ý nơi họ dừng lại hoặc đưa ra một bản tường trình khác. Những khoảnh khắc đó cho thấy nơi sách trắng cần một lời giải thích rõ ràng hơn, không chỉ là cách diễn đạt mượt mà hơn.

Những lỗi soạn thảo nhỏ để lại câu hỏi lớn

Những vấn đề khó phát hiện nhất thường là khoảng trống giữa các phần. Một đánh giá cuối cùng nên tìm kiếm mâu thuẫn và thiếu bối cảnh, không chỉ lỗi chính tả và bố cục.

• Mục đích mơ hồ: người đọc không thể biết sản phẩm phục vụ ai hoặc nó thay đổi điều gì.
• Kế hoạch được viết như sự thật: các tính năng tương lai nghe như có sẵn hôm nay.
• Chi tiết token không có nhãn: người đọc không thể biết một con số mô tả gì hoặc nó đã được xác định chưa.
• Tuyên bố không có kiểm tra: các phát biểu về thiết kế, bảo mật hoặc hiệu suất không có nguồn được nêu tên.

Hãy thử một lần đọc đơn giản. Nhờ một người mới với dự án giải thích những gì đang hoạt động, những gì đã lên kế hoạch và token phù hợp như thế nào. Sau đó so sánh bản tường trình của họ với giải thích dự định của nhóm. Sửa đoạn gây nhầm lẫn và kiểm tra các phần liên quan cho cùng một vấn đề.

Một sách trắng có thể giải thích một dự án, nhưng nó không thể thiết lập tuân thủ pháp lý hoặc đảm bảo sự chấp nhận từ một sàn giao dịch. Những quyết định đó thuộc về các cố vấn và nền tảng liên quan, những đánh giá và yêu cầu của họ vẫn nằm ngoài tầm kiểm soát của người viết tài liệu.

Nếu bạn cần một kế hoạch viết, hãy so sánh công việc liên quan với hướng dẫn chi phí viết sách trắng trước khi quyết định hỗ trợ nào phù hợp.

Giữ sách trắng đồng bộ khi dự án thay đổi

Một sách trắng đã xuất bản vẫn hữu ích khi ai đó giữ nó đồng bộ với dự án mà người đọc có thể thấy. Chọn một chủ sở hữu có thể nhận thấy khi các tính năng sản phẩm, chi tiết token hoặc sự phụ thuộc quan trọng đã thay đổi.

Giữ một nhãn phiên bản rõ ràng và ghi lại những gì đã thay đổi mỗi lần bạn sửa đổi sách trắng. Kiểm tra lại sơ đồ, tài liệu tham khảo và các thuật ngữ đã định nghĩa cùng với văn xuôi. Nếu một phiên bản trước đó vẫn có sẵn, hãy cung cấp cho người đọc một ghi chú ngắn giúp họ hiểu những gì đã thay đổi giữa các phiên bản.

Hãy tưởng tượng nhóm cập nhật một luồng sản phẩm sau khi sách trắng được xuất bản. Chủ sở hữu có thể so sánh luồng mới với sách trắng và tìm mọi đoạn mô tả nó. Sau đó nhờ chủ sở hữu kỹ thuật xác nhận văn bản thay thế. Sự kiểm tra đó làm cho việc bảo trì trở thành một phần của kế hoạch viết, không phải là một suy nghĩ sau.

Giữ cho tóm tắt trang web, tài liệu token và thông tin liên lạc launch nhất quán với bản tường trình của sách trắng. Nếu bạn muốn có một đôi mắt thứ hai, hãy gửi bản nháp hoặc ghi chú hiện tại của bạn cho Brand Community. Bao gồm người đọc dự định và tên của những người có thể xác nhận chi tiết sản phẩm, kỹ thuật và token. Chúng tôi sẽ bắt đầu bằng cách xem xét dàn ý và xác định các câu hỏi cần giải quyết trước khi soạn thảo. Bạn có thể tìm thêm bài đọc thực tế trên Blog.

Cách hoạt động

1. Xác định người đọc và mục đíchViết ra sách trắng dành cho ai và họ nên hiểu điều gì. Đánh dấu những gì đang hoạt động, đã lên kế hoạch hoặc chưa quyết định.
2. Thu thập nguồn và chủ sở hữuThu thập ghi chú sản phẩm, tài liệu kỹ thuật và chi tiết token đã được phê duyệt. Nêu tên một người có thể xác nhận mỗi chủ đề.
3. Sắp xếp dàn ýĐặt các câu hỏi chính của người đọc theo một thứ tự rõ ràng. Giải quyết thông tin còn thiếu trước khi soạn thảo.
4. Soạn thảo và kiểm traSử dụng ngôn ngữ đơn giản và ghi nhãn các giả định. Yêu cầu các thành viên nhóm liên quan kiểm tra các tuyên bố của họ dựa trên tài liệu nguồn.
5. Chỉnh sửa và duy trìGiải quyết nhận xét, kiểm tra thuật ngữ và ghi lại phiên bản đã được phê duyệt. Chỉ định ai đó xem xét sách trắng khi chi tiết dự án thay đổi.