ユーザー起点で設計する仮想通貨ウォレット開発計画

メンバーが使いたいウォレットから始める

優れたウォレット計画は、製品の明確な役割から始まります。誰が使うのか、何をする必要があるのか、どこで使うのかを検討します。これらの選択が、設計が進みすぎる前にカストディ、プラットフォーム、統合の判断を導きます。

最初のリリースですべての形式を揃える必要はありません。主要なメンバージャーニーを選び、必要なネットワーク、アセット、アクションを特定します。ウォレットがより広範な製品の一部である場合は、関連する範囲についてWeb3開発をご覧ください。

既存のdAppをサポートするウォレットは、接続と署名フローに焦点を当てる必要があるかもしれません。スタンドアロン製品の場合は、オンボーディング、復元ガイダンス、サポートツールも必要になることがあります。MVPからプロダクションに向けて構築することも、自社チームと並行して特定の部分を担当することも可能です。

画面が増える前に重要な選択を行う

小さな取引所のパートナーシップチームがAMAの前夜に、ウォレット体験を見せたいと考えているとします。しかし、誰がアクセスを管理するのか、デモにどの操作を含めるのかがまだ決まっていません。私たちはまずそれらの判断をマッピングし、チームが明確に説明できるシンプルなジャーニーを合意します。

このような初期の会話は、製品の表現を正直に保ちます。ノンカストディアルウォレットは、ユーザーが何を管理し、どのようにアクセスを復元できるかを説明する必要があります。カストディアルウォレットは、サービスの責任とサポートの範囲を明確に示す必要があります。モデルがまだ未確定の場合は、決まったかのように設計するのではなく、その疑問を記録します。

カストディの図、重要なユーザーパス、想定される障害状態を製品担当者とレビューします。その後、決定事項と未解決の質問を共有記録に残します。既存の製品ノート、ラフな画面、動作するコードがあれば、それらを持ち込むことができます。洗練されている必要はありません。ウォレットがコントラクトの動作に依存する場合は、受け入れ基準を設定する前に、スマートコントラクト開発とそれらの選択を調整します。

最初のリリースでサポートすべきウォレットジャーニーは？

最初のリリースでは、少数の重要なウォレットジャーニーを簡単に実行できるようにする必要があります。メンバーが完了するために来たアクションから始め、その前後に何を理解する必要があるかを決定します。

画面だけでなくアクションをマッピングする

送金フローの場合、ユーザーがアセット、送信先、金額をどのように識別するかを合意します。署名アクションとトランザクションステータスを明確にします。スワップの場合、ユーザーが確認する情報と、トランザクションが進められない場合にインターフェースが何を表示するかを決定します。マルチチェーン対応の場合、ネットワークをリストアップし、ユーザーがどのネットワークとアセットを操作しているかをどのように確認できるかを示します。

瞬間に合った表面を選ぶ

ブラウザ拡張機能はデスクトップファーストの製品に適しています。モバイルアプリは専用のスマホジャーニーをサポートできます。その製品作業についてはモバイルアプリ開発をご覧ください。Telegramミニアプリは、Telegram体験内にウォレット操作を配置できます。各表面には独自の設計、実装、検証作業があります。機能リストではなく、実際のメンバータスクに基づいて最初の表面を選ぶお手伝いをします。

メンバーがスマホでアセットを確認し、その後Telegramミニアプリを開いて続ける場合を想像してください。体験がどこで変わるか、どの情報を明確に保つ必要があるかをマッピングします。Telegramでの納品については、Telegramボットとミニアプリ開発をご覧ください。

そのマップを使用して、引き継ぎを明確にし、メンバーの次のアクションを理解しやすくすることができます。また、最初のリリースにどの表面を含めるかを決定するための具体的な道筋をチームに提供します。

各ウォレットの決定にビルド内の位置を与える

ウォレットプロジェクトは、実装前に製品の質問を解決しておくと追跡しやすくなります。3部構成のチェックインリズムを使用します。決定事項を明確にし、フローが形になるにつれて作業をレビューし、合意した引き継ぎを確認します。

1. 開始時の状況を共有する。 ウォレットの対象ユーザー、主要なメンバータスク、ターゲットプラットフォーム、必要なネットワークを教えてください。既存のデザイン、コード、統合があれば含めてください。
2. カストディとアーキテクチャをレビューする。 アカウントの責任、復元、権限、トランザクションジャーニー、未解決の決定事項を製品担当者とマッピングします。
3. 完了の定義を合意する。 含まれる作業、受け入れ基準、依存関係、レビューポイントを一緒に設定します。これにより、全員が同じ完了イメージを持ちます。
4. 合意したフローを設計・構築する。 チームは選択された製品表面と技術的接続を進めます。優先ジャーニーが形になるにつれて確認します。
5. 検証して引き継ぐ。 合意した作業を受け入れ基準に対してレビューし、指定されたセキュリティ資料を準備し、運用担当を文書化します。

スケジュールは、チームが選択された表面、カストディのアプローチ、統合、レビューの必要性を理解した後に決まります。最初の週は、製品詳細の収集と未解決の質問の解決に集中できます。チームの都合に合わせます。計画を可視化し、チームがアクセス、承認、技術的連絡先を提供する必要がある場所を特定します。

ウォレットの準備状況をチームが確認できる基準で保つ

有用なウォレットの引き継ぎは、動作する画面以上のものをチームに提供します。合意した作業に応じて、製品要件、インターフェースデザイン、ウォレットコード、バックエンドまたはチェーン接続、優先フローのテストを含めることができます。技術ノートやモニタリング計画も含めることができます。ウォレットがトークンローンチに接続する場合は、トークンの作成とデプロイと調整してください。より広範な製品については、Web3開発が共有の技術的判断の特定に役立ちます。

リリース前に、主要なチェック項目を一箇所にまとめます。カストディと復元の選択が文書化されていることを確認します。ユーザーが署名前にトランザクション詳細を確認できることを確認します。統合、アクセス、アラートの担当者を割り当てます。セキュリティレビューの所見に明確な担当者と解決への道筋を割り当てます。

合意した実装を納品し、セキュリティレビューの資料を準備できます。外部監査人が所見を決定します。カストディアル製品の規制上の分類は、ローンチ前に顧問弁護士がレビューする必要があります。ネットワークの可用性とサードパーティ統合の動作も、構築チームの管理外です。

ユーザー、既知のカストディの選択、プラットフォーム、ネットワーク、優先アクションを含む簡単な概要をお送りください。製品担当者とレビューし、最初のウォレットの決定を一緒にマッピングします。

仕組み

1. 開始時の状況を共有するウォレットの対象ユーザー、主要なメンバータスク、ターゲットプラットフォーム、必要なネットワークを教えてください。既存のデザイン、コード、統合があれば含めてください。
2. カストディとアーキテクチャをレビューするアカウントの責任、復元、権限、トランザクションジャーニー、未解決の決定事項を製品担当者とマッピングします。
3. 完了の定義を合意する含まれる作業、受け入れ基準、依存関係、レビューポイントを一緒に設定します。
4. 合意したフローを設計・構築するチームは選択された製品表面と技術的接続を進め、優先ジャーニーが形になるにつれて確認します。
5. 検証して引き継ぐ合意した作業を受け入れ基準に対してレビューし、指定されたセキュリティ資料を準備し、運用担当を文書化します。