インタラクティブ製品ガイドの作り方

新規ユーザーがつまずくのは、ドキュメントがないからではなく、手順と製品そのもののあいだを行き来し続けなければならないからであることがよくあります。

インタラクティブ製品ガイドは、アプリケーションの中で実際の作業を進めながら学べるようにすることで、この隔たりを埋めます。このガイドでは、インタラクティブ製品ガイドとは何か、静的なユーザーガイドや動画とどう違うのか、そしてどのように計画し、構築し、測定するのかを説明します。オンボーディングツール全体の選定については、従業員オンボーディングソフトウェアのガイドをご覧ください。

インタラクティブ製品ガイドとは何ですか？

インタラクティブ製品ガイドとは、製品の中で動作し、ユーザーが各操作を完了したときにだけ次へ進む、ステップ形式の手順解説です。読み手はスクロールも再生もしません。実際のボタンをクリックし、実際の入力欄を埋め、作業をすることで前に進みます。

これが本質的な違いです。静的なユーザーガイドは、読んでから別の場所で実行するよう求めます。デモ動画は、見て覚えるよう求めます。インタラクティブガイドは、読むことと行うことを1つの動きにまとめます。手順と操作が、同じ場所で、同時に起こるのです。

覚えておく価値のある捉え直しが1つあります。目指すのは見栄えの良いガイドではありません。読み手が実際に行うことで完了できるガイドです。インタラクティブガイドの成否は、制作の完成度ではなく完了率で決まります。

インタラクティブ製品ガイドが静的なユーザーガイドと異なる点

静的なユーザーガイドとインタラクティブガイドは同じ問いに答えますが、負担をかける場所が違います。静的なガイドは読む作業を先に集中させ、ユーザーがそれを稼働中の製品へ正しく置き換えられることを前提にします。インタラクティブガイドは、この置き換えの工程そのものを取り除きます。

簡単な判断基準があります。ユーザーが文書とアプリのあいだを行き来しなければたどれないなら、それは静的なガイドです。案内がアプリの上に乗り、ユーザーの操作に反応するなら、それはインタラクティブガイドです。

それぞれの形式が適する場面

• 静的なユーザーガイド：方針の詳細や機能の全一覧のように、文脈から離れて何度も参照する資料に最適です。
• 動画による製品チュートリアル：ユーザーがまだ触れられないフローを見せる場合や、語りが必要な概念に最適です。受動的ですが「なぜ」を伝えるのに役立ちます。
• インタラクティブガイド：ユーザーが実際の複数ステップの作業を初めて行い、理解するだけでなく成功する必要がある場面に最適です。

ここではスクリーンショットや動画が敵なのではありません。受動的な対比としてあるだけです。視聴型・読解型の形式については、重複させるのではなく、分かりやすい作業手順書の書き方の専用ガイドをご覧ください。

インタラクティブガイドの一般的な種類

インタラクティブガイドにはいくつかの定番の形があり、多くのチームは結局それらを組み合わせて使います。共通しているのは、進行をユーザーが動かすという点です。

インタラクティブガイドの形式

• ガイド付き手順解説：ユーザーが各操作を完了するごとに進む一連のステップで、初回セットアップに適しています。
• ツールチップとホットスポット：特定のUI要素に紐づいた文脈的な案内で、ユーザーがそこに目を向けた瞬間にコントロールを説明します。
• チェックリスト：長めのオンボーディングを通じて進捗を追える、目に見えるタスク一覧です。中断しても続きから再開できます。
• 文脈内チュートリアル：ユーザーがある機能にたどり着いたときに起動する、作業別のフローです。案内が必要なタイミングで届きます。

ユーザーオンボーディングにおけるインタラクティブガイドの利点

中心的な利点は、関与そのものではありません。能動的な実践のほうが、受動的に見るより記憶に残りやすいということです。ユーザーが案内を受けながら一度その作業を行えば、単独で繰り返すために必要な想起の土台がすでにできています。先週の火曜日に見た動画では、それは得られません。

能動的な学習が定着を助けるというこの原則は、教育研究において十分な裏づけがあり、他のあらゆるスキルと同じく製品の定着にも当てはまります。その価値は、運用担当者が測定できる2つの場所に現れる傾向があります。より作り込んだフローを構築するチームは、同じ能動的学習の原則を補強するために、ガイドとインタラクティブな社員研修ツールを組み合わせることがよくあります。

新規ユーザーが価値に到達するまでの時間の短縮

価値到達までの時間とは、ユーザーが登録してから、求めていたものを手にするまでの隔たりです。静的なドキュメントは、読み、解釈し、そのうえで試す必要があるため、この隔たりを長くしかねません。インタラクティブガイドは、最初の試行そのものが学習になるため、この時間を縮めます。

新しく用意されたコンソールでユーザープロビジョニングを設定する、SaaSの管理者を考えてみましょう。静的なガイドでは、まず文書へ行き、コンソールへ戻り、項目名が一致しないとまた文書へ戻ることになります。インタラクティブな手順解説なら、コンソールの中でプロビジョニングを一歩ずつ進められるため、アカウントは最初の一回で正しく設定されます。彼らはガイドの後ではなく、ガイドの最中に価値へ到達します。

サポート問い合わせと解約の削減

「これはどうやるのか」という問い合わせはすべて、存在しなかったガイド、あるいはたどられなかったガイドの表れです。インタラクティブガイドは、そうした疑問を戸惑いが生じたその瞬間に受け止めるため、繰り返し発生する作業についての問い合わせ件数を下げる傾向があります。

同じ依頼を絶えず受けているカスタマーサクセスチームを考えてみましょう。顧客の多要素認証（MFA）のリセットです。これをクリック単位のインタラクティブガイドにすれば、その作業はセルフサービス化できます。顧客は製品の中で完了し、問い合わせは起票されず、CSチームは人が必要な判断の仕事に時間を使えます。早い段階でつまずくユーザーが減れば、後になっての静かな解約も減り得ますが、解約にはオンボーディングの摩擦以外にも多くの要因があります。

インタラクティブ製品ガイドとオンボーディングガイドの計画

良いインタラクティブガイドは、作る前に計画されています。落とし穴は、いきなりツールに飛び込み、見つけたクリック操作をすべて記録してしまうことです。それでは誰も最後まで進まない、肥大したガイドができあがります。目指すのはすべての機能を案内することではありません。ユーザーが残るかどうかを左右する、わずかな作業を案内することです。

3段階で計画しましょう。ユーザーにとっての成功とは何かを定義し、そこへ至る機能を洗い出し、そのうえで初めて形式とツールを選びます。

ユーザーの目標と利用段階を定める

自社の機能一覧ではなく、ユーザーの目標から始めましょう。ユーザーは「ダッシュボードを覚える」ことを望んでいるのではありません。チームを招待したい、データソースを接続したい、最初の成果物を出したいのです。そうした成果に名前を付け、初回のセッション、最初の1週間、最初の1か月という道筋の上に配置します。

段階が違えば必要なガイドも違います。初回のセッションには、1つの明確な成功にたどり着く短い手順解説が必要です。後の段階では、より深く緊急度の低い作業を重ねていけます。初日にすべてを教えようとするオンボーディングガイドは、結局何も教えられない傾向があります。速さを優先するのであれば、従業員をより早く立ち上げる方法のプレイブックでも同じ段階的な考え方を扱っています。

主要機能をガイドのステップに対応づける

目標が分かったら、それぞれに到達するための製品内の最短経路を洗い出します。多くのチームが作り込みすぎるのはここです。機能が存在することは、それを案内する理由にはなりません。

ガイドの経路を洗い出す

1. 成果を書き出す：「最初のレポートを公開する」のように、ユーザーが望む具体的な結果を書きます。
2. 最短経路をたどる：その成果に到達するために厳密に必要なクリックだけを記し、任意の寄り道は省きます。
3. あると便利なものを削る：成果を妨げないステップは取り除きます。それらは手順解説ではなく参考資料に属します。
4. ステップを並べる：残った操作を、ユーザーが実際に行う順序どおりに並べます。

適切なガイドの形式とツールを選ぶ

形式は作業に従います。一度きりのセットアップにはガイド付き手順解説が向きます。「これは何をするもの？」という小さな疑問の集まりには、ツールチップとホットスポットが向きます。複数のセッションにまたがる長い立ち上がりには、中断に耐えるチェックリストが向きます。

より難しいのは作成と保守の問題であり、多くのインタラクティブガイドが静かに古びていくのはここです。これが劣化の問題であり、次のセクションで正面から扱う価値があります。

インタラクティブな製品チュートリアルの作成

ガイドを作ること自体は、チームが難しいと身構える部分です。実際にはたいていうまくいきます。飛ばされがちなのは、ガイドを正確にするレビューの工程と、UIが変わった後も正確さを保つ保守です。

インタラクティブガイドの中心的なリスクは劣化です。製品は変わります。ボタンが移動し、項目名が変わり、ステップが追加されます。その瞬間、手作業で作られたガイドはもう存在しないものを指し示し、ユーザーは作業の途中で行き止まりに突き当たります。静かに壊れるガイドは、ガイドがない状態よりたちが悪いとも言えます。ユーザーがそれを信じていたからです。

ここでは、個々の機能よりも作成の方法が重要になります。従来のガイド作りでは、インターフェースが変わるたびに誰かが手順解説を収録し直すか書き直すことになり、だからこそ多くのライブラリが古びていきます。キャプチャファースト型のツールはこれを反転させます。実際のワークフローを一度記録すれば、UIが変わったときに一致しなくなったステップを変更検知が知らせてくれるため、作り直すのではなく再生成できます。この手法が実際にどう機能するかは、キャプチャファースト型のワークフロードキュメントのガイドをご覧ください。

明確で行動につながるステップの文章を書く

各ステップは、ユーザーが目にしているものに紐づけて、やるべきことをちょうど1つ、命令形で伝えるべきです。「設定オプションに移動する」より「左サイドバーの「設定」をクリックする」が優ります。曖昧な手順はユーザーに解釈を強い、その解釈こそがガイドから人を失わせる場所です。

ステップを書くときのルール

• 1ステップにつき1操作：2つのクリックを1つの手順にまとめてはいけません。画面が変わるたびに、それは別のステップです。
• 実際の要素名を使う：ユーザーが画面上で目にする、ボタン、タブ、入力欄のラベルをそのまま使います。
• 動詞から始める：操作を表す言葉から始め、理由より先に何をすべきかが分かるようにします。
• 結果を確認させる：操作の後に何が起こるはずかを伝え、成功したとユーザーが分かるようにします。

最後のルールは見た目以上に重要です。次に何が見えるはずかをステップが伝え、そのとおりに見えたとき、ユーザーは次のステップを信じられるようになります。

ツールチップ、ホットスポット、手順解説の設計

ツールチップとホットスポットでは、配置がすべてです。説明しているボタンを覆ってしまうツールチップは欠陥です。案内は要素の上ではなく横に配置し、ユーザーの注意がすでにそこへ向いているときに表示しましょう。

手順解説は短く保ちます。一度に数ステップを超えて続く手順解説は、成果にたどり着く前に人を失う危険があります。どうしても多くのステップが必要な作業なら、長い強行軍にするのではなく、ユーザーが中断して再開できるチェックリストに分けましょう。

チュートリアルのテストと改善

ガイドは、作り終えたときに完成するのではありません。それを見たことのない人が、たどるだけで作業を完了できたときに完成します。前提知識なしの試行を行いましょう。チーム外の人にガイドを渡し、どこで迷うかを観察します。

迷いはすべて、ユーザーではなくガイドの欠陥を指しています。テストした人を責めるのではなく、そのステップを直しましょう。そして意味のあるUIの変更があるたびに再度テストします。前四半期に機能していたガイドが、移動したボタンを指し示しているかもしれないからです。

ガイドの利用状況と効果を測る

測定していないガイドは改善できません。ただし、測るべきものを測りましょう。表示回数が多く完了率が低いガイドは成功ではありません。それは流入の多い失敗です。完了を伴わない網羅は、ガイドの体裁にすぎません。

答える価値のある問いは2つです。ユーザーはガイドを最後まで進んでいるか。そしてその後、実際の作業に成功しているか。それ以外はすべて副次的です。

主要指標：完了率、離脱、定着

ガイドが機能しているかを示す指標

• 完了率：ガイドを開始し、最後のステップに到達したユーザーの割合。完了率が低い場合、ガイドが長すぎるか、どこかのステップが壊れていることが多いです。
• 離脱地点：ユーザーがガイドをやめる具体的なステップ。1か所に離脱が集まっていれば、それは的確な修正の指示です。
• 機能の定着：ガイドを完了したユーザーが、その後もその機能を使い続けているかどうか。ガイドが機能した何よりの証拠です。
• 完了までの時間：案内された作業にかかる時間。ユーザーが足踏みするステップを見つけるのに役立ちます。

分析データでガイドを最適化する

分析データは、漠然とした不満を具体的な修正に変えます。ステップ4での離脱の急増は謎ではありません。書き直すべきステップか、移動したUI要素を指しています。数字を読み、該当するステップだけを直し、再テストしましょう。

ループは単純です。公開し、離脱データを見て、最も悪いステップを直し、繰り返す。このループを回すガイドは着実に良くなっていきます。公開したまま忘れられたガイドは、完了率が下がっていることに誰かが気づくまで静かに劣化します。ドキュメント全体でこの測定と保守の作業をAIがどう変えつつあるかについては、AIによるプロセスドキュメントのユースケースとROIの概説をご覧ください。

よくある質問