user-flow-mapping

ユーザーフローのマッピング

このスキルを使うと、ユーザーが製品内でタスクを完了するまでに遭遇するすべてのステップ、判断ポイント、エラー状態、成功パスをマッピングした詳細なユーザーフロー図をエージェントが作成できます。エージェントは、Mermaid の図表構文を使用して、移植性の高い3種類のフロー（タスクフロー（判断を伴わない単一路線）、ユーザーフロー（判断分岐を伴う複数の経路）、ワイヤーフロー（画面のワイヤーフレームを注釈として加えたフロー））を作成します。それぞれのフローには、コンバージョン指標、離脱リスクの高いポイント、最適化の機会に関する注釈が含まれます。

ワークフロー

1. フローの目的と範囲を定義する：マッピングする具体的なユーザーの目標（例：「購入を完了する」「パスワードをリセットする」）を特定します。開始地点への流入経路（直接リンク、ホームページのナビゲーション、メールの CTA、プッシュ通知など）を明確にします。また、図が際限なく拡大しないよう、成功の基準と範囲の境界を定めます。

2. すべてのステップと判断ポイントを特定する：画面、操作、システムの応答を順番にリストアップします。ユーザーまたはシステムが分岐する判断ポイント（例：「ユーザーはログイン済みか？」「支払いは成功したか？」）に印を付けます。エラー状態、入力検証の失敗、再試行ループも含めます。各ステップについて、ユーザーの操作（クリック、入力、スワイプ）かシステムの操作（リダイレクト、API 呼び出し、メール送信）かを記録します。

3. まず成功パスをマッピングし、次にエッジケースの経路を追加する：まず開始地点から成功までの理想的な経路を描きます。次に、ユーザーがログインしていない場合、入力検証に失敗した場合、セッションがタイムアウトした場合、支払いが拒否された場合など、代替経路を追加します。各分岐は、成功状態、エラーからの回復経路、または終了地点のいずれかで終わるようにします。

4. 指標とリスクポイントを注釈に加える：各ステップに、関連する指標（ページビュー数、クリックスルー率、フォーム完了率、離脱率など）を記載します。ユーザーが離脱しやすい、操作の負担が大きいステップ（複数項目のフォーム、アカウント作成の強制、支払いページなど）には印を付けます。それぞれのリスクポイントに対する具体的な最適化案を提示します。

5. Mermaid 図を生成する：ノードの形状を統一し、見やすい Mermaid graph TD 図を作成します。ページや画面には角丸四角形 ()、判断にはひし形 {}、操作には長方形 []、開始・終了状態には二重丸 (()) を使用します。内容がわかるラベルを付け、style ディレクティブを使って色を指定し、エラー経路を赤、成功経路を緑で強調します。

6. レビューして反復する：ユーザーと図を確認し、内容に漏れがないか検証します。すべての分岐が終了しているか、孤立したノードがないか、エッジケースを含め、フローが実際の製品の動作を正確に反映しているか確認します。

使い方

ユーザーの目標、製品のコンテキスト（ウェブアプリ、モバイルアプリ、クロスプラットフォーム）、既知の画面やステップをエージェントに伝えます。必要に応じて、分析データ（離脱率、コンバージョン率）を含めると、エージェントが図に注釈として追加できます。エージェントは、注釈付きの Mermaid 図を作成します。

例

例1：EC サイトのチェックアウトフロー

ユーザーの依頼：「EC サイトのチェックアウトフロー全体をマッピングしてください。ユーザーはログイン済みの場合とゲストの場合があります。クレジットカードと PayPal に対応しています。」

エージェントの回答：

graph TD
    START(("Start: Cart Page")) --> REVIEW["Review Cart Items"]
    REVIEW --> EMPTY{Cart empty?}
    EMPTY -- Yes --> BROWSE["Redirect to Shop Page"]
    EMPTY -- No --> AUTH{User logged in?}

    AUTH -- Yes --> SHIPPING["Enter Shipping Address"]
    AUTH -- No --> CHOICE{Guest or Sign In?}
    CHOICE -- Sign In --> LOGIN["Login Page"]
    LOGIN --> LOGIN_OK{Login successful?}
    LOGIN_OK -- Yes --> SHIPPING
    LOGIN_OK -- No --> LOGIN_ERR["Show Error, Retry"]
    LOGIN_ERR --> LOGIN
    CHOICE -- Guest --> GUEST_EMAIL["Enter Email Address"]
    GUEST_EMAIL --> SHIPPING

    SHIPPING --> VALIDATE_ADDR{Address valid?}
    VALIDATE_ADDR -- No --> ADDR_ERR["Show Validation Errors"]
    ADDR_ERR --> SHIPPING
    VALIDATE_ADDR -- Yes --> DELIVERY["Select Delivery Method"]

    DELIVERY --> PAYMENT{Payment method?}
    PAYMENT -- Credit Card --> CC["Enter Card Details"]
    CC --> CC_VALID{Card valid?}
    CC_VALID -- No --> CC_ERR["Show Card Error"]
    CC_ERR --> CC
    CC_VALID -- Yes --> PROCESS

    PAYMENT -- PayPal --> PP["Redirect to PayPal"]
    PP --> PP_OK{PayPal authorized?}
    PP_OK -- No --> PP_ERR["PayPal Cancelled"]
    PP_ERR --> PAYMENT
    PP_OK -- Yes --> PROCESS

    PROCESS["Process Payment"] --> SUCCESS{Payment successful?}
    SUCCESS -- Yes --> CONFIRM["Order Confirmation Page"]
    CONFIRM --> END(("End: Order Complete"))
    SUCCESS -- No --> DECLINE["Show Decline Message"]
    DECLINE --> PAYMENT

    style BROWSE fill:#fef3c7,stroke:#f59e0b
    style LOGIN_ERR fill:#fee2e2,stroke:#ef4444
    style ADDR_ERR fill:#fee2e2,stroke:#ef4444
    style CC_ERR fill:#fee2e2,stroke:#ef4444
    style PP_ERR fill:#fee2e2,stroke:#ef4444
    style DECLINE fill:#fee2e2,stroke:#ef4444
    style CONFIRM fill:#d1fae5,stroke:#10b981
    style END fill:#d1fae5,stroke:#10b981

指標の注釈：

• カート → 配送：およそ72％が次に進む（カートを表示した後、28％が離脱）
• 配送 → 支払い：およそ85％が次に進む（住所確認の負担は小さい）
• 支払い → 確認：およそ64％が次に進む（最も離脱率が高い。保存済みの支払い方法の導入を検討）
• ゲストとサインインの選択比率：およそ55％がゲストとしてチェックアウト（ゲストの選択肢を目立たせ、手間を減らす）

例 2：意思決定ポイントを含む SaaS オンボーディングフロー

ユーザーのリクエスト：「プロジェクト管理ツールのオンボーディングフローを図にしてください。新規ユーザーはサインアップし、メールアドレスを確認し、プランを選択して最初のプロジェクトを作成し、チームメンバーを招待します。」

エージェントの応答：

graph TD
    START(("Entry: Landing Page")) --> SIGNUP["Sign Up Form"]
    SIGNUP --> VALIDATE{Form valid?}
    VALIDATE -- No --> FORM_ERR["Show Validation Errors"]
    FORM_ERR --> SIGNUP
    VALIDATE -- Yes --> EMAIL_SENT["Verification Email Sent"]

    EMAIL_SENT --> VERIFIED{Email verified?}
    VERIFIED -- No, 24h+ --> RESEND["Resend Verification"]
    RESEND --> VERIFIED
    VERIFIED -- Yes --> PLAN{Choose Plan}

    PLAN -- Free --> FREE["Free Plan Selected"]
    PLAN -- Pro --> BILLING["Enter Billing Info"]
    BILLING --> BILLING_OK{Payment valid?}
    BILLING_OK -- No --> BILL_ERR["Show Billing Error"]
    BILL_ERR --> BILLING
    BILLING_OK -- Yes --> PRO["Pro Plan Activated"]

    FREE --> PROFILE["Complete Profile"]
    PRO --> PROFILE

    PROFILE --> CREATE["Create First Project"]
    CREATE --> INVITE{Invite team members?}
    INVITE -- Yes --> TEAM["Enter Team Emails"]
    TEAM --> INVITES_SENT["Invitations Sent"]
    INVITES_SENT --> DASHBOARD
    INVITE -- Skip --> DASHBOARD["Dashboard - Onboarding Complete"]
    DASHBOARD --> END(("End: Active User"))

    style FORM_ERR fill:#fee2e2,stroke:#ef4444
    style BILL_ERR fill:#fee2e2,stroke:#ef4444
    style RESEND fill:#fef3c7,stroke:#f59e0b
    style DASHBOARD fill:#d1fae5,stroke:#10b981
    style END fill:#d1fae5,stroke:#10b981

指標の注釈と最適化に関するメモ：

• サインアップ → メールアドレス確認：約68％が1時間以内に確認します。24時間後にリマインダーを送信します。初期の離脱を減らすため、確認前でも一部の機能を利用できるようにすることを検討してください。
• プラン選択：約80％が最初にFreeを選択します。Proへの移行率を高めるため、請求情報の入力不要で14日間のProトライアルを提供します。
• 最初のプロジェクトを作成：重要なアクティベーション手順です。ユーザーが48時間以内にプロジェクトを作成しない場合は、ガイド付きチュートリアルのメールを送信します。目標：初回セッション中のアクティベーション率60％。
• チームを招待：約35％がこの手順をスキップします。招待率を高めるため、コラボレーションの価値（例：「チームでプロジェクトを3倍速く完了」）を示します。

ベストプラクティス

• 分岐を追加する前に、必ず理想的なフローを図にする：理想的な経路から始めると、図の読みやすさを保てます。エラー状態、例外ケース、代替経路は段階的に追加します。
• ノードの形状を統一する：意思決定ポイントにはひし形、画面やページには角丸四角形、ユーザーやシステムのアクションには四角形を使用します。この視覚的なルールにより、フローをひと目で把握できます。
• すべての分岐を終端に到達させる：図のすべての経路は、成功、エラーからの回復、または明示的な終了など、定義済みの状態で終わる必要があります。孤立したノードは、プロダクトのロジックに不足があることを示します。
• 入手可能な場合は実データで注釈を付ける：各手順の離脱率、コンバージョン率、セッション時間を加えることで、フロー図を計画用の資料から最適化ツールへと変えられます。
• 1つの図につきユーザーの目標は1つにする：「サインアップ」「購入」「アカウント管理」を1つの図にまとめると、読みづらくなります。目標ごとに個別の図を作成し、共通の開始点や終了点で図をつなげます。

例外ケース

• 循環するフロー（リトライループ）：支払いの再試行、フォームの再送信、再認証によって、図に無限ループが発生することがあります。最大再試行回数の注釈（例：「最大3回試行し、その後サポートにリダイレクト」）と、再試行回数を超えた場合の終端ノードを追加します。
• 外部システムへのリダイレクト（OAuth、PayPal、3D Secure）：ユーザーがサードパーティ認証のためにプロダクトを離れる場合は、遷移を明示し、成功して戻る、キャンセルして戻る、タイムアウト／戻らない、の3つの結果を考慮します。「ユーザーが戻らない」場合の終了ノードを含めます。
• A/Bテストのバリエーション：テストグループによってフローが異なる場合は、バリエーションの分岐点に、テスト名とバリエーション識別子を付けた意思決定ノードを作成し、それぞれの経路を対応する結果まで図にします。
• 複数のセッションにまたがるフロー：パスワードリセット（メールを受信 → 数時間後にリンクをクリック）やメールアドレスの確認は、1回のセッションで完了しないことがあります。セッションの境界を明示し、再開のきっかけ（メールのリンク、プッシュ通知、再訪問）を示します。
• モバイルアプリのオフライン状態や機能低下状態：プロダクトがオフラインでも動作する場合は、フローの途中で接続が切れたときの動作（保留中のアクション、エラーメッセージ、再接続時の同期動作）を図にします。