私がユーザー体験の仮説をたて施策をうつときにすること
前提条件として
- ターゲットとなるユーザー層に知り合いがいることが前提です。
- え、いない？ 作りましょう。いないと話になりません。
- え、つくりたくない？ 興味を持つつもりもないユーザー相手に商売してもうまくいきませんよ。
システムしているの？
- 検証でやることはほぼ地道なアナログ作業です。
- このあたりの作業を最後までやりきってルーチン化できれば自動化できます。
- ようするに最初はほぼアナログです。この作業に限って言えば、ディープラーニングや機械学習は「機械に任せられるフェーズが早められる」「分析する変数が増やせる」くらいの効能しかありません。
これを１サイクル回すのにどれくらいかかる？
- 約２週間〜４週間
- 1~2イテレーションくらいです。
- 施策を検証せずに打つより時間はかかります。しかし有効度が高いためこの方法を採用しました。
- 「連射性」より「命中性」を重視した施策の打ち方です。
- 大事なのは「有効弾」や「有効ダメージ」をどれだけ出したかなので、連射性を下げてでも命中率の向上にこだわりました。
やること
1.オフラインインタビュー
最初にユーザーになりえそうな知り合いに直接サービスを見せて、どう思うか？を聞いてみましょう。
- ズケズケものを言うタイプの人がイイです。
- ものを知っている「素人じゃない」人でもいいです。
- ある程度仲が良いなら、競合であってもかまいません。というか競合同士ならお互いにインタビューができます。
- 逆に、取引先とかインターン生とか、そういう利害関係にある人は向きません。こちらに気に入られようと頑張りすぎます。
言われた内容をまとめます。主に、問題点として感じている部分が中心です。
- 逆に解決策として提案されたことは直接は役に立ちません。解決策として提示された内容があれば、実際には何を解決したかったかに注目します。
- 一般ユーザーは問題に対する適切な解決策を知りません。
- 片言隻句に注目するのではなく、発言内容の傾向に着目します。注目すべき点は１０種類以下になるくらいに絞りましょう。５種類以下でもいいと思います。
- 一度に多くは追えません。コストパフォーマンスを考えて重要な奴から叩きましょう。
2.選抜インタビュー
上の内容でまとめた内容をもとに「質問」としてまとめます。質問は複数作ります。
- 「このサービスはどんなサービスだと思いましたか？」
- 「〜〜するときに探しづらいとか思いましたか？」
- 「〜〜しようとしたときに、ちゃんと予約するところまでたどり着けましたか？つけなかったとしたら何が問題ですか？」
- 質問の回答を通じて「ユーザー体験の課題」を検索することが目的です。
質問は選択形式が２、３個、あとは自由記述式がよいです。回答はGoogleフォームでいいと思います。メールベースでも長々書いてくれる人はいます。
- このサービスの第一印象として、どんなサービスだと思った？は私なら絶対入れます。
- たとえば「このサービスを一言で言うと」の部分は運営側とユーザー側で印象は一致しているか？
- 「旅行を比較しながら旅行の予約できる」サービスだとして、「旅行を予約するサービス」だと直感できた？「選ぶ楽しさ」は感じられた？という質問は入れます。
- 作っている側が感じて欲しい部分は「本当に伝わっているか？」はシード段階で検証すべきです。そうでないと伸びません。伸びが止まります。
回答者の選び方
- 「お気に入りリストに大量に登録している」「アクティブに使っている」「滞在時間が長い」というようなヘビーなユーザーを選びます。
- 比較的リテラシーが高く、回答するモチベーションも高いからです。回答する可能性と有意な回答を返す可能性が高いです。
3.少量データチェック
- 選抜インタビューで得られた「ユーザー体験の課題」が本当に正しいか？という点を調べます。検証方法はDBに直接SQLを投げたりスクリプトを走らせたりして収集します。
- いきなりビッグデータ検証はしません。
- 地道かつ不定形な作業になります。
- コスト的に総当たりで調べられないので、調べるには絞りこむためのドメイン知識が必要になります。
目的は２つ。
- 一つは検証方法を確立すること。何を見たら課題の検証ができるか？がわからないと検証の意味がありません。
- もう一つは「回答者が主観的に感じた課題は実在するか？」の検証です。ユーザーが主観的に感じているストレスの原因はユーザーが主張している内容とは異なっている可能性があります。間違った原因を調べても無意味です。
ユーザーの主張する原因に一致する結果が得られない場合
- ストレスを感じている原因は別にある可能性があります。
- アンケートの質問が悪かったのか、ユーザーの認知がゆがんでいるのか、実際には背後に別の問題が隠れているのかを調べる必要があります。
4.大量データチェック
- 上の少量データチェックで有意な仮説検証方法を見つけられた場合に遷移します。
- 「時間をたっぷりかけて調べてみました、よくわかりませんでした。」にならないように基本的にこのフェーズは有意と思われる仮説検証方法を見つけてから移ります。
- 「なんかの参考になりそうな数字」にならないようにしています。
- Google Big Queryでも Hadoopでも Treasure Dataでもお好きなものをどうぞ。
5.自動データ取得
- 大量データチェックでユーザーの挙動を象徴する指標をとります。
- 「施策の効果を測定するための、短期的に監視する数値」は特に監視対象です。
施策実施
- インタビューから時間をかけて検証した仮説をもとに、施策を打ちます。
1.施策の策定と実装方法の立案
- ProttやSketchにおこすまえにペーパープロトタイピングで設計します。
- これは意図やプランをメンバーにも考えさせることで、あとあとのマネージメントコストの低下を狙います。
- 実装者の深い理解は必須です。作っている人間が理解していない意図が、ユーザーに伝わるわけがないからです。
- しかし「理解しろ」の掛け声だけでは解決しないため、実装者にもこのフェーズに参画させることで理解と動機を植え付けます。
2.プロトタイプの検証
- 上で作ったプロトタイプを使って検証します。
- 検証は複数タイプでやります。本命は事前に決まっていても、対抗馬から思わぬユーザーの理解が引き出せる可能性もあります。
- また「対抗馬はなぜ敗れたか？」を理解させることは次回以降の時間の節約になります
実際の検証方法
- ユーザー体験は本当に解消するか？という点はUXデザイナーとそれ以外の素人(チーム外の同僚がいい)を使って検証します。
- チーム内の人間はほぼ隅から隅まで知り尽くしているため、施策を打てば敏感に反応しますが、素人の場合情報の洪水に流されて期待と異なる行動をとったり、挫折したりします。
- 重要なのはユーザーの大半は「怠惰で士気が低く観察力が低い」という点です。偏差値５０以下のユーザーが使えることがヒットサービスの条件です。
- なのでちょっとぼやっとした感じの人の方がテストには向いています。
- 集中力が低下する朝イチか、昼食直後がオススメです。
3.デザイナーによるデザイン
- この段階でようやくデザイナーがデザインします
- 一番最初にこのフェーズを経ないのは、「目に見えるものがないと人間は考えづらい」ので事前に検証をしたいからです。
- デザインの後に最初の検証をかけないのは、仮に「これってよくないのでは？」という疑問が出たときに「必死に考えたデザインを否定された」デザイナーは抵抗を感じますし、実装者は「なぜこれがよいのか」という説明をされていないため「上からふってきた」ものとして感じるからです。
- この２つの感情は「チーム内の軋轢」と「他人事感」を生み出していまう原因になります。
4. 実装
- 上で実装者を施策の実施意図まで含めて 説明しているためこのフェーズはスムーズに進みます。
5. リリース
- 触ってみて、これで大丈夫か？という確認をします。
- 直前まで触っていた人間は親のひいき目がでるので、この段階でも「チーム外の同僚による検証」を入れるのが望ましいです。
6. 検証
- ちゃんと効果は出たか？
- 副作用はなにが出ているか？
- この２つは検証します。問題なければこのまま続行します。
- もしまずかったときにすぐに引っ込められるようにリリースサイズは小さくするのが望ましいです。
