dAppを使う人から始める
dAppは、ウォレットやコントラクトの操作が現れる前に、主要なタスクを理解しやすくする必要があります。まずメンバーが何をしに来るのかをマッピングし、各ステップをアプリケーションに必要な画面とデータに結び付けます。
最初の会話はシンプルで構いません。プロダクトの対象者、できるようにしたいこと、既存のものを教えてください。ラフなスケッチやメモ数行で十分です。それらを、技術的な判断が必要な部分も含めた最初のリリースの共通認識に変えます。
例えば、NFTプロジェクトでメンバーがコレクションを探索し、その後オンチェーンアクションを行いたい場合があります。ウォレット接続が必要な部分と、誰でもアクセスできるままにすべき部分を分けることができます。新しいコントラクトも必要な場合は、スマートコントラクト開発とアプリケーション計画を調整できます。より広い技術的な全体像については、Web3開発で1つのdAppを超えたプロダクト連携をカバーしています。
3つの明確なパスで構築をマッピングする
有用なdApp計画は、アイデアをユーザータスク、統合、最初のリリース判断に通します。この3つのパスにより、開発開始前に重要な選択肢を可視化します。
- ジャーニーを記述する。 メンバーが取るべきアクションを、アプリを開いてから主要タスクを完了するまでリストアップします。インターフェースが選択肢を説明したり応答を表示したりする必要がある箇所を記録します。
- 接続を収集する。 プロダクトが連携すべきコントラクト、ウォレット、ネットワーク、既存サービスをレビューします。各画面が表示すべき情報も記録します。
- 最初のリリースを選択する。 初期構築に含める画面と統合を合意します。その他のアイデアはフォローオンリストに残し、途中で静かに作業に加わらないようにします。
チームがすでにプロダクトスケッチとコントラクトを持っているが、データビューがまだ不確かな場合を想像してください。確定部分をマークし、未解決の質問をリストアップし、実装前に回答すべきことを合意できます。別途パブリックサイトが必要な場合は、Web3ウェブサイト・ランディング開発でアプリ計画に混ぜずにカバーできます。
ウォレットとオンチェーンデータはどこで出会うべきか？
ウォレットフローとデータビューは、同じユーザータスクをサポートする必要があります。これらを一緒に計画することで、メンバーはアプリが表示する内容と接続が必要な理由を理解できます。
ウォレット手順
ウォレットアドレスやユーザー承認アクションが必要なタイミングをマッピングします。インターフェースは、未接続、接続済み、アプリに戻るという3つの基本状態を考慮する必要があります。また、アプリが次のステップをどのように説明するかも合意し、ユーザーが文脈なしでウォレットプロンプトを解釈するままにしないようにします。
使えるデータ
メンバーがオンチェーンレコードを検索・整理する必要がある場合、インデックスを検討する価値があります。まず画面が答えるべき質問から始め、その情報のソースと表示方法を特定します。単一のアカウントビューと検索可能なアクティビティ履歴では、必要なデータ作業が異なります。
例えば、コレクターが以前のアクションを確認するために戻ってくる場合、画面が必要とする情報をトレースし、既存のソースで十分か判断できます。表示したいレコードやビューの例をお持ちください。ウォレット機能自体がより広範なプロダクトである場合は、仮想通貨ウォレット開発という別の選択肢があります。
静かな瞬間もデザインに組み込む
フォロワーが少ないNFTアーティストを想像してください。ちょうど対応できる唯一の人が休暇に入ったところです。新しいメンバーがコレクションについての質問とdAppでのアクションを持ってやって来ます。次のステップをインターフェースで可視化し、プロダクトが説明のために誰かがオンラインであることに依存しないようにします。
そうした瞬間は、サポート計画だけでなくプロダクトレビューに属します。初めてのメンバーが見るもの、情報がない場合の表示、アクション後のアプリの応答を確認します。そして、どの状態を設計・テストすべきかを合意します。
構築作業の前に、以下を確認します：
- 新しいメンバーが完了すべき主要タスク。
- ウォレット接続なしで探索できる内容。
- データ読み込み中や利用不可の場合に表示されるメッセージ。
- アクション送信後にメンバーが見るもの。
このレビューにより、インターフェースは実際の使用に基づいたものになります。また、最初のリリースに含めるべきものと、さらなるフィードバックを得るまで待てるものを判断するのにも役立ちます。
納品まで作業を可視化する
良い納品は、何が構築されたか、合意したユーザーフローがどのように確認されたか、どの依存関係が残っているかを示します。実装前と納品直前の2つのレビューポイントを設けます。実装前には合意した機能を確認します。納品直前には、完成した作業を一緒に確認します。
構築中は、計画したフロントエンドの状態と統合をユーザージャーニーに照らして確認します。未解決の質問は可視化し、新しいリクエストは合意した作業を変更する前に議論します。納品時には、アプリケーションを確認し、実装ノートを共有し、チームが検討すべきフォローオンタスクを特定します。
ウォレットプロバイダー、ネットワーク、コントラクト、データサービスは当社の管理外です。それらの可用性、トランザクション処理、アップデート、互換性は変更される可能性があるため、合意したアプリの動作を検証しますが、外部システムの動作を保証するものではありません。
開始するには、プロダクトノート、インターフェース案、利用可能なコントラクト詳細、メンバーが必要とするデータの例をお送りください。Brand Communityがそれらを確認し、未解決の質問を明確にし、明確な判断ができる最初のリリース計画を形にします。
仕組み
- プロダクトの全体像を共有dAppが誰のためか、メンバーが何をする必要があるか、既存のものを教えてください。
- 接続をトレースそれらのタスクを支えるウォレット、コントラクト、ネットワーク、データ要件をレビューします。
- 最初のリリースを合意構築に含める機能と納品でカバーすべき内容を決定します。
- フローを構築・確認合意した作業を実装し、メンバージャーニーに照らしてレビューします。
- 納品を確認完成した作業を提示し、ノートを共有し、残りの依存関係を特定します。
よくある質問
最初のdAppの打ち合わせには何を持っていくべきですか？
短いプロダクト説明、主要なメンバータスク、既に構築済みのものがあればそれをお持ちください。インターフェーススケッチ、コントラクト詳細、表示したいデータの例も役立ちます。3つのユーザーアクションの簡単なリストでも、実践的な出発点になります。
既存のコントラクトに合わせてdAppインターフェースを構築しますか？
はい。既存のコントラクトに合わせてフロントエンドとウォレットフローを計画できます。利用可能なコントラクト情報を共有し、メンバーが何をする必要があるかを説明してください。接続ポイントをレビューし、不明点を記録し、最初のリリースに含める機能を合意します。
dAppにインデックスが必要かどうかはどのように判断しますか？
メンバーがアプリに答えてほしい質問から始めます。アクティビティ全体でレコードを検索、整理、表示する必要がある場合、インデックスが有用かもしれません。考えているレコードや画面の例をいくつか共有していただければ、データ要件をプロダクトにマッピングします。
誰かが接続する前にアプリは有用な情報を表示できますか？
はい、プロダクトフローが許せば可能です。ウォレットなしで探索できる情報と、接続が必要なアクションを特定します。例えば、パブリックコレクションビューは、ウォレット承認が必要なメンバーアクションとは別に計画できます。
dApp構築には通常どのくらい時間がかかりますか？
機能、既存資料、統合を確認した上でスケジュールを設定します。集中したフロントエンドフローと、複数のコントラクトやデータ接続があるアプリでは異なる計画が必要です。作業に応じたマイルストーンを合意するため、各レビューで次のステップを確認できます。
すべてのウォレットとデータ接続が常に動作することを保証できますか？
いいえ。ウォレットプロバイダー、ネットワーク、コントラクト、データサービスは可用性、処理、互換性を変更する可能性があります。選択した統合に対して合意したアプリケーション動作を構築・テストし、依存関係を文書化できます。例えば、納品時にアプリが期待する接続とチームが監視すべき内容を示せます。
プロジェクトについて教えてください
4つの簡単な質問に答えると、マネージャーが1時間以内にプラン、スケジュール、価格帯をお送りします。すべて機密情報として扱われます。
フォームを読み込んでいます…