ヘルプサイトの作り方
著者:仲田尚央
https://images-na.ssl-images-amazon.com/images/I/41QfyPzNC7L._SX350_BO1,204,203,200_.jpg
通読して感じたのは、ドキュメント整備にも通ずるものがある、ということ。大事なのは以下
誰に何を伝えるのか、目的をはっきりさせる
必要な情報を構造化して整理することが一番大事
アプリケーションと同じように、設計から始まる
作ったら終わり、ではないので改善を続けていく
こまごまとしたテクニック的なものの紹介も多岐にわたっていて、非エンジニア・非デザイナーの人が読んでも分かるような内容のレベル感でわかりやすく述べられていると思った。ペルソナ設定からHTMLの記述、GAの設定からGitのさわりまで、、、、と内容が多岐に渡るぶんそれぞれの内容は浅く広く、という感が否めない。必要であれば専門書を別途用意するという形で十分なのだと思うが、そもそもすべての人に必要な情報とも限らないのでは?と思いこの本の主題に思いを馳せることになった。
まさに、この本自体が誰に向けて書かれているか=ペルソナは誰か、その人にどういう情報が必要だと考えたのか。サービスを運用しているエンジニアなのか、カスタマーサービスの領域の人たちなのか、プロダクトオーナーとかマネージャークラスの人なのか。一体誰の役に立つのだろう、と。
曲がりなりにもエンジニアである私としては、前半部分の内容をもっと深堀りして欲しかった感じしかしない。設計が大事、情報の整理と構造化が大事、というならそこが一番大事なんだけどな、と。小さく作って改善回す、というのも合わせて紹介されているのだが、そちらも手法とかの紹介なのでもっと改善の仕組みづくりとか考え方にフォーカスして欲しかった。ただこれは、私が本書で言うところのストーリーに当てはまらない人間だったということが大きいようで、実際にAmazonレビューにはプロダクトマネージャーをしている人が星5をつけていたし、べた褒めコメントもあった。
個人的には何ページもの書籍にしなくとも付箋20枚くらいの箇条書きでまとめられるかな、という感じ。
各章のタイトルにつづいてまとめや気付きをメモしておく。
ヘルプ作成に必要なのは文章力より設計力
・想定ユーザーのスキルや状況を考え、何を伝えるべきかを明確にする
・ユーザーがどのような状況でどのような情報を探すかを考える
・ユーザーが必要な情報を見つけやすいように、情報を整理して構造化する
良いヘルプの要素は、役に立つ、探しやすい、正しい、わかりやすい
一文を短く
要求を先に述べる
ヘルプ制作の流れ
誰に何を伝えるかを整理する
構成を設計する
スタイルガイドや用語集を用意する
記事を作る
記事をチェックする
公開後にフォードバックをもとに改善する
誰に何をつたえるかを整理する
ペルソナ設計から始める
複数人いてもOK
自発的なストーリー
書き手が伝えたいことを整理する
このとき、できないことも明確に伝える
ドックフーでィングして感じたこと、つまづいたところを書き出す
ユーザーの使い方を意識して構成を設計する
情報探索のモデル
既知項目検索 自分が探しているものが何かわかっている状況
探求検索 自分が何をわかっていないのか、何が必要な情報なのかを把握していない状況
再検索 過去に見たことがある情報を再度見る必要が生じて再び探す状況
全数検索 あるトピックについての情報を網羅的に探す状況
動線も2種類ある
直線的な動線 目的が定まっているパターン(既知項目検索=スーパーの乾物売り場)
カテゴリ構成では機能別、目的別、状況別、ターゲット別などで分類し、どこになんの情報があるかわかりやすくする
回遊的な動線 目的が定まっていないパターン(探求探索=スーパーの野菜肉売り場)
初心者向けの特別な動線
チュートリアルなど
ユーザーはページを流し読みするのでトリガーワードを有効に使う
トップダウンで設計するパターン、ボトムアップで設計するパターンを繰り返して設計する
ユーザ−の動線からナビゲーションを考える
ページナビゲーションの考え方
モバイルユーザーの行動とデスクトップユーザーの行動の違い
モバイルのほうが閲覧ページ数の平均が2ページ以上少ない
モバイルのほうがオーガニックサーチからの流入が多い
モバイルではサイト内検索が使われる率が低い
ユーザーが疑問を解決できているか確認する
これがないと改善にやくだてることができない
スタイルガイドや用語集を準備する
スタイルガイドを用意するのは大変なので公開されているやつを参考にする
用語集で用語を統一
Webデータベースで管理
登録、編集が容易にできることが必須
言葉の使い方も変化するので、どうしてこの表記に統一したのか、なぜ変更したのかなどの議論もWebデータベース上で残していく
国によって意味が異なる表記などを使わない
1990/10/10など
参照リンクは「こちら」などの表記にせずリンク先に書かれてある事がわかるタイトルでリンク張ること
複数の意味に取れる文章やイラストを避ける
記事を作る
具体的な記事の書き方、テクニックの話。
ユーザーのスタートとゴールを決める
記事を読む前のユーザーの理解度、何を求めてこの記事を読むのかを確認してから書く
各記事に対してスタートとゴールを設定する
伝えることを箇条書きで整理する
ユーザーを主体にした文体を意識
伝えることを整理できたらふさわしい見出しをつける
わかりやすい記述
二重否定を用いない
係り受けをはっきりさせる
主述の対応をあわせる
一文一義
主述近接
トラブルシューティングは、以下の3つを伝える
状況
原因
対処法
データからヘルプサイトを改善する
ヘルプの改善をどう回していくか、という話。後半は具体的なGAの設定などになったので割愛。
ヘルプのKPI設定方法
アンケート集計結果
検索結果ページでの離脱率
解決までの時間
検索結果ゼロの割合
チュートリアル完走率
初回訪問ユーザーがアンケートにポジティブなリアクションをした割合
アンケートの質問項目を検討する
KPIに設定するには正しい情報を得る必要がある
回答率とかにも関わる
ユーザーテストでヘルプを改善する
シナリオを作って、ユーザーテストを行う
テスト前にユーザーの立場や考えていることをストーリー調のテキストで共有する
ユーザーは自分がシナリオの中の人になったつもりでサービスをテストする
ユーザーテスト前に思考発話の練習をする
使いながら考えていることをできるだけ発話してもらうことが大切
5分程度、任意のウェブサイトを使いながら考えていることを声に出してもらう
テスト実施中はユーザーの言動を観察する
できれば離れたところから観察する
手助けはしない
ユーザーテストのインタビューをする
使ってみて総合的にどうだったか
迷ったり意図と違う動きになったところはあったか
記事を読んでどう感じたか
記事をどこまで理解できたか
ヘルプサイトの構成のチェック方法2つ
どちらもやったほうがいい
クローズドカードソーティング(既存のヘルプがあるとき)
大分類や中分類を用意しておいて、記事の内容を項目に分類してもらう
オープンカードソーティング(新規で作るとき)
記事の内容をカテゴライズしてもらい、それをもとに分類に反映させる