FAQを作るとき、
多くの現場ではまずこう考えます。
どんな質問が来ているか
よく聞かれる内容は何か
問い合わせが多い順に並べよう
一見、合理的です。
しかしこの発想こそが、FAQを機能しなくさせる原因になります。
なぜなら、FAQが向き合うべき対象は「質問」ではないからです。
FAQに載せるべきなのは「質問」ではない
ユーザーは、最初から質問文を持っているわけではありません。
何が分からないのか、まだ言語化できていない
自分の状況が特殊なのか、一般的なのか分からない
聞くほどのことなのか判断がつかない
この状態でユーザーが抱えているのは、
質問ではなく「迷い」です。
質問は、その迷いを言葉にできた“結果”にすぎません。
「質問ベース」でFAQを作ると起きること
質問を基準にFAQを作ると、次のような状態に陥ります。
文言が実際の問い合わせとズレる
状況が違うと当てはまらない
自分のケースか判断できず、結局問い合わせる
FAQは存在しているのに、
ユーザーの判断は一歩も進まない。
これが「FAQは読まれているのに解決しない」状態です。
FAQが本当に扱うべきもの＝ユーザーの「迷い」
では、FAQは何を扱うべきなのか。
それは、
不安になっている状態
判断できずに止まっている状態
次に何をすればいいか分からない状態
こうした行動が止まる原因です。
FAQは、
「質問に答える場所」ではなく、
迷いを解消し、次の行動に進ませるための装置です。
迷いは「現象」ではなく「判断の詰まり」で捉える
ここで重要なのは、
迷いを単なる出来事として扱わないことです。
たとえば、
メールが届かない
ログインできない
エラーが出た
これらは、起きている“現象”にすぎません。
ユーザーが本当に困っているのは、
どこを確認すればよいのか分からない
自分の操作が間違っているのか判断できない
このまま待っていいのか、対応が必要なのか分からない
といった判断の詰まりです。
FAQが向き合うべきなのは、
この「判断できない状態」そのものです。
FAQに載せるかどうかの判断基準
FAQに載せる内容は、
件数や頻度だけで決めるべきではありません。
判断の基準は、次の一点です。
その迷いは、ユーザーの行動を止めているか
この問いに「はい」と答えられるなら、
たとえ問い合わせ件数が少なくても、FAQに載せる価値があります。
FAQは「多い質問」を集める場ではなく、
迷わせてはいけないポイントを守るための設計だからです。
FAQに載せるべき「迷い」を拾う入口は、問い合わせだけではありません。
問い合わせは強い材料ですが、最後に表面化した迷いしか残りません。
実務では、次の3つの入口をセットで見ます。
- 問い合わせログ：困り切って問い合わせに来た迷い
- ヘルプ検索ログ：探したが解決できなかった迷い
- サジェストワード：そもそもユーザーが使っている言い方
既存サービスでは問い合わせ・ヘルプ検索ログが中心になります。
新規や改修直後はログが薄いため、サジェストワードから「迷いの言葉」を先に拾ってFAQ候補を作ります。
この入口の違いを理解しておくと、
「載せたつもりなのに見つからない」「問い合わせには出るのに検索では拾えない」
といったズレを、材料の段階で減らせます。
FAQは「質問集」ではない
ここまで整理すると、FAQの位置づけは明確です。
Q&Aは、個別の質問への回答
よくある質問は、頻度の整理
FAQは、迷いを減らすための構造
FAQとは、
質問を並べるものではありません。
ユーザーが立ち止まる地点を特定し、
判断を前に進めるための応答を用意すること。
それが、FAQが果たすべき役割です。
まとめ
FAQには、
「質問」ではなく「迷い」を載せるべきです。
質問文をどう書くか以前に、
どこでユーザーの判断が止まっているかを見極める。
FAQを「情報の一覧」ではなく、
「迷わせないための構造」として捉え直したとき、
はじめてFAQは機能し始めます。
コメント