ユーザー起点で設計するWeb3アプリ開発

役立つアプリは、たった一つの現実のユーザータスクから始まる

Web3アプリは、一つの役立つタスクを誰にでもわかりやすくするべきです。クローズドベータを開始しようとしているスタジオ、AMAの前夜を想像してください。チームはメンバーにモバイルフローを試してもらいたいと考えています。そこで、画面を選ぶ前にウォレットのステップをマッピングします。

その最初のタスクは、残高確認、DeFi機能の利用、ロイヤリティ特典の表示などです。私たちは、ユーザーが何をする必要があるのかを尋ねることから始めます。どの情報が必要か、どのアクションにウォレットやブロックチェーン接続が必要かを尋ねます。これにより、チームはローンチに必須の要素と、後回しにできるアイデアを現実的に切り分けることができます。

この作業は、新製品にも、より広範なWeb3サービスのモバイル部分にも対応できます。アプリ計画を既存のプロダクト、その技術的セットアップ、そしてそれを維持する担当者と結びつけます。ブラウザベースの体験も必要な場合は、dApp開発の作業がモバイルとWebのジャーニーを一致させるのに役立ちます。より広範なプロダクト構築については、Web3開発をご覧ください。

明確な最初のタスクは、デザインとエンジニアリングに同じ出発点を与えます。チームは、そのタスクに役立たない画面や連携に時間を投資する前に、フローをレビューできます。

あなたのプロダクトに最適なモバイル体験は？

適切なアプリ形式は、プロダクトのユーザージャーニー、プラットフォームのニーズ、および保守計画に従います。ネイティブiOS/Android開発とクロスプラットフォームアプローチのどちらを選択する前に、これらのニーズを検討します。

ネイティブアプリが適している場合

ネイティブ開発は、iOSとAndroidの体験に異なる動作やプラットフォーム固有のデザインが必要な場合に適しています。それらの違いをチームとマッピングし、各バージョンがサポートすべき内容を記録します。これにより、開発開始前に作業の全体像をより明確に把握できます。

共有開発が適している場合

クロスプラットフォーム構築は、画面と主要なアクションがほぼ共有されているプロダクトに適しています。連携、インターフェースのニーズ、将来のメンテナンス計画を一緒に確認します。決定は、フレームワークの好みではなく、チームが運用するために必要なものを反映する必要があります。

例えば、メンバーがアプリ内で特典を表示し、特定のアクションのためにウォレットを接続するロイヤリティプロダクトを想像してください。単に表示される情報と、接続が必要なアクションをマークします。プロダクトに独自のウォレット体験が必要な場合は、要件を仮想通貨ウォレット開発と比較してください。既存または新しいコントラクトの動作に注意が必要な場合は、スマートコントラクト開発が関連する作業工程になる可能性があります。

コードを書く前に決める4つの判断

開発を始める前に、プロダクトのアイデアを簡潔な計画にします。デザインとエンジニアリングの両方がその計画を利用できます。3部構成のキックオフノートで、ユーザー目標、ローンチアクション、技術的依存関係を把握します。

1. 主要なユーザージャーニーを特定する。 アプリがサポートすべき最初のタスクを特定します。次に、ユーザーがそれを完了するために必要な画面をマッピングします。
2. 接続をマッピングする。 必要なウォレット、ブロックチェーン、バックエンド、APIの作業をリストアップします。また、チームが提供できる既存のサービスや技術資料も記録します。
3. 最初のリリース機能を選択する。 ローンチ時に必須のものと、後で追加できるものをマークします。これにより、最初のビルドに集中しつつ、プロダクト全体のビジョンを見失わないようにします。
4. チェック項目に合意する。 チームが各コアフローをどのようにレビューするかを定義します。確認、待機状態、アクションが完了しなかった場合にユーザーが目にするものをチェックします。

1ページのフローマップを作成すると、これらの判断をレビューしやすくなります。プロダクトリーダーと技術リーダーが早期に詳細の抜けを発見し、インターフェース作業に明確な道筋を与えることができます。アプリが新しいトークンに依存する場合は、トークン作成とデプロイと計画を連携させ、アプリの前提条件を明確にできます。

最初の画面からリリース可能なビルドへ

ビルドでは、合意されたユーザージャーニーを実際のアプリにします。その後、提出準備の前にそれらのジャーニーをチェックします。主要な部分がどのように組み合わさるかを以下に示します。

アプリが形になるにつれて、デザインとエンジニアリングの連携を維持します。これには、プロンプト、確認、待機時間、エラーメッセージが含まれます。ユーザーは重要なアクション中にこれらの詳細に遭遇します。チームは、リリース候補を合意された動作と照らし合わせてチェックします。これは、直前のビジュアルレビューだけに頼るのではありません。

また、デベロッパーアカウントへのアクセス、プロダクトテキスト、スクリーンショット、その他のリリースインプットを誰が提供するかを明確にします。Telegramベースの機能は、スタンドアロンのモバイルアプリよりもミニアプリとして適している場合があります。そのニーズをTelegramボットとミニアプリ開発と比較してから、チームが間違った形式にコミットするのを防ぎます。

リリース計画をストアのルールに基づいて現実的に

優れたリリース計画は、最終ビルドの前に責任と未解決の質問を可視化します。開発前に仮想通貨アプリのポリシーをレビューします。そして、その早期レビューを、チームが必要とする機能、デザイン、提出作業に結びつけます。これにより、プロダクトフローについてまだ議論の余地があるうちに、全員が質問を提起する機会を得られます。

また、アプリストアのアカウントと提出に関する決定を誰が担当するかについても合意します。製品詳細を誰が提供し、誰がフォローアップを担当するかを明確にします。キックオフチェックリストでは、Brand Communityがプラットフォームターゲット、ローンチ優先順位、既存の技術資料、作業を承認できる担当者を記録します。プロジェクト中は、実装が進む前にインターフェースとコアジャーニーをチェックします。その後、同じ合意された動作に対してビルドをレビューします。

AppleとGoogleは仮想通貨アプリのポリシーを設定し、レビュー決定を行います。どちらの結果も当社がコントロールできるものではありません。合意された提出作業を準備しますが、承認を約束することはできません。

開始するには、プロダクトの概要、対象プラットフォーム、既存のデザインや技術メモを簡単に送ってください。ローンチ時に最も重要なユーザーアクションをお知らせください。それらの資料をレビューし、最初の判断を特定し、実用的なビルド計画を一緒に概説します。

仕組み

1. プロダクトノートを共有目標、対象ユーザー、プラットフォーム計画、既存のデザインや技術資料を送ってください。ローンチ時に重要なアクションを指摘してください。
2. アプリとその接続をマッピング主要なジャーニー、必要なウォレットとブロックチェーンリンク、バックエンドやAPIの作業、未解決の質問を概説します。
3. インターフェースをレビュー開発開始前に、主要な画面とインタラクションの状態を一緒に確認します。
4. コアフローを構築してテスト合意されたアプリを開発し、要件に対して主要なジャーニーと連携をテストします。
5. リリース引き継ぎを準備計画内の提出作業を整理し、各項目を誰が提供するかを明確にし、リリース後サポートについて合意します。