「良いFAQの書き方」で学ぶ現場で使えるFAQ改善への道
とても参考になり、かつ具体例が豊富すぎる書籍でした。
はじまりはこの日・・・
FAQに特化したkindle参考書の不在
上記のツイートにもあるように、FAQに特化したkindle参考書はほとんどありませんでした(物理本なら「FAQの活用と実践」がありましたが)
類似では、同じく技術評論社から出てる「ヘルプサイトの作り方」があって、すごく参考になる知見が多かったです。
ただヘルプサイトの作り方は、(有益知見はたくさんあるものの)文字通りヘルプサイトの情報設計全体をスコープにしていて、プロジェクトとしては少し大がかりになりがちなトピックが多い印象がありました。
一方で「良いFAQの書き方」の方は、CSという部門単位で取り組める知見が多く、現場で手を動かせる内容が多い印象です。
ということで、書籍の内容を触りだけ紹介しつつ、個人的に改善の切り口として参考にしていきたいポイントを紹介していきます。
補足
具体例がめちゃくちゃ豊富なので「FAQ、どうしたら良いのか分からん」な人は、書籍の目次だけでも見て、良さそうならポチっとすることをおすすめします。逆に、普段からバリバリFAQ改善してたり、ゴリゴリ試行錯誤している人には、物足りない内容かもしれません。
表記の説明
Q:Question --> FAQタイトル。ユーザー質問
A:Anser --> FAQ本文や内容。質問への回答/解決策
良いFAQサイトに備わる5つの要素
質の良いFAQサイトにはいくつか共通する要素があり、大まかに5つに分類できます。
良いFAQの書き方 では、5つの内、(1) と (2) を重視して具体的に解説されています。
QAの質に重要なこと
結論からいえば「一問一答であること」が重要であると解説されています。
一問一答であることにより
FAQよくあるNGパターン
初級レベル
専門用語が多用されてる
文章が長過ぎる(説明が冗長過ぎる)
適切に画像が使われていない
表記の揺れが多い
記事の数が多すぎる
厳密にはプロダクトや商品、事業規模と対するユーザー数の比率などが考慮される
中級レベル
QとAが一問一答になっていない
Q(タイトル)が具体的でなくユーザー毎に解釈の余地が出てしまう
解決や結論が先に記載がない
集計(後の改善)を前提に設計されていない
1つの記事に強調色などが3種類以上使用されている
FAQの質を改善する流れ
Step1:QAを一問一答にする
Step2:推敲する(Q→Aの順)
Step3:運用する(データを取る)
Step4:改善する(分析→絞る→推敲するor増やす)
1. Qで困りごとを具体的にする
例1
困りごとや目の前の事象、頭に浮かんだ不明点をQに含めます。
例2
Qが 問題+解決案の先出し になるようします。
補足説明
ユーザーは頭に浮かんだ言葉を使って記事の「検索」を行うことが多い
問題を抱えるユーザーは目の前の事象を具体的に言語化できているわけではない
ABCカードをなくした でもユーザーの状況と一致していると感じれば記事自体はクリックはされる
ただし、解決案は実際にページを見るまで分からない(期待が外れることがある)
改善策
A(本文/回答)をシンプルにして、すばやく読んで理解できるようにする
Q(タイトル)の文のあいまいさや誤解の余地をなくす
2. Q(記事タイトル)一覧の視認性を改善
修正後のが視認性が良くリスト時に見つけやすい
文節や表記を整えて視認性を改善する
文頭や文末を同一の表現にそろえる
例
修正後 では全体の意味を変えずに「ネット電話」を文頭に、「教えて」を文末にQ(タイトル)を修正します。
3. ログ集計の質を高める
一問一答にすることでサービスのどこで躓きが発生するのか明確になる
一つのQにAを複数入れると改善すべきポイントが見えづらくなる
一問一答だと集計の質が上がり、データ分析の質も高くなる
質がやや低い状態
「カードの解約について」という記事へのアクセスが、仮に「計1000件」ある場合では以下の目的が混在することになってしまいます。
質がやや高い状態
ユーザーの目的(アクセス)がことなるため、記事を目的ごとに分割してから集計することで、どの課題から着手すべきかの判断材料にしやすくなります。
・・・とこんな感じで、豊富な具体例とともに解説されています。具体例が豊富なので、ほとんどのサービスで参考になるものがあるんじゃないかと思います。
上記はほんとに一部のエッセンスにすぎないため、興味のある方はぜひ書籍を手に取り、実際に「手を動かすFAQ改善」を進めていきましょう