interactive-product-tour

インタラクティブな製品ツアー

シニアプロダクトマーケティングディレクターが、製品の機能を摩擦なく伝えるインプロダクトツアー、ツールチップ、コンテキストヘルプを設計するためのプレイブックです。トリガーのロジック、ツアーの構成、コンテキストに応じた配置、完了状況の追跡を扱います。必要なタイミングで表示され、不要なときには消えるヘルプシステムを構築するための手法です。

製品ツアーの大半は、次の2つのうちどちらかの理由で失敗します。すべてのボタン、リンク、機能に「ツアーを見るにはクリック」といったヒントを付け、視覚的なノイズが大きくなりすぎて、ユーザーがドットを見ても気づかなくなるケースです。あるいは、初回ログイン時に一度だけツアーを表示し、ユーザーがそれをスキップするか流し見したあと、実際に操作でつまずいたときには同じヘルプが二度と表示されないケースです。必要なときに見えないヘルプは、存在しないのと同じです。

効果のあるツアーは、これとは違う方法を取ります。常時表示するのではなく、ユーザーが操作でつまずいたタイミングで表示します。ユーザーがまだ使ったことのないセクションに入ったとき、設定が必要な機能をクリックしたとき、または長い間利用していなかったユーザーが戻ってきたときに、コンテキストに応じたヒントを表示します。システムはユーザーが何を理解しているかを把握し、適切なタイミングでヘルプを表示します。

このスキルの語り手は、ツアーを再設計して機能の利用率が2倍になる様子も、あらゆる画面にツールチップを追加して利用率が急落する様子も見てきたシニアプロダクトマーケティングディレクターです。有用なヘルプと視覚的なノイズを分けるトリガーのロジックについて実践的で、明確な意見を持ち、インプロダクトツアーを一切用意しないのが正解の場合は、そのことを率直に指摘します。

このスキルを使う場面：初めてインプロダクトヘルプシステムの範囲を決めるとき、利用促進の成果は見られないのにエンゲージメント指標だけを生み出すツアーシステムを監査するとき、ヘルプをいつ表示するか決めるトリガーのロジックを設計するとき、ツアーが必要な機能とドキュメントで対応する機能を判断するとき。

---

このスキルの対象範囲

このスキルでは、インプロダクトツアー、ツールチップ、コンテキストヘルプを扱います。グロース関連ツールにおける区分は次のとおりです。

• onboarding-wizard-design は、初回利用時の順を追った体験を扱います。このスキルは、ライフサイクル全体を通じて製品内で表示するコンテキストヘルプを扱います。
• chatbot-flow-design は、会話形式のヘルプを扱います。このスキルは、会話形式ではないツアーやツールチップによるヘルプを扱います。
• **interactive-product-tour（このスキル）**は、トリガーのロジック、ツアーの構成、コンテキストに応じた配置、完了状況の追跡、必要になるまで表示しないための手法を扱います。
• discovery-research-synthesis は、ツアーの内容に役立つ調査を扱います。これは入力情報であり、このスキルの一部ではありません。
• pm-spec-writing は、ツアーを構築するエンジニア向けの仕様書を扱います。このスキルでは何を構築するかを扱い、pm-spec-writing ではそれをどう伝えるかを扱います。

対象読者：プロダクトマーケター、グロースマーケター、社内のプロダクトチーム、SaaS クライアントのアクティベーション施策を担当する代理店。

対象外：初回利用時のウィザード（onboarding-wizard-design の対象）、会話形式のヘルプ（chatbot-flow-design の対象）、エンジニアリング実装、Userpilot／Pendo／Appcues の具体的なプラットフォーム設定（これらは実装側の範囲です）。

---

ツアーを導入すべきか：投資に見合う場合とドキュメントで十分な場合

ツアーシステムを設計する前に、ツアーが適切な手段かどうかを判断します。

ツアーへの投資に見合う場合：

• ユーザーが案内なしでは本当に見落としてしまう機能がある場合です。メニューの奥に埋もれた具体的な機能、手順を踏む必要がある高度なワークフロー、ユーザーが存在を知らないインテグレーションなどが該当します。
• ユーザーにとって、文脈から切り離されたドキュメントよりも、利用中の画面でのガイダンスが有益な場合です。ツアーはユーザーが機能を使う場所で使い方を伝えますが、ドキュメントでは別の画面に切り替える必要があります。
• プロダクトの進化に合わせて、チームがツアーをメンテナンスできる場合です。ツアーの内容は古くなります。メンテナンスする約束がなければ、ツアーが廃止済みの UI を案内することになります。
• 成功指標が定義されている場合です。機能の利用率、特定の機能で価値を得るまでの時間、ツアーで扱う機能に関するサポートチケットの削減などが該当します。

ツアーへの投資に見合わない場合：

• プロダクトの機能が少なく、ドキュメントで十分な場合です。主要な機能にツールチップをいくつか用意するだけで十分かもしれません。
• ユーザーが自分で機能を見つけることを好む場合です。画面内のガイダンスを煩わしく感じ、自由に探索したいユーザーもいます。
• プロダクトの変更に合わせて、チームがツアーをメンテナンスできない場合です。古くなったツアーは、ツアーがないよりも悪い結果を招きます。
• プロダクトが頻繁に変更される場合です。プロダクトの変更が速いと、ツアーのメンテナンスにかかるコストが、ツアーの価値を上回ることがあります。

判断すべきなのは「ツアーシステムを導入すべきか」ではなく、「このプロダクトとユーザーにとって、プロダクト内ツアーは適切な手段か」です。

詳細はreferences/tour-decision-criteria.mdをご覧ください。

---

ツールチップの乱立 vs 一度きりのツアー vs 必要なときのコンテキストに応じた案内

この考え方が要となります。

ツールチップの乱立。 すべてのボタン、リンク、機能に「クリックしてツアーを表示」というヒントや点滅するドットがあります。視覚的なノイズが生まれ、ユーザーはドットに反応しなくなります。その結果、ツアーシステムは学習の手段として機能しなくなります。コスト：デザインにかけた労力が、ユーザーに認識されないヘルプを生み、視覚的な煩雑さがプロダクト全体の質を損ないます。

一度きりのツアー。 初回ログイン時にツアーを一度だけ表示します。ユーザーはスキップするか、流し読みします。実際に困ったときに、同じツアーが再び表示されることはありません。コスト：必要なときに表示されないヘルプは役に立ちません。機能の利用率は低いままで、ツアーで説明した機能に関するサポートチケットも減りません。

必要なときのコンテキストに応じた案内。 ユーザーが困ったときにツアーやツールチップを表示します（未探索のセクションに移動したとき、セットアップが必要な機能を開いたとき、長い不在の後に戻ってきたとき、フィーチャーフラグを初めて有効にしたときなど）。システムはユーザーが知っていることを把握し、適切なタイミングでヘルプを提示します。コスト：トリガーロジックの構築には相応の作業が必要ですが、その見返りとして、機能の利用促進につながるヘルプを継続的に提供できます。

判断の基準は、ユーザーが初めて機能に触れる様子を観察することです。その瞬間にヘルプシステムが役立つ案内を表示しますか。それとも、ユーザーがとうに忘れてしまった初回ログイン時に案内を表示しましたか。前者なら、必要なときのコンテキストに応じた案内です。後者なら、一度きりのツアーです。ページ全体に散らばった14個のツールチップのドットとヘルプが競合しているなら、ツールチップの乱立です。

---

トリガーロジック：イベントベース、時間ベース、状態ベース

ヘルプを表示するタイミングを決める仕組みです。

イベントベースのトリガー。 ユーザーの操作に応じてヘルプが表示されます。機能を初めてクリックしたとき、新しいセクションに移動したとき、フローを完了したときなどです。

使用する場面。ほとんどのコンテキストヘルプでのデフォルトです。ユーザーが何かをすると、それに応じてヘルプを表示します。

時間ベースのトリガー。 一定時間が経過するとヘルプが表示されます。30日間利用していなかったユーザーが製品に戻ってきたとき、何も操作せずにこのページに60秒間滞在したときなどです。

使用する場面。時間の経過がニーズの兆候になる場合（長期間の不在、ページ上での行き詰まりなど）に使用します。時間だけではシグナルの精度が低いため、控えめに使用してください。

状態ベースのトリガー。 ユーザーの状態に基づいてヘルプが表示されます。新規ユーザーかパワーユーザーか、アカウントの規模、機能の利用履歴などです。

使用する場面。ユーザーセグメントによってヘルプの内容が異なる場合に使用します。状態ベースのトリガーによってヘルプをパーソナライズできます。

組み合わせトリガー。 本番環境で使用されるツアーシステムの多くは、この3つすべてを組み合わせています。イベントを起点とし、時間と状態に応じて頻度やコンテンツを調整します。

原則。トリガーは「このヘルプはいつ、なぜ表示されるのか」に答えるものです。装飾的なトリガー（必要のないときにヘルプを表示すること）は、ツールチップの乱用につながります。

詳細は、references/trigger-logic-patterns.mdをご覧ください。

---

ツアーアーキテクチャ：単一ツアー、分岐型ツアー、マイクロツアーのライブラリ

ヘルプの構成方法です。

単一ツアー。 製品全体を説明する、1つの直線的なツアーです。シンプルですが柔軟性に欠け、ユーザーの実際の探索方法に合うことはほとんどありません。

分岐型ツアー。 ユーザーの選択や製品内での経路に応じて内容が変わるツアーです。関連性は高まりますが、複雑になります。

マイクロツアーのライブラリ。 それぞれ特定の機能やワークフローに紐づいた、小規模で焦点を絞ったツアーを多数用意します。状況に応じて表示します。最も柔軟ですが、メンテナンスの負担も最大です。

選択の指針。 現代のシステムの多くは、マイクロツアーのライブラリを採用しています。単一ツアーは定型的に感じられ、分岐型ツアーは規模が大きくなるとメンテナンスが困難になります。コンテキストに応じたマイクロツアーのライブラリは、ユーザーの実際の探索方法に合っています。

詳細は、references/tour-architecture-patterns.mdをご覧ください。

---

コンテキストに応じた配置：ヘルプの表示場所と閉じ方

ヘルプの視覚的なデザインです。

配置パターン。

• ホバー時のツールチップ。 ホバーすると、要素の横にヘルプが表示されます。軽量で、なじみやすい方法です。
• スポットライトオーバーレイ。 要素を強調表示し、その横にヘルプを表示します。目立ちやすい一方で、より作業を妨げます。
• サイドバー。 サイドパネルにヘルプが表示されます。ユーザーが作業している間、表示を維持できます。
• インライン。 ページのフロー内にヘルプが表示されます。作業を妨げにくい一方で、閉じにくくなります。

閉じる仕組み。

• Xをクリック。 標準的な閉じ方です。常に利用できるようにします。
• 外側をクリック。 ユーザーがほかの場所を操作すると、ヘルプが閉じます。モーダルではないヘルプであることを示します。
• 自動的に閉じる。 数秒後にヘルプがフェードアウトします。ユーザーが読み終わる前に消えるおそれがあるため、注意が必要です。
• 操作されるまで表示を維持。 ユーザーが提案された操作を行うまで、ヘルプが表示され続けます。ガイド付きフローでは効果的ですが、それ以外では煩わしくなります。

邪魔をしない原則。 ヘルプは、必要なときに見つけられ、不要なときには無視できるものであるべきです。画面を塞ぐモーダルヘルプは作業を妨げ、簡単に消えすぎるヘルプでは学習につながりません。

詳細は、references/contextual-placement-patterns.mdおよびreferences/dismissal-and-non-intrusion-patterns.mdをご覧ください。

---

完了状況の追跡と再表示ロジック

各ユーザーが何を見たかを把握し、いつ再表示するかを判断します。

ユーザーごとの状態追跡。

• ユーザーが完了したツアーはどれですか？
• ユーザーが閉じたツアーはどれですか？
• ユーザーが見たものの完了していないツアーはどれですか？
• 前回の操作からの経過時間。

再表示ロジック。

• 完了したツアー：通常は再表示しません。
• 閉じたツアー：閉じた操作を尊重し、機能が再び関連するようになった場合は、十分な時間が経過した後に再表示することを検討します。
• スキップされたツアー：関連するタイミングで再表示します。
• 長期間利用していなかったユーザー：簡潔なヘルプで再案内します。

過剰な表示の落とし穴。 完了済みのツアーをユーザーに何度も表示すると、信頼が損なわれ、ユーザーはツアーを無効にします。

表示不足の落とし穴。 ユーザーが同じ問題に再び直面しても、ツアーが再表示されません。必要なときにヘルプを提供できません。

詳細はreferences/completion-tracking-and-re-trigger.mdをご覧ください。

---

パワーユーザーと新規ユーザーの区別

ユーザーによって必要なヘルプは異なります。

原則。 パワーユーザーは、すでに使いこなしている機能のツアーを望みません。新規ユーザーには、初めて使う機能のツアーが必要です。ヘルプシステムは両者を区別できる必要があります。

区別の手がかり。

• 機能の利用履歴（ユーザーは以前にこの機能を使ったことがありますか？）。
• 利用期間（ユーザーはどのくらいの期間この製品を利用していますか？）。
• 利用頻度（日常的に利用しているか、月に一度戻ってくるか）。
• 自己申告によるスキルレベル（まれで、通常は推測します）。

区別のパターン。

• パワーユーザーには、新しい機能についてのみヘルプを表示します。
• 新規ユーザーには、探索の段階に合った機能のヘルプを表示します。
• 再訪ユーザーには、前回のセッションから長期間経過している場合、再案内のヘルプを表示します。

過剰なヘルプの落とし穴。 使いこなしている機能についてパワーユーザーを支援すると、信頼が損なわれます。

ヘルプ不足の落とし穴。 すべてのユーザーをパワーユーザーとして扱うと、新規ユーザーが重要なヘルプを見逃します。

詳細はreferences/power-user-vs-new-user-patterns.mdをご覧ください。

---

よくある失敗パターン

簡潔にまとめています。診断についてはreferences/common-tour-failures.mdをご覧ください。

• 「ツアーは表示されるが、機能の利用率が向上しない。」ヘルプは視覚的には表示されていても、状況に関連していない可能性があります。トリガーロジックを見直してください。
• 「ユーザーがツアーを一括で無効にしている。」システムがユーザーを困らせています。表示頻度、閉じる操作、過剰な表示を見直してください。
• 「初回ログイン時のツアー完了率は80パーセントだが、機能の利用率は変わらない。」一度きりのパターンで、必要なときにツアーの内容が活用されていません。
• 「ツールチップが至る所に表示されるが、誰もクリックしない。」ツールチップの乱発です。状況に応じたトリガーに調整してください。
• 「ツアーの内容に、6か月前に廃止した機能が記載されている。」メンテナンスが行き届いていません。
• 「パワーユーザーが、すでに知っている内容のポップアップに不満を述べている。」パワーユーザーを区別できていません。
• 「ツアーはデスクトップでは動くが、モバイルでは壊れる。」ヘルプシステムのモバイル UX がテストされていません。
• 「ツアーを公開するチームもあれば、気に留めないチームもある。一貫性がない。」ツアーのガバナンスがなく、一部のチームは構築し、他のチームは無視しています。
• 「ツアーは正しく表示されたが、ユーザーが提案に従わない。」ヘルプの内容がわかりにくいか、行動喚起がありません。

---

フレームワーク：プロダクトツアー設計における12の検討事項

アプリ内ツアーシステムを設計または監査する際は、以下の12項目を確認してください。

1. ツアーを実施するかどうか。 ツアーは適切な手段ですか、それともドキュメントで十分ですか？
2. 必要なときに状況に応じて表示し、ツールチップを乱発したり一度きりにしたりしない。 ユーザーがつまずく場面でヘルプを表示します。
3. トリガーロジックが適切である。 基本はイベントベースとし、時間と状態に応じて調整します。
4. ツアーのアーキテクチャが利用方法に合っている。 ほとんどの製品では、マイクロツアーのライブラリが適しています。
5. 状況に応じた配置で、邪魔にならない。 必要なときに見つけやすく、不要なときには無視できるヘルプにします。
6. 閉じる操作が誠実である。 標準的な閉じるボタンと、外側のクリックによる閉じ方を用意し、読み終える前に自動で閉じないようにします。
7. 完了状況の追跡を計測できる。 ユーザーごとの状態と、ツアーごとのステータスを記録します。
8. 再表示のロジックが配慮されている。 完了したツアーは再表示せず、閉じたツアーについてもユーザーの判断を尊重します。
9. パワーユーザーと新規ユーザーを区別する。 ユーザーの状態に応じてヘルプを調整します。
10. モバイルでも同等に利用できる。 対象ユーザーが使うデバイスでヘルプを利用できるようにします。
11. 保守を徹底する。 製品の変更に合わせてツアーを更新し、四半期ごとに監査します。
12. 成功指標は利用の定着とする。 ツアーの完了だけでなく、機能の利用定着を重要な指標とします。

このフレームワークから導かれるのは、必要になるまで表示されず、関連性の高い場面でヘルプを提示し、機能の利用定着につなげるツアーシステムです。

---

参考ファイル

• references/tour-decision-criteria.md - ツアーを構築する価値がある場合と、ドキュメントで十分な場合。
• references/trigger-logic-patterns.md - イベントベース、時間ベース、状態ベース、複合型のトリガー。有用なトリガーとノイズを区別するための指針。
• references/tour-architecture-patterns.md - 単一ツアー、分岐型、マイクロツアーのライブラリ。ユーザーの実際の探索方法に合ったアーキテクチャ。
• references/contextual-placement-patterns.md - ツールチップ、スポットライト、サイドバー、インライン表示。配置とビジュアルデザイン。
• references/completion-tracking-and-re-trigger.md - ユーザーごとの状態、再表示のロジック、表示過多と表示不足の落とし穴。
• references/power-user-vs-new-user-patterns.md - 区別のためのシグナルとパターン。過剰なヘルプと不十分なヘルプの落とし穴。
• references/dismissal-and-non-intrusion-patterns.md - 閉じる操作。邪魔にならないことの原則。
• references/tour-anti-patterns.md - ツアーのように見えて、製品の質を損なうパターン。
• references/common-tour-failures.md - 診断と対処法を含む、9つ以上の失敗パターン。

---

まとめ：ツアーは、必要になるまで表示されないことでユーザーの注意を引きつけます

複利的な資産として機能するツアーシステムとは、ユーザーがツアーシステムの存在を意識しないものです。困ったときにヘルプを表示し、困りごとが解消したら消え、視覚的なノイズとして積み重なることはありません。ユーザーは機能を初めて使うときに短いコンテキストヒントを目にし、提案された操作を行って、先に進みます。システムは役目を果たし、ユーザーはシステムについて考える必要がありません。

目指すべき水準はここです。これを下回るのが、ツールチップの乱発（ユーザーが次第に見過ごすようになる視覚的なノイズ）と、一度きりのヘルプ（必要なときに見つからないヘルプ）です。これを上回るのが、トリガーのロジック、ツアーのアーキテクチャ、コンテキストに応じた配置、再表示への配慮が連携し、ヘルプが押しつけられたものではなく、自然に存在するように感じられる、必要なときに表示されるシステムです。

大切なのは、設計上の選択です。ツアーシステムを構築するか、ドキュメントに頼るかという判断。ヘルプをいつ表示するかを決めるトリガーのロジック。機能やワークフローごとにマイクロツアーを整理するアーキテクチャ。ヘルプを邪魔にならないものにする配置と終了方法。ユーザーがすでに知っている内容の再表示を防ぐ完了状況の追跡。専門知識に配慮するパワーユーザー向けの差別化。ツアーを製品と同期させ続けるメンテナンスの頻度。