Web3 サイト制作：プロダクト公開の瞬間に備える

Webサイトはベータ版に信頼できる正面玄関を提供する

クローズドベータ版を公開しようとしているスタジオを想像してください。固定されたメッセージがもはやプロダクトと一致していません。Webサイトは訪問者に最新の説明を提供できます。チームはリンクが正しい遷移先に繋がっているかを確認できます。

Web3プロジェクトサイトは、主要なプロダクト詳細、有用な導線、次のステップをまとめます。LPは、1つの焦点を絞ったメッセージまたはアクションに対して同じことを行います。訪問者が学ぶべきことをマッピングして、どちらが適切かを判断するお手伝いをします。そして、訪問者が何をできるようにすべきかを特定します。

ベータ版にプロダクト、ドキュメント、コミュニティに関する個別の詳細があるとします。これらのニーズには個別のページが必要かもしれません。ベータ版に短い説明と応募リンクだけが必要な場合は、LPで十分かもしれません。サイト計画をdApp開発と連携させることも可能です。また、この作業をより広範なWeb3開発の全体像に位置付けることもできます。

最初のレビューの前に、3つのものを集めてください：平易な言葉でのプロダクト概要、主要な訪問者アクション、承認済みの画像やコピー。まだ変更中の詳細にはマークを付けてください。そうすることで、確定情報と未確定の質問を分離できます。また、古いメッセージに依存した構築を防ぐことができます。

訪問者は最初のパスで何を見つけるべきか？

有用なWebサイトは、ページの目的、主要メッセージ、次のステップを簡単に見つけられるようにします。視覚的な詳細の前に、ページリストとナビゲーションを計画します。これにより、訪問者は重要な説明がどこにあるかを推測することなく情報を移動できます。

各ページに役割を与える

各ページが説明すべきことを一文で書き出すことから始めます。プロダクトページはサービスを紹介し、ドキュメントはセットアップの質問に答えます。LPは1つのオファーまたはアクションに集中できます。関連する詳細はまとめてください。複数の導線に同じ役割を与えないでください。

トークンプロジェクトの場合、アセットの役割とチームが承認する表現について合意します。その情報をトークン作成とデプロイと整合させることができます。Webサイトの説明はプロダクトの技術的機能とは別のものとして保たれます。

構造を読みやすくする

ナビゲーション、タイトル、ページコピーで一貫したプロダクト名を使用します。すべての導線に説明的なページタイトル、明確なメイン見出し、遷移先がわかるリンクを付けます。重要な説明は読みやすいページコンテンツに配置します。画像だけに依存しないでください。デスクトップだけでなくモバイル画面も考慮し、ドキュメントに専用の導線が必要かどうかを確認します。

ページごとのレビューでは、各導線を合意された目的と比較します。実装前に不足しているコンテンツを指摘します。これにより、チームに実用的なチェックポイントを提供します。変更がまだ議論しやすいうちに、訪問者導線を確認できます。

構築を軌道に乗せる4つの決定事項

明確なサイト制作は、チームがレビューできるいくつかの決定事項から始まります。実装前に訪問者導線、コンテンツ、技術的ニーズを確認します。そして、未解決の質問を作業が進む間も可視化しておきます。

1. ページ形式を選択する。 個別の情報ニーズをリストアップします。複数の異なるトピックはプロジェクトサイトに適している場合があります。1つのメッセージとアクションはLPに適している場合があります。
2. 訪問者のアクションを指定する。 主要な導線ごとに、訪問者が読むべきか、リンクをたどるべきか、フォームを送信するべきか、別のプロダクトに入るべきかを指定します。各リンクの遷移先を確認します。
3. 連携をマークする。 Webサイトに必要な接続を教えてください。セットアップ詳細を提供できる担当者を記載します。アプリケーションへのリンクは、その機能をWebサイトに組み込むこととは異なります。コントラクト作業がプロダクトの一部である場合、スマートコントラクト開発と調整できます。
4. レビュー資料を準備する。 承認済みのコピー、プロダクト画像、技術的な好み、必要な言語バージョンを共有します。フィードバックを収集する担当者を1名指名します。これにより、決定事項が明確に伝わります。

サイトがNFTコレクションを紹介し、訪問者をプロダクト体験に誘導する必要があるとします。まず、どの詳細がWebサイトに属するかを確認します。また、どの詳細がコレクション体験に属するかも明確にします。その後、NFTコレクション開発と関連導線をマッピングします。これにより、コードが書かれる前に責任範囲が明確になります。

構築内容：チームが確認できる単位で

Webサイト構築には、合意したページと機能に加えて、チームが何が準備できているかを理解するためのノートが含まれます。正確な組み合わせは、1つのキャンペーンページが必要か、より広範なプロジェクトサイトが必要かによって異なります。また、どの連携がそれらのページに含まれるかにも依存します。

チームは、プロダクトの主張、最終テキスト、ブランド素材、アカウントアクセスが必要な連携詳細を提供または承認します。これらの責任範囲は実装前に明確にします。プロダクトにTelegram体験も必要な場合、Webサイトの作業をTelegramボットとミニアプリ開発から分離するお手伝いができます。

有用な引き継ぎでは、どの導線が構築されたか、どのフローが確認されたか、チームが次に何を処理すべきかが明確になります。これらの項目をページ計画と照らし合わせてレビューしてください。視覚的な参照だけでなく、計画と比較することで、サイトが準備完了と見なされる前に、欠落した遷移先や未完了のコンテンツ決定を見つけることができます。

サイト公開前の落ち着いた最終確認

公開前に、訪問者としてWebサイトをウォークスルーしてください。ページが合意した計画と一致していることを確認します。モバイルとデスクトップで主要な導線をチェックします。すべての重要なリンクをたどり、担当者がプロダクトの表現を承認したことを確認します。

実用的な最終確認は4つの領域をカバーします：ページの目的、ナビゲーションの遷移先、モバイルレイアウト、合意したプロダクトフロー。また、タイトル、見出し、フォーム、公開連絡先詳細もレビューします。構築中にプロダクトまたはそのベータ版の詳細が変更された場合は、サイトを広く共有する前に関連ページのコピーを更新します。

検索エンジンは、ページをクロールしてインデックスするかどうかを決定します。また、それらのページが結果にどのように表示されるかも決定します。ウォレットやアプリケーションの動作は、選択した連携と訪問者の環境によって異なる場合があります。合意したページと導線を構築しレビューすることはできますが、それらの外部の決定を制御したり、特定の検索掲載を約束したりすることはできません。

開始するには、Brand Communityにプロダクト概要、希望する形式、ページリスト、連携ノートをお送りください。お持ちの内容を確認し、未決定事項を明確にします。その後、承認のための明確な計画をお返しします。直接話し合う準備ができている場合は、チームにお問い合わせください。詳細をお送りいただければ、こちらで対応します。

仕組み

1. プロダクト像を共有プロダクト概要、対象ユーザー、訪問者のアクション、既存のコピーや画像をお送りください。連携や公開の依存関係も記載してください。
2. ページを合意導線、ページの目的、機能、各コンテンツの提供者または承認者を確認します。
3. 構造をレビューページレイアウトが開発に移る前に、ナビゲーションと訪問者のアクションを一緒に確認します。
4. 構築と確認合意した作業を実装し、導線とフローをチームと一緒にレビューします。
5. サイトを引き継ぎ合意したWebサイトの作業と、納品されたページおよび次のステップに関するノートをお受け取りいただきます。