ヘルプセンターを作ることになった。
まず知りたいのは「どんな構成にすればいいのか」という具体例だと思います。
この記事では、
- 一般的なヘルプセンターの構成例
- よくある失敗パターン
- 改善につながる構成の考え方
を順に整理します。
一般的なヘルプページの構成例
多くのWebサービスで採用されている基本構成は、次のような形です。
ヘルプトップ
├ 検索バー
├ お知らせ
├ よくある質問（FAQ）
├ カテゴリ
└ 問い合わせフォーム
この5つで、ヘルプの土台は成立します。
① 検索バー（トップに配置）
ユーザーがキーワードで直接探せる導線。
ヘルプに来る人の多くは「探し物」が明確です。
だからこそ、装飾よりも
迷わせない位置と視認性が重要になります。
② お知らせ
ここは“全体影響”の領域。
- 障害情報
- メンテナンス
- 仕様変更
- 重要告知
FAQとは役割が違います。
お知らせは「全員向けの告知」。
FAQは「個別の困りごとの解決」。
ここを混ぜると、情報の優先順位が崩れます。
③ よくある質問（FAQ）
問い合わせの多い内容を即答するエリア。
ただし注意点があります。
人気順だけで並べると、
“過去に多かった質問”に引きずられます。
今困っている人の優先順位と一致しているか。
ここが設計の分岐点です。
④ カテゴリ
「アカウント」「料金」「操作方法」など、
機能単位で分けるのが一般的です。
しかしここに落とし穴があります。
ユーザーは機能で探していません。
- ログインできない
- 請求額が違う
- メールが届かない
という“困りごと”で探しています。
分類が運営視点のままだと、
検索依存のヘルプになります。
⑤ 問い合わせフォーム
自己解決できなかった場合の連絡手段。
ただし、
ヘルプの途中で強く出しすぎると、
考える前に問い合わせが選ばれます。
問い合わせは並列導線ではなく、
最終手段として設計する。
ここも成果を左右します。
ここまでが“型”
検索上位の記事は、
ほぼこの説明で終わります。
でも、なぜ問い合わせは減らないのか？
要素はあるが、構造になっていない
構成“要素”は揃っている。
なのに機能しない。
理由は単純です。
ヘルプが「ページの集合」になっているから。
ヘルプは本来、
解決までの流れで設計するものです。
改善につながる構成とは？
重要なのは「要素」ではなく「流れ」。
ヘルプは、
困りごと
↓
状況確認
↓
具体手順
↓
関連ケース
↓
解決しない場合のみ問い合わせ
というプロセスで設計する。
この流れが成立していれば、
構成要素が同じでも成果は変わります。
カテゴリ設計の視点を変える
機能軸ではなく、
“つまずき軸”で分類する。
例：
× アカウント
○ ログインできない
○ パスワードを忘れた
分類を“判断できる単位”に落とすと、
検索依存が減り、到達率が上がります。
ヘルプページ構成で本当に考えるべきこと
検索バーを置くかどうかではありません。
考えるべきは3つ。
- ユーザーは何を基準に探すか
- どの順番で判断させるか
- どこで問い合わせに誘導するか
この3点が設計できていないと、
デザインを整えても成果は変わりません。
まとめ
一般的なヘルプセンター構成は、
- 検索バー
- お知らせ
- よくある質問
- カテゴリ
- 問い合わせフォーム
で成り立ちます。
しかし、機能するかどうかは
「構成要素」ではなく「解決までの構造」次第。
構成例をそのまま真似るのではなく、
自社サービスの“つまずき”を基準に再設計する。
では、実際にどの順番で設計すればいいのか。
ヘルプページを「書く前」に決めるべき構造設計を、以下の記事で整理しています。
コメント