ヘルプ・ガイダンス (Help & Guidance)

「ヘルプページを見てください」——これはUIの敗北宣言です。ユーザーが操作に迷い、ヘルプを探し、別ページに飛び、読んで戻ってくる。この一連の流れは、UIが「自分で説明できなかった」ことを意味します。

よくある失敗パターンは「FAQページへの丸投げ」です。フォームの入力欄に「詳しくはFAQをご覧ください」と書いてあっても、ユーザーはその瞬間に答えが欲しいのです。別タブを開き、FAQを検索し、読んで戻ってくる——その間に集中力は途切れ、多くのユーザーは離脱します。

ヘルプ・ガイダンスが崩れたUIは、ユーザーを「自力で解決するか、諦めるか」の二択に追い込みます。それはサポートコストの増大と、コンバージョン率の低下につながります。

1. 原則の定義

ヘルプ・ガイダンス（Help & Guidance）とは、ユーザーが迷う可能性のある場面で、その場で・その瞬間に・必要最小限の情報を提供することで、操作の中断なく目的を達成させる設計原則。

本質は「ヘルプを探させないこと」です。最高のヘルプは、ユーザーが「ヘルプを見た」と気づかないほど自然に、操作の流れの中に溶け込んでいます。ツールチップ・プレースホルダー・インラインエラーメッセージ・コンテキストヒント——これらはすべて、「必要な瞬間に必要な場所で」情報を届けるガイダンスです。

2. いつ使うか（適用場面）

特に重要になるケース

• 複雑なフォーム入力: パスワードの要件、クレジットカード番号の形式、郵便番号の入力方法など、ユーザーが迷いやすい入力欄。
• 専門用語・業界用語が多い画面: 「CPC」「ROAS」「LTV」など、一般ユーザーには馴染みのない用語が並ぶ管理画面。
• 取り消しできない操作の前: 削除・公開・送信など、実行後に戻れない操作の確認画面。
• 初回利用時の機能説明: 新機能を初めて使うユーザーへの、その場でのガイダンス。

トレードオフが起きる場面

• ガイダンスの過剰表示: ツールチップやヒントが多すぎると、画面が煩雑になり、熟練ユーザーの邪魔になる。初回のみ表示・ホバー時のみ表示などの制御が必要。
• ガイダンスへの依存: ガイダンスで補完できるからといって、UIの設計自体を改善しない言い訳にしてはいけない。ガイダンスは「UIの欠陥を隠す絆創膏」ではなく「良いUIを補完するもの」。

3. なぜ重要か（設計判断の核）

ヘルプ・ガイダンスは「サポートの代替」ではなく、「UIの一部」である。

設計判断の基準

• 「このガイダンスは、ユーザーが迷う前に表示されているか？」→ 迷った後に表示されるなら、UIの設計を見直すか、ガイダンスの表示タイミングを早める。
• 「ガイダンスを読まなくても操作できるか？」→ 読まないと操作できないなら、UIの設計自体が問題。

優先順位の考え方

• 1. UIを直す（最優先）: ガイダンスが必要な箇所は、UIの設計が不十分なサイン。まずUIを改善する。
• 2. インラインガイダンス: それでも説明が必要なら、その場で・その瞬間に表示する（ツールチップ・プレースホルダー・インラインヒント）。
• 3. 外部ヘルプへの誘導（最終手段）: 詳細な説明が必要な場合のみ、ヘルプページへのリンクを添える。

例外条件

• 熟練ユーザー向けの専門ツール（IDE・DAWなど）では、ガイダンスを最小化し、ショートカットや高度な機能へのアクセスを優先する設計が適切な場合がある。

4. 具体の設計ルール（チェックリスト）

最低ライン（Must - これ守らないと危険）

これがないと、ユーザーは迷ったまま離脱します。

エラーメッセージがインラインで表示されるか: フォームのエラーは、送信後に別ページで表示するのではなく、問題のある入力欄の直下にリアルタイムで表示されているか？
入力形式のヒントが事前に示されているか: 「半角英数字8文字以上」「YYYY/MM/DD形式」など、入力前にフォーマットが明示されているか？エラーになってから初めて教えるのは遅い。
専門用語に説明が添えられているか: ユーザーが知らない可能性のある用語には、ツールチップや括弧書きで簡潔な説明が添えられているか？

理想ライン（Better - できると強い/プロの品質）

「わかる」を超えて「迷わない」状態です。

コンテキストに応じてガイダンスが変わるか: 初回利用時は詳しく、2回目以降は省略するなど、ユーザーの習熟度に応じてガイダンスの量が調整されているか？
ガイダンスを非表示にできるか: 熟練ユーザーが「もう覚えた」と感じたら、ツールチップやガイダンスを非表示にできるか？
プロアクティブなガイダンスがあるか: ユーザーが迷う前に、「次はこうすると良いですよ」と先回りして提案するガイダンスが設計されているか？

5. UI例

同じパスワード入力欄でも、ガイダンスの設計でユーザーの体験は大きく変わります。

改善プロセス

1. プレースホルダーで事前に伝える: 入力欄のプレースホルダーに「8文字以上、英大文字・数字・記号を含む」と書くだけで、ユーザーは入力前に要件を把握できる。
2. リアルタイムでフィードバックする: 入力しながら「✓ 8文字以上」「○ 英大文字を含む」のようにリアルタイムで充足状況を表示する。ユーザーは「今何が足りないか」を即座に把握できる。
3. 強度インジケーターで動機づける: パスワード強度バーを表示することで、ユーザーは「もっと強くしよう」という動機を持つ。ガイダンスが行動を促す設計になっている。

6. 関連リンク

• 関連リファレンス（理論）: 認知負荷, 防御的デザイン
• 用語集（定義）: リアクティブオンボーディング, オンボーディング
• 関連するUI原則（横）: オンボーディング (Onboarding), マイクロコピー (Microcopy), エラー回復 (Error Recovery)

7. まとめ

今日から直せる一手 担当しているフォームを開き、入力欄のエラーメッセージが「送信後に表示される」か「入力中にリアルタイムで表示される」かを確認してください。送信後なら、今日中にインラインバリデーションに変更してください。それだけでフォームの完了率は大きく改善します。

チームに共有するなら一言 「最高のヘルプは、ユーザーが『ヘルプを見た』と気づかないほど自然に、操作の流れの中に溶け込んでいる。」