FAQ を用意する際に考慮したいこと

Web サイトは他の媒体(テレビや新聞、雑誌など)に比べて、ユーザーが能動的に回遊しながら情報を得て、自らの目的を達成するように行動をするという点で、「セルフサービス」型なメディアと言うことができます。そんな、セルフサービスメディアとしての Web サイトにとって、うってつけと言えるコンテンツのひとつに、FAQ(Frequently Asked Questions)があります。ユーザー(顧客)から頻繁に寄せられる質問とその回答を、あらかじめサイト上で公開しておき、閲覧できるようにしておくものです。

この記事では、FAQ を扱うえで、ユーザビリティの観点から問題になりがちなこと、考慮しておきたいこと、などについてまとめたいと思います。

FAQ のメリット

まずはじめに、FAQ を Web サイトで公開しておくことのメリットについて、おさらいがてらリストアップしておきましょう。

  • ユーザーが課題を自己解決できる。適切な内容の FAQ があれば、わざわざ問い合わせたりする手間が省けるので、解決までの時間短縮/効率化につながり、ユーザーエクスペリエンス(顧客満足度)の向上が期待できる。
  • サイト運営側にとっては、問い合わせ件数の減少(ひいては顧客サポートの効率化やコスト軽減)が期待できる。
  • FAQ の充実がすなわちサイトのコンテンツの充実になる。コンテンツが充実すれば、サイトへの顧客流入経路の多様化に対応できる可能性が高まる(検索エンジンでの様々な入力クエリー、ソーシャルメディアからの被リンク、など)。

このように、ユーザーにとっても、サイト運営側にとっても、メリットが大きい FAQ ですが、実際は「他社のサイトでもやっているから、取り敢えずうちのサイトでも...」というような姿勢でいたりしませんでしょうか?私が知る限りの事例ですが、FAQ はコンテンツ企画や制作において、比較的優先度が低くなってしまうことが多いように思います(取り急ぎ、通り一遍の FAQ を作っておいてハイ終わり、といった具合に)。とした場合、実質的に役立たない FAQ になってしまい、ユーザーもサイト運営側もハッピーにならない、もったいない結果を招くかもしれません。

FAQ 作成において注意すべきこと

FAQ を、ユーザーにとってもサイト運営側にとっても役立つものにするためには、下記のように、いくつか注意しておきたいことがあります。

内容について

サイト運営側のひとりよがりな Q & A にならないことが、何よりも大切です。本当にユーザー(顧客)が欲している内容でなければなりません。Jakob Nielsen(ヤコブ・ニールセン)氏は、Alertbox というコラムにおいて、FAQ を「Top Ten Web-Design Mistakes(Webデザインにおける10大ミス)」のひとつとして挙げています。彼は「あまりにも多くの Web サイトが FAQと称して、実際には企業側/サイト運営側がユーザーに質問して欲しい内容を羅列している。(Too many websites have FAQs that list questions the company wished users would ask. No good.)」と言っています。これは、2002年に書かれたコラムですが、今でもそういうサイトは、多いのではないでしょうか。

こうした問題を回避するには、ユーザーが「実際に」してくる質問の内容を集め、分析することが役に立ちます。様々なチャンネル(メールや電話などで寄せられた問い合わせ、実店舗などでの実際の会話、など)を通じてこれまでに得られた質問やコメントを集め、分類し、パターン化し、抽象化して、FAQ に落とし込むのです。分類された質問内容の、実際に寄せられている回数や頻度も併せて考慮に入れると、FAQ 項目の優先度を決めるうえでの材料になるでしょう。この作業は、カスタマーサービス担当者、実店舗で接客をしている人、コールセンターのスタッフ、といった関係者にも一緒に参加してもらい、KJ 法のような手法を用いてまとめると、より実効性のあるものになると思います。

もちろん、今の世の中、インターネット上に散りばめられている自社の評判や不満なども参考にできますね。ツイッターやブログなどを、エゴサーチ的な手法で検索してみることで、FAQ に加えるべき内容のヒントが見つかるかもしれません。

また、サイト開発途上において実際のユーザーを招いてユーザビリティテストを実施している場合、そこで得られた知見(ユーザーの要望)で、最終的に実装に至らなかった事項を、FAQ として拾い上げるというのもアリでしょう。

ところで、FAQ の実効性を計る手段として、「この回答で問題が解決できましたか?」というアンケートを見かけることがあります。段階評価や Yes/No の選択肢を用意して FAQ の満足度を定量的に計ろうとするものですが、単にユーザーにひと手間かけさせているだけで、ユーザー側にはなんのメリットも無く、定量的調査として十分なデータが収集できているかも疑問です。もし満足いく解決ができなかった場合にこの手の質問を提示されたら、多くのユーザーは余計な苛立ちを覚えるだけでしょう。アンケートを盛り込みたいのであれば、ごくシンプルで控えめな自由記述形式のフォームにすることを検討してはいかがでしょうか。(ユーザーが残念ながら問題を解決できなかった場合)どんなことが知りたいですか?といった問いかけをするのです。実際にフォームに記入してくれるユーザーは多くないかもしれませんが、記入したユーザーにしてみれば「多少は自分のことをケアしてくれている」と感じることができるでしょうし、寄せられた内容によっては、FAQ 内容(あるいは他のサイトコンテンツ)の改善のヒントになる可能性があります。

表記/表現について

FAQ を実際にサイト上でどう表現するか、ですが、英語で「FAQ」や「Q & A」などと表記するよりは、「よくあるご質問」のように日本語で表記するほうが、わかりやすくてよいでしょう。ユーザーの多くは Web ページ上を「斜め読み」して、興味関心に引っかかった箇所だけをじっくり読もうとします。斜め読みに対する視認性を高める(ユーザーに気づかれやすくする)ためにも、日本語表記のほうがベターだと思います。

また、個々の Q & A 項目を記述する際には、「ユーザー(顧客)の言葉」で表現することを十分に意識し、社内用語や難解な用語/略語は極力使わないようにしましょう。

そして、FAQ の記述においてもっとも大切なのは、ユーザーを不快な気持ちにさせないことです。実際に接客しているような感じで、質問者に対して誠意を尽くした回答にするべきであることは言うまでもありません。ただし、丁寧すぎる言葉遣いで冗長になるのも逆に問題です。ユーザーは課題の自己解決のために、必要な情報を「正しく」「素早く」入手したいだけなので、適正な内容を簡潔に表現することを心がけましょう。

ナビゲーションについて

FAQ のインデックスページから、個々の Q & A 項目にナビゲート(誘導)するには、様々な手法があります。あらかじめカテゴリー分類しておいてリンクを辿ってもらうことが基本になりますが、大規模な FAQ ですと、キーワード検索やソート(並べ替え)機能などを実装して、ファインダビリティ(findability:情報の探し出しやすさ)をサポートする仕組みを提供しておくと、ユーザーに喜ばれるかもしれません。よく参照されている FAQ のランキングを提示するのも一考でしょう。

ここで気をつけておきたいのは、FAQ にアクセスするユーザーは、その時点で何らかのフラストレーションを抱えている可能性が高く、とにかく早く問題解決したいと思っていることが多いことです。カテゴリーの分類、ラベリング(表記)、階層構造の設計においては、ユーザー視点に立った十分な配慮が必要であることは言うまでもありません。また、キーワード検索やソート機能を実装する場合は、データベース設計やクエリー対応の仕様決めをしっかりと行ない、ユーザーの要求に対して必要十分に、また迅速に、応対できるようにしておかなければなりません。

ナビゲーション設計において大切なのは、ユーザー(顧客)に対して「あなたのことをきちんとケアしたいと私共は思っています」という姿勢を具現化することと、ユーザーの時間を無駄にしないこと、だと思います。

「答え」は独立したページで

ひとつのページに、質問と答えを羅列している FAQ を見かけることがあります(特に比較的小規模な FAQ で、よく見受けられます)。私見ですが、できればインデックスページ(質問項目をリストしたページ)と個々の「答え」のページは別々に用意しておき、インデックスページから個々の「答え」のページにリンクさせるほうが望ましいと考えます。というのも、こうしておくことで、アクセスログ解析を通じて、どの質問項目がよく参照されているか(逆にされていないか)を定量的にモニターすることができるからです。こうして得られたデータは、ユーザーの関心事を理解したり、コンテンツ改良のヒントを掴むための、参考になることでしょう。

ユーザビリティ的な観点で、「ユーザーに1クリック余計な操作をさせることにならないか?」という議論もあるかもしれませんが、逆に、インデックスページの内容を質問項目(Q & A で言うところの「Q」)に限定することで、サイトで用意されている FAQ 内容をユーザーが見渡しやすくなり、スクロールによるページ内の行き来をそれほどすることなく、関心のある「Q」を見つけやすくなる、というメリットもあります。

無駄な FAQ 項目を削減する

FAQ の充実は、すなわちサイトのコンテンツの充実に直結しますが、だからといって、無闇やたらと FAQ 項目を増やすことは考えものです。ファインダビリティ(情報の探し出しやすさ)の面で考えると、できるだけ項目は少ないほうがよいと言えますし、少なくとも、ノイズとなるような項目は極力排除すべきです。なんでもかんでも FAQ にしない、無駄な FAQ 項目は削減して本当に FAQ で扱うべき項目のみを残す、といったことも考慮しましょう。

たとえば、極端な例ですが、「資料請求したいのですが、どうすればよいですか?」といった質問項目があるとします。資料請求の申し込みフォームが用意されているサイトにおいてこの手の質問が来るとしたら、それはナビゲーションの不備に起因するものなので、わざわざ FAQ 項目にするよりはむしろ、ナビゲーションデザインを改良することで解決すべき問題であると言えるでしょう。

無駄な FAQ 項目を削減するヒントとしては、以下が挙げられます。

  • サイト内に既に「答え」となるコンテンツが存在している質問であれば、そのコンテンツのページにユーザーが辿り着けていないことが考えられる。ナビゲーション/動線設計が適切かを検証し、改良する。
  • 既存のコンテンツの記述内容がわかりにくい(ユーザーに意図が適切に伝わってない)ということも考えられる。コンテンツが「ユーザーの言葉」で表現できているかを検証し、改良する。
  • サイト内に盛り込まれていない内容で、ユーザー(顧客)から同じ質問が頻繁に寄せられているのであれば、FAQ に追加する以前に、その内容をサイトの新規コンテンツとして制作することを検討する。

上記のような対策を講じた上で、それらのコンテンツにユーザーを導く補助手段として必要であれば、FAQ の掲載も検討する、くらいのスタンスがよいのではないか、と考えています。

課題解決の主導権をユーザーに与える

よく見られる例として、リンクを辿って「お問い合わせ」ページらしきところにアクセスしたつもりが、実際には FAQ がずらーっと並んでいて、お問い合わせフォームが見つけられない、というサイトがあります。また、もっとひどい例として、「お問い合わせ」ページへのアクセス方法が明示されておらず、FAQ を閲覧して初めて、問い合わせ方法がわかる、というサイトもあったりします。

問い合わせをする前に FAQ の閲覧を強要するようなフローは、顧客サポートの手間を減らしたいというサイト運営側の意図が見え見えで、ユーザーからすると不快感を覚えます。「FAQ を使って課題を自己解決したい」のか「サイト運営者に直接問い合わせて課題を解決したい」のかを選択する主導権は、あくまでもユーザー側に委ねるべきだと思います。これは FAQ ページに限った話ではありませんが、お問い合わせフォームへのアクセスは、いついかなる状況にユーザーがあっても、すぐにできるようにしましょう。

マーケティングツールとしての FAQ

FAQ は、顧客サポートツールとしてだけでなく、Web マーケティングの有力なツールともなり得ます。いくつか、そのヒントをご紹介したいと思います。

ランディングページとして活用する

FAQ ページ、特に個々の「答え」のページは、適度に内容を充実させることで、また、下記のようなちょっとした工夫を施すことで、検索エンジンからのランディングページ(ユーザーが、そのサイトで最初に訪れるページ)として活用することができます。

たとえば、自サイトで提供している商品やサービス内容に関して、Google などの検索エンジンで吸収できないような表記揺れがある(人によって表記のしかたが異なる)場合、それら異なる表記をすべてキーワードとしてページに盛り込む形で、FAQ の回答文面を作成することによって、検索エンジンからの来訪の間口を広くできる可能性があります。人によって誤字が多く見られる用語、読みかたが複雑で人によって発音(かな表記)が異なりやすい用語、についても、同様のテクニックが使えるかもしれません。適正な範囲で(キーワードスパムと検索エンジンに解釈されない程度で)、いろいろ試してみるとよいでしょう。

また、競合他社の商標があまりにもポピューラーになりすぎて一般名詞化している場合は、その他社商標をちゃっかり(もちろん、フェアな範囲で)自社サイトの FAQ に盛り込むことで、検索エンジンからの来訪を増やせる可能性があります。古い例ですが(こんなたとえ話をしたら年齢がばれそう...)、昔、ヘッドフォンステレオ(ポータブルなカセットテープ再生機)を指す言葉として、ソニーの商標である「ウォークマン(Walkman)」が一般名詞化するほどに世間を席巻していました。ライバルメーカー、たとえばアイワからは「カセットボーイ」という製品が出ていましたが、一般の多くの人にとっては、「アイワ製のウォークマン」と認識されてしまうほどでした。このようなケースで、仮に自分がアイワのウェブマスターだったとしたら、「ウォークマンとカセットボーイの違いは何ですか?」といった具合に「ウォークマン」という語を巧みに盛り込んだ Q & A を用意して、「ウォークマン」+「アイワ」というキーワードで検索してきたユーザーを自サイトに誘導することを試みると同時に、ソニーのウォークマンには無い、自社製品の特長をアピールする回答文面を用意すると思います。

FAQ から「その先」に誘導する

FAQ は、ユーザーの課題の自己解決を支援しますが、その FAQ 回答ページを読んで終わり(ユーザーはそこからサイトを離脱する)にするのではなく、できれば「その先」に、ユーザーを導きたいところです。関連する具体的な商品/サービスの詳細ページへのリンクを設ける、資料請求や問い合わせへの入り口を設ける、など、何らかのコンバージョンにつながる動線設計ができないか、ぜひ検討しましょう。

大事なのは、実店舗での顧客対応と同様、質問を受けたらお返しとして「具体的に提案すること」です。できないことに対して「できません」と回答して終わる接客は、実店舗ではあり得ないことでしょう。Web サイトにおける FAQ も同様で、このような場合も何らかの代替案を示し、そこに誘導するなど、ポジティブな内容に変える工夫をしたいものです。

繰り返し、改善すること

実際のところ、FAQ の内容は、特に開設当初は、仮説レベルで公開されてしまうことが多いことでしょう。仮説レベルから、「本当にユーザーが欲している内容」のレベルに進化させるには、公開後であっても、少しずつでよいので、改善を繰り返すことが大切です。

改善を繰り返し、FAQ が進化して内容が変わってくれば、結果的に、カテゴライズやナビゲーションなどの変更も必要になってくるかもしれません。あくまでも「どのような動線を提供することがユーザーにとってベストか」という観点に立ち返り、必要に応じて改良を惜しまないようにしましょう。ただし、ユーザーの中でこれまで蓄積されたメンタルモデルを覆してしまうほどの大きなナビゲーション変更は、慎重に検討したいところです。また、個々の「答え」のページは、ランディングページとしての価値を維持するためにも、安易に URL を変更しないことが望ましいと言えます。FAQ 内部の URL のロジックは、将来的なカテゴリーの変更にも対応できるように、初期段階から慎重に吟味しておくことをおすすめします。

なお、公開後の FAQ の継続的改善においても、上記「内容について」などでご紹介した各種の手法を用いることはもちろん可能なので、特に「ユーザーが本当に知りたいことを吸い上げる」ことを意識しつつ、これらの手法を活用していただければと思います。