優れたUXを実現するための設計思想である「ユーザー中心設計（UCD: User Centered Design）」について体系的にまとめられたユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―の「Part1 調査・分析」を読んだので、学んだことや所感（＝読書メモ）をまとめます。
ユーザビリティ、UX（ユーザーエクスペリエンス）、UCDの概要についてまとめられている「Introduction」についての記事はこちらです。
ユーザーの声を聞くべからず
いきなり衝撃的なことが書かれていました。UCDの第一原則は「ユーザーの声を聞くべからず」であると。
これは意味は、ユーザーの声の背後には具体的な体験があるが、ユーザーの声はそのような体験をユーザー自身が分析（と言っても素人の分析）した結果に過ぎないと書かれています。
ユーザーの体験は生のデータ（まだ勝手な分析をされていない）なので、設計者が慎重に分析することで、ユーザー本人でさえ気付いていない”暗黙”の要求まで探索することができます。
その”暗黙”の要求に応じてこそ、そのプロダクトに価値が生まれます。
ユーザーの声に応じればユーザーは満足するというのは大きな間違いです。
量的調査と質的調査
調査方法は大きく以下の2つに分類されます。
- 量的調査：数値データやカテゴリデータを収集し、演算・集計して数表やグラフ等で結果を表す
- 質的調査：インタビューや観察など、数値化できないデータを扱う
自社製品に対するユーザーの満足度のように数値の結果が欲しい場合はアンケートをはじめとする量的調査が適していますが、UCDにおける重要な情報である「個別のユーザー体験」を調べるためには質的調査が適しています。
ユーザーに弟子入り
「個別のユーザー体験」を調査するための有効な手段として本書で紹介されているのが、「師匠と弟子（Master/apprentice）」という人間関係モデルに基づいた調査方法です。
この方法の基本プロセスは以下。
- インタビュアーはユーザーに”弟子入り”する
- ユーザーは仕事を見せながら説明する
- インタビュアーは不明点があればどんどん質問する
- 一通り話を聞いたら、インタビュアーは理解した内容をユーザーに話して、理解度をチェックする
実際のインタビューでは、以下の4ステップで構成されます。
- 教えを請う：まず「何を教えて欲しいのか」をユーザーに伝える
- 根掘り葉掘り：ユーザーの行動や説明に少しでも不明点があれば、インタビュアーは根掘り葉掘り質問する必要がある
- 確認する：インタビュアーはユーザーに教えて欲しいことについて一通り理解できたと思ったら、理解した内容をユーザーに確認してもらう
- フォーカスを移動する：話が一段落したら速やかに話題を変える
ユーザーの習性
インタビューで気をつけるべきことはユーザーに「良い師匠」になってもらう（または期待する）のではなく、インタビュアーが「良い弟子」になることです。その理由は一般的にユーザー（というか”人”と読み解いて良いと思う）には以下の習性があるからです。
話を要約する
例えば
「夏休みはどうでした？
という問いに対し、以下のように体験を“要約”して回答するのが普通です。
「友達と神戸に旅行に行ってきました。グルメ、ショッピング、ホテルなど色々楽しめました。今回は大阪・京都には行けなかったけど次回はいきたいです。」
通常の会話だと上記のような何気ないやりとりで話が進みますが、
- 移動手段（新幹線？車？飛行機？バイク？）
- なぜその移動手段を選んだのか
- 旅行の目的（神戸に1番を何を求めていた？）
- その目的は達成できたのか
- どのお店に行ったのか
- そのお店はどうやって調べたのか（食べログ？僕が運営している神戸のグルメインスタ？友達からのおすすめ？）
- 泊まったホテル
- 買ったお土産
このような情報はいちいち自分からベラベラ話しません。通常は、インタビュアー（普通の会話だとすると、神戸に行っていない方の人）が気になったことを質問して少しずつ明らかになります。
話が不完全
例えば以下のようなことです。
- 体験の途中から話を始める
- 話の途中を飛ばす
- 順序を勝手に入れ替えて話す
- 前後の前提条件を省略する
例外を除外する
ユーザーは例外に触れようとしません。ほとんどのユーザーは公式の作業手順についてのみ話します。しかし、どんな作業にも、例外処理はあります。場合によっては、例外の方が重要であることも少なくありません。
ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―（P.34）
と書いているのですが、正直「例外処理」の例が思い浮かびませんでした…のでここはサラッと飛ばします！！！
上記の3つのことからユーザーはインタビューが期待するような完全な回答を提供してくれない可能性の方が極めて高いです。要約された詳細な体験、話の途中を飛ばされた部分、例外の作業の方が「”暗黙”の要求」や「本当に解決すべき課題」を見つけるために重要であることも少なくないので、インタビュアーが「良い弟子」になることが大切です。
インタビューのコツ
本書を読んで個人的に重要だと思ったことを列挙する。（どのようにインタビューするのが良いのかについてはユーザーインタビューのやさしい教科書を読んだこともあり、ここはスッと入ってきたのでサラッと書く）
- 質問はクローズドクエスチョンではなく、オープンクエスチョンにする
- 事前に作ったインタビューガイド通りにやらない
- ガイドの時間配分を気にしすぎると、ユーザーから重要な情報が聞けそうになってきたのに次の質問に行ってしまうから
- 録画や録音する場合は、必ず事前に同意を得る
ペルソナ
ペルソナとは「”仮装”のユーザー像」のことです。
ペルソナを使用する背景としては、
- インタビュー等で得られた全てのユーザーのニーズを満たそうとすると、結局誰のニーズも満たさない製品が出来上がってしまう
- みんなのためにデザインするのではなく、1人のためにデザインする
という考えがあります。
ペルソナは名前や顔写真も用意して、実在の人物のように描きます。そして重要なのがペルソナは”架空”のユーザーではないです。空想上の生成物ではなく、事実（ユーザーのデータ）によって作られます。
ペルソナには名前を定義しますが、有名な名前（芸能人やアニメのキャラ）はその名前に強いイメージが既に染み付いてしまっているので、使わない方が良いと書かれていてなるほどなーと思いました。（名前辞典サイトを使うのが良いみたい）
ペルソナの個人情報は最低限この3つは定義します。（+αはそのプロダクトによりけり）
- 性別
- 年齢（年代）
- 職業
ペルソナの使い方
ペルソナは1つのプロジェクトで3体〜6体くらい定義することが多いです。
複数のペルソナから、優先順位をつけ、1位のペルソナ（プライマリーペルソナ）の要求を完全に満たすことを目的にします。
プライマリーペルソナの要求を最優先で満たしますが、2位以降のペルソナ（セカンダリーペルソナ）の要求をガン無視するわけではないです。
とある機能を検討する場合は以下のようなケースを作ることができます。
| プライマリーペルソナ | セカンダリーペルソナ | 結果 |
|---|---|---|
| 要求する | ※どんなケースでも同じ | 実装する |
| 要求しない | 要求する | 却下 |
| どちらでも良い | 要求する | 検討可能 |
要求が対立する場合は、プライマリーペルソナを優先します。プライマリーペルソナが要求する場合はセカンダリペルソナの要求がどうであれ、その機能は実装が必要になります。
最後に
この章では個人的に超序盤ですが、UCDの第一原則は「ユーザーの声を聞くべからず」であることがとても印象的でした。ユーザーインタビューの経験があるので、読みながら「確かに！」となったのですが、やはり文字にして見てみるとインパクトは大きいですね。。
インタビュアーとして（も）有名な阿川佐和子さんのインタビュー術に関する記事。
「聞く力」という本もあるので時間を見つけて読んでみようと思います。（知らなかったけど多分これ普通に有名な本ですよね）
お得に読書をするなら月額980円で200万冊以上の本が読み放題のkindle unlimitedがオススメです。
30日間の無料体験がありますので、少しでも気になった方はぜひ使ってみてください。
コメント