Web3 UIUXデザイン：dApp、ウォレット、取引所向け

Web3 UIUXデザインの対象範囲は？

Web3 UIUXデザインは、プロダクト要件をテスト済みのインターフェース計画と本番対応のFigmaファイルに変換します。

最も重要なユーザーアクション（ウォレット接続、トランザクション実行、資産管理、その他の主要タスク）から始めます。そのアクションをもとに、最初のデザインサイクルで解決すべき内容を定義します。リサーチと競合レビューは、一般的なパターンや混乱ポイントの特定に役立ちますが、権限、カストディ、対応ネットワークに関するプロダクト上の判断を代替するものではありません。

スコープは、特定のフローに絞ることも、より広範なインターフェースシステムとすることも可能です。有用なブリーフには、プロダクト名、ターゲットユーザー、対応プラットフォーム、既存のデザインファイル、ユーザーが完了すべきタスクを記載してください。関連するブランドおよびビジュアルワークについては、デザインとビジュアルおよび仮想通貨プロジェクトのブランディングをご参照ください。インターフェースを公開プロダクトメッセージと整合させる必要がある場合は、Web3コピーライティングが同じユーザージャーニーをサポートできます。

ウォレットとトランザクションフローはどのように設計しますか？

各フローは、ユーザーの判断、プロダクトの応答、そして次の明確なアクションを中心に設計します。

1. ジャーニーをマッピングする。 エントリーポイント、前提条件、判断ポイント、完了状態を記します。
2. 接続状態をカバーする。 接続前、接続中、接続後、再試行が必要な場合のインターフェースを示します。
3. トランザクションフィードバックを指定する。 保留中、確認済み、拒否、失敗の各状態を、関連するガス代とエラーメッセージを含めて設計します。
4. オンボーディングを確認する。 ユーザーの判断に影響を与える箇所で、馴染みのない用語やアクションを説明します。

これらの状態が重要なのは、ウォレットプロンプトやトランザクションによって、ユーザーがプロダクトインターフェースとウォレットインターフェースの間を行き来する可能性があるからです。デザインは、プロダクトで何が起きているか、ユーザーに何が期待されているか、アクションが完了しなかった場合に何ができるかをユーザーに伝える必要があります。この動作をフローとプロトタイプに文書化し、ハッピーパスのみをプロダクト全体として扱わないようにします。

キックオフ時には、既存のプロダクト要件、スクリーンショットまたはステージングビルドへのアクセス、およびチームによる対応ウォレットアクションの説明を提供してください。未解決の質問はLaunch Specに記録し、ビジュアル詳細の変更コストが高くなる前にプロダクトチームとエンジニアリングチームが解決できるようにします。これは、複数のネットワーク、アカウント状態、またはオンボーディングルートを含むプロダクトで特に有用です。

含まれるFigmaデリバラブルは？

デリバラブルにより、合意されたユーザージャーニーをレビュー可能にし、プロダクトチームが使用できる状態にします。

インターフェースは、プロジェクトの既存のプロダクト上の判断とビジュアルディレクションを基に構築します。これらがまだ定義中の場合は、ブリーフで変更を承認する担当者と、未決定の判断事項を特定してください。これにより、デザイン探索の焦点が定まり、プロトタイプがエンジニアリングで承認されていないプロダクト動作を暗示することを防ぎます。

ハンドオフでは、開発者が現在のバージョンを推測することなく、関連する画面、状態、コンポーネントを見つけられるようにします。Spec Reviewでは、Figma構造をウォークスルーし、合意された画面と状態が存在することを確認し、最終的な修正を収集します。プロダクト内インターフェースではなくランディングページが必要な場合は、ランディングデザインを、モーションアセットについてはアニメーションをご覧ください。

レビューとハンドオフの流れは？

プロジェクトは、確定したブリーフからフロー、インターフェースデザイン、プロトタイプレビュー、開発者ハンドオフへと進みます。

スケジュールは、画面数、フローの複雑さ、プロダクト上の判断の可用性、レビュアーの応答速度を把握した上で設定します。焦点を絞ったフローは、未解決のウォレットやトランザクション動作を抱えるマルチロールプロダクトよりも、依存関係が少なくレビューを進められます。作業開始前にマイルストーンとフィードバック期間を確認し、スコープ変更は黙ってデリバラブルを拡大するのではなく、承認を得るためにフラグを立てます。

Run Logは、決定事項、提出されたフィードバック、現在の作業段階を記録し、クライアントチームに簡潔なプロジェクト記録を提供します。レビューを実効的にするため、コメントを統括する担当者を1名指名し、各項目を欠陥、ユーザビリティ上の懸念、または好みとしてラベル付けしてください。プロダクトブリーフ、現在のFigmaまたはスクリーンショット、および主要なユーザータスクをAEOTechにお送りください。それらのインプットをもとに、スコープとレビューシーケンスを提案します。

Web3 UI承認前にチームが確認すべきことは？

デザインハンドオフの準備が整うのは、画面、主要な状態、未解決のプロダクト上の判断がデザインとエンジニアリングの両方から見える状態になったときです。

• ウォレット接続と切断の状態が表現されていることを確認する。
• トランザクションフィードバックが保留中、成功、拒否、失敗をカバーしていることを確認する。
• ガス代とエラーメッセージをプロダクトまたはエンジニアリングの担当者と確認する。
• オンボーディングの文言をプロダクトに詳しくない人とレビューする。
• コンポーネント名と画面構成がチームの実装ワークフローと一致していることを確認する。

プロトタイプは開発前に不明瞭なステップを明らかにできますが、コントラクトの動作を検証したり、技術レビューの代わりにはなりません。エンジニアリングチームに、プロダクトが実際に検出・表示できるトランザクション結果とエラー詳細を確認してください。プロダクトオーナーには、ラベル、権限、ネットワーク選択が現在のプロダクトルールと一致していることを確認してもらいます。これらのルールの変更はフローや画面の更新を必要とする可能性があるため、スコープ上の判断として記録してください。

ウォレットプロバイダーは独自のプロンプトとトランザクションインターフェースを制御しており、ネットワークはプロダクトが解釈すべき結果を返す可能性があります。当社のFigma作業は、これらの外部画面を制御したり、トランザクションの成功を保証したりすることはできません。当社は合意されたインターフェースファイルと文書化された状態を納品しますが、ウォレットやネットワークの動作を変更するものではありません。主要なジャーニーと既存のプロダクト制約をお送りいただければ、お客様のWeb3 UIUXプロジェクト向けのスコープ提案を返送します。

料金

開始価格はUSD表示です。カスタムバンドルやボリュームディスカウントはご相談ください。USDT、USDC、BTC、ETH、SOL、TON、またはプロジェクトトークンでのお支払いが可能です。

仕組み

1. ブリーフを共有プロダクトタイプ、主要なユーザータスク、既存のデザインファイル、主要な制約をお送りください。
2. スコープを確定プロジェクトに必要な画面、状態、レビュー担当者、ハンドオフを定義します。
3. UX構造を承認詳細なビジュアルデザイン開始前に、ユーザーフローとワイヤーフレームをレビューします。
4. プロトタイプをレビューFigmaで合意されたジャーニーをテストし、統合されたフィードバックを返送します。
5. ハンドオフを受け取る整理されたFigmaファイル、再利用可能なコンポーネント、実装ノートを受け取ります。