新しい機能をリリースするたびに、必ずこの問いが生まれる。
「ユーザーに、どうやって使い方を伝えるか」
チュートリアル動画を作る？ヘルプページを用意する？それとも、UIそのものに「教える仕組み」を組み込む？
Google Stitch でウォークスルーとツールチップの設計を担当したとき、私はこの問いと正面から向き合った。「使い方を教えるUI」は、単なる説明の追加ではない。ユーザーが「わかった、やってみよう」と感じるまでの体験を設計することだった。
プロジェクト管理ツールに新しいカンバン機能を追加したとき、それがいつどのように説明されるかを設計するのが私の仕事だった。機能そのものをStitchで設計するより、「機能の使い方を教える部分」の設計の方が、ずっと難しかった。
結論から言うと——ウォークスルーとツールチップの設計で最も重要なのは「タイミング」と「文脈の一致」だ。ユーザーが実際にその機能を必要としている瞬間に、必要な情報だけを届けること。そのための設計を、Google Stitch で試行錯誤した記録を共有する。
ウォークスルーとツールチップとは何か
ウォークスルー（Walkthrough）とは、プロダクトの機能や操作方法を画面上でステップごとに案内するUIのことです。通常、特定の操作ができる要素をハイライトしながら説明テキストと「次へ」ボタンで進行します。初回起動時や新機能公開時に表示されることが多いです。
ツールチップ（Tooltip）とは、特定のUI要素にホバーまたはタップしたときに表示される小さな説明テキストのことです。アイコンの意味・ボタンの機能・フォームの入力ガイドなどを文脈に応じて伝えるために使われます。
この2つは似ているようで異なる役割を持つ：
- ウォークスルー：プロダクト全体の「オリエンテーション」。複数ステップで機能の全体像を教える。初回または新機能公開時に有効
- ツールチップ：特定の要素の「補足説明」。1つの要素に1つの情報を届ける。日常的な操作の補助として常に機能する
なぜ「教えるUI」の設計が難しいのか
ウォークスルーとツールチップの設計が難しい理由は、「教えすぎる」と邪魔になり、「教えなさすぎる」とユーザーが迷子になるという、相反する要求を満たさなければならないからだ。
ウォークスルーは、表示されたユーザーの半数以上が途中でスキップするという調査結果もある。「邪魔だから飛ばす」というユーザーと「ちゃんと読んで使えるようになりたい」というユーザーが共存する。その両方に配慮した設計が必要になる。
Stitch でウォークスルーUIを設計した体験
カンバン機能のウォークスルーを設計したとき、最初のプロンプトは「カンバン画面のチュートリアルを作って」だった。
出てきたのは、画面全体を暗くして特定の要素だけをハイライトするスポットライト型のウォークスルーだった。「タスクをドラッグして列を移動できます」という吹き出しが出ていた。
デザインとしては正しい。でも何かが引っかかった。
「これを見たとき、ユーザーは実際にドラッグしてみるだろうか？」
答えはNoだった。ウォークスルーを見ながら同時に操作するのは認知的に難しく、多くのユーザーは「読んで→閉じて→忘れる」という動きをする。
「説明する」から「体験させる」への転換
ウォークスルーの設計を見直した。方向性を変えて、「最初の1アクションを引き出す設計」にすることにした。
「カンバン画面。ウォークスルー第1ステップ：画面全体を薄いオーバーレイで覆い、最初の未着手カードだけをハイライト。吹き出しのテキストは『このカードをドラッグして「進行中」に移してみましょう』。「やってみる」ボタンのみで「次へ」ボタンなし。操作完了後に第2ステップが自動表示される設計。」
「説明して次へ」ではなく「操作させてから次へ」にすることで、ユーザーが実際に機能を体験しながらウォークスルーが進む構成になった。
実際に使ってみてわかったのは、ウォークスルーは「情報を届ける仕組み」ではなく「最初の成功体験を作る仕組み」だという視点の転換が、設計品質を上げることだった。
ツールチップの設計：「文脈の一致」を作る
ツールチップはウォークスルーと違い、ユーザーが能動的にアクセスする（または特定のタイミングで自動表示される）ものだ。
ツールチップの種類と使い分け
設計で使ったツールチップのパターンを整理する：
- ホバー型：アイコンや機能名にマウスをのせたときに表示。デスクトップUIで標準的。内容は1〜2文に絞る
- 長押し型：モバイルで要素を長押しすると表示。タップでは出ないため、誤操作のリスクが低い
- フォーカス型：フォームの入力欄にフォーカスが当たったときに表示。入力例や制約（文字数上限など）を伝えるのに有効
- コーチマーク型：特定の操作を促す「吹き出し+矢印」形式。新機能のお知らせや初回利用時の誘導に使う
Stitch でこれを設計するとき、「どの種類のツールチップか」を明示しないと汎用的なホバー型が生成されることが多かった。プロンプトに「フォーカス時に表示されるインラインヒント」や「初回利用時のコーチマーク」と種類を明示するのが重要だった。
ツールチップを「表示する条件」を設計する
ツールチップ設計で見落とされやすいのが「いつ表示し、いつ消すか」のコンディション設計だ。
- コーチマーク型は「一度見たら二度と表示しない」または「一定期間後に再表示しない」設計が必要
- エラー状態のツールチップは「エラーが解消されるまで表示し続ける」設計にする
- ホバー型は「マウスが離れたら即座に消える」か「300ms後に消える」かを決める
これらをStitchでデザインとして表現するときは、「ツールチップ表示状態」と「非表示状態」を別々のプロンプトで生成して両方を設計ドキュメントに含めることを習慣にした。
ウォークスルー・ツールチップの設計原則
設計を繰り返す中で、自分なりの原則が固まってきた。
スキップを「正しい選択肢」として設計する
ウォークスルーを途中でスキップしたユーザーを「失敗したユーザー」として扱わない設計が重要だ。スキップしても後からアクセスできる「ヘルプ」や「チュートリアルをやり直す」リンクを提供することで、スキップへの罪悪感をなくす。
Stitch でウォークスルーを設計するとき、すべてのステップに「スキップして使い始める」ボタンを目立たないが存在するサイズで入れることにした。
ツールチップのテキストは「動詞で始める」
ツールチップのテキストで最も効果的なのは「動詞で始める」形式だ。
- 「タスクを別の列に移動するためのドラッグハンドルです」→ 機能説明型（読むのが面倒）
- 「ドラッグしてタスクを移動」→ 動詞型（すぐに行動できる）
ツールチップの文字数は20〜40文字を目安にし、それ以上の説明が必要な場合は「詳しく見る」リンクでヘルプページに誘導する設計にする。
よくある失敗と対処法
- 失敗1：ウォークスルーのステップが多すぎる——7ステップ・8ステップのウォークスルーは、多くのユーザーが途中で離脱します。ウォークスルーは最大4〜5ステップに絞り、残りはヘルプページに委ねましょう。
- 失敗2：操作できない状態で説明する——オーバーレイでUIが操作できない状態で「これをクリックしてください」と説明されても、ユーザーは実際にやってみられません。可能であれば実際に操作させながら進むウォークスルーの方が記憶に残ります。
- 失敗3：ツールチップが表示され続ける——コーチマーク型のツールチップが一度見た後も毎回表示され続けると、ユーザーの邪魔になります。「一度見たら非表示にする」ためのユーザー状態管理を必ず実装設計に含めましょう。
- 失敗4：モバイルでホバー型ツールチップを使う——モバイルにはホバー状態がないため、ホバー型ツールチップはモバイルでは機能しません。モバイルでは長押し型・タップ型・インラインヒントに切り替えましょう。
- 失敗5：ウォークスルーをスキップしたユーザーへのフォローがない——スキップしたユーザーが「後から使い方を知りたくなったとき」のための場所（ヘルプページ・チュートリアル再起動ボタン）が必要です。スキップ後の画面設計も忘れずに行いましょう。
よくある質問（FAQ）
Q. Google Stitch でウォークスルーのオーバーレイ（暗転）UIを設計できますか？
A. できます。プロンプトに「画面全体に半透明のダークオーバーレイ（rgba(0,0,0,0.6)）を重ね、特定の要素だけを明るく見せるスポットライト効果。対象要素の周囲にボーダーラインまたは光るアウトライン」と指定することで、ウォークスルーのハイライト状態を生成できます。ただしオーバーレイのアニメーションはStitchでは設計できないため、実装時に追加が必要です。
Q. ツールチップの表示位置（上・下・左・右）はどう決めればいいですか？
A. 基本は「ターゲット要素の上」が一般的ですが、画面端に近い要素では画面外にはみ出す場合があります。Stitch でプロンプトに「ツールチップを要素の上側に表示。要素が画面上端から100px以内の場合は下側に表示」のように条件を書くと、両パターンを生成して確認できます。実装ではFloating UIやPopper.jsなどのライブラリで自動位置調整が可能です。
Q. 機能リリースのたびにウォークスルーを設計するのは大変です。効率化できますか？
A. コーチマーク型のシンプルなツールチップを「機能の近く」に配置するアプローチが、フルウォークスルーより設計・実装コストが低くなります。「新機能の要素に吹き出し（New）バッジ + タップで説明表示」という最小限のパターンをデザインシステムに組み込んでおくと、新機能のたびに使い回せます。
Q. ウォークスルーを「見ない」ユーザーへの対策はありますか？
A. ウォークスルーを見ないユーザーへの対策として有効なのが「空の状態（Empty State）に使い方のヒントを埋め込む」アプローチです。初回のデータが何もない状態で「最初のタスクを追加してみましょう ＋ ボタンをクリック」のような誘導テキストを表示することで、ウォークスルーなしでも使い方が伝わります。
Q. 新機能の告知バナーとウォークスルーはどう使い分ければいいですか？
A. 告知バナーは「新機能があることを知らせる」もので、ウォークスルーは「新機能の使い方を教える」ものです。まず告知バナーで認知を高め、ユーザーが新機能を触ろうとした瞬間にコーチマーク型のツールチップで使い方を教える——この2段階のアプローチが、UXを損なわずに機能習得を促す設計として有効です。
まとめ：教えるUIは「邪魔しないこと」から始まる
Google Stitch でウォークスルーとツールチップを設計してみて、「教えるUI」の本質に気づかされた。
ユーザーはプロダクトを「使いたい」のであって、「使い方を学びたい」わけではない。教えるUIが主張しすぎると、本来の目的（プロダクトを使うこと）の邪魔になる。
最良の「教えるUI」は、ユーザーが意識しないほど自然に、その人が必要としている瞬間に、必要な情報だけを届ける。
スキップを許容する設計、操作させながら教える構成、文脈に合ったタイミングでのツールチップ——それぞれが「邪魔しないで教える」という原則に従っている。
Stitch でこれを設計するプロセスは、「どう教えるか」より「いつ、何を教えるか」という問いを考え続けることだった。
次のステップ：自分のプロダクトで「ユーザーが最初に迷う場所」をユーザビリティテストやサポート問い合わせから特定し、そこだけにツールチップを追加することから始めてみましょう。
