机上のUXじゃなく、ユーザの本音を聞き出すインタビューとユーザテスト方法って?

机上のUXじゃなく、ユーザの本音を聞き出すインタビューとユーザテスト方法って?

本のまとめ

▼読んだ本は?
■ユーザビリティエンジニアリング(第2版) ―ユーザエクスペリエンスのための調査、設計、評価手法
■樽本徹也さん
http://amzn.asia/d/fBiS2OF
▼ユーザビリティを超えたユーザエクスペリエンス(UX)ってなに?
■ユーザは製品やサービスそのものより、エクスペリエンス(体験)に対して最も高いお金を払う
└コーヒーを淹れて、提供するだけであれば「50セント~1ドル」
└でも、洒落たカフェやホテルのラウンジでコーヒーを提供すると「2~5ドル」
└例えば、スターバックスはコーヒーだけでなく、落ち着いた内装、座り心地の良いソファ、洒落たBGMなど、体験全体を提供
▼最適なUXの構成を分解すると?
【1】ユーザの目に見える「ユーザインタフェース」がある
【2】ユーザインタフェースを剥がすと、その奥には「骨格」がある
【3】骨格は「構造」によって支えられている
【4】構造は「要件」から導き出される
【5】要件は「戦略」がもとにある
▼最適なUXを生み出すステップは?
【1】調査する
└ユーザの利用状況を把握する

【2】分析する
└利用状況からユーザニーズを探索する

【3】設計する
└ユーザニーズを満たすような解決策を作る

【4】評価する
└作った解決案を評価する

【5】改善する
└評価結果をフィードバックして、より良くする

【6】反復
└前ステップの「評価」と「改善」を繰り返す

▼2つの調査方法って?
【1】量的調査
└数値データやカテゴリデータを収集
└それを演算、集計して数値やグラフなどで結果を表す
└例えば、二千人分程度のデータから国民の傾向を統計的に推測する「世論調査」

【2】質的調査
└インタビューや観察といった数値化できないデータを扱う
└KJ法などを使って、データを分類・構造化して、文章や図で結果を表す

▼最適なインタビューでの調査方法って?
■「師匠と弟子」インタビュー
【1】インタビューする人はユーザーに「弟子入り」する
【2】ユーザは「師匠」として、普段のしごとを見せながら、インタビューする人に説明する
【3】インタビューする人は、不明な点があれば、その場で質問する
【4】一通り話しを聞いたら、インタビューする人は、理解した内容をユーザに話して、間違ってないか確認する
▼師匠と弟子インタビューのポイントは?
■インタビューする人は、ユーザが話す文脈から「質問を見つける」こと
■師匠となる人の、仕事に対する「技能や経験のレベル」を理解しておくこと
■「はい/いいえ」で答えられる質問ではなく、オープンな質問にすること
■例えば、家族構成について知りたい時は「あなたのご家族を紹介してください」など
■インタビューの順序は以下であること
【1】はじめはユーザのプロファイルや仕事の内容などの周辺情報
【2】徐々にメインテーマに近づいていく
【3】最後に関連するテーマに話題を移していく
▼インタビューのような質的データを分析するKJ法って?
【1】データの単位化
└適当なまとまりごとに、インタビュー結果の文章から重要な内容をピックアップする

【2】カード化
└1単位になった文章に「一行見出し」をつけて、カードにする

【3】グループ化
└すべてのカードを平面上に展開して、似たような内容のカードをひとまとめにする

【4】概念化
└ひとまとめにしたカード群に、そのグループの内容を適切に表す「グループ名」を作る

【5】再グループ化
└作成したグループ名に対して、グループの数が10個以下になるまで、グループ化を続ける

【6】図解化
└グループ相互の関係性を論理的に説明できるように、カードの位置の並び替え、矢印を引く、囲ったりを行う

【7】文章化
└図解化したカード相互の関係性を踏まえて、カードの情報を論理的な文章として書く

▼インタビュー調査とKJ法分析を行う目的は?
■サービスや製品に対する「ペルソナとペルソナが抱える要求」を導き出すことが目的
■ペルソナとは「ユーザをパターン化して、それを擬人化して、優先順位を付けたもの」
■通常、ペルソナは一つのプロジェクトで「3体~6体」
■ペルソナには必ず「優先順位」を付ける
■1位を「プライマリーペルソナ」、2位以下を「セカンダリーペルソナ」
■プライマリーペルソナの要求を完全に満たすために、プロジェクトを進める
■プライマリーペルソナとセカンダリーペルソナで要求が対立したら、プライマリーペルソナの要求を優先する
▼解決策を設計するためのブレインストーミングとは?
■ブレインストーミングとは、自由にアイデアを出し合うための「場づくり」のルールのこと
【1】批判厳禁
└誰かの発言に対する、反対意見は絶対禁止

【2】自由奔放
└どんな突飛なアイデアも否定しない

【3】質より量
└中途半端でも構わないので、とにかく数多く発案することを重視

【4】便乗歓迎
└人のアイデアにつけ足したり、アイデアをくっつけたりも自由

【5】視覚化
└フローチャート、グラフ、イラストなど絵を描く

【6】脱線禁止
└自由奔放とはいえ、議論のテーマから外れる発言はだめ

【7】一度に1人
└他の参加者が発言している間は、話に割り込まず、耳を傾ける

【8】Yes And話法
└イエス(そうですね)と他の人の発言を肯定した後に、否定せず自分の発言を付け加える

▼ブレストで出された解決案をまとめるには?
【1】KJ法
└関連するアイデアをひとまとめにする

【2】ポジショニングマップ
└例えば「実現性⇔新奇性」など軸を設けて、アイデアを分類する

【3】ドット投票
└参加者にシールを配って、一番良いと思うアイデアに投票する

▼3つのシナリオタイプって?
【1】課題シナリオ
└ユーザが抱える「課題」と、その課題が発生している「状況」を描くシナリオ

【2】作業シナリオ
└新たな製品やサービスによって、ユーザの仕事や生活がどのように変化するのかを描いたシナリオ

【3】情報シナリオ
└作業シナリオを具体化して、ユーザがどのような画面や情報を目にするかを描いたシナリオ
└通常の設計における「ワイヤーフレーム」や「サイトマップ」

【4】対話シナリオ
└ユーザが画面上でどんな操作を行い、そのときにシステムがどんな操作を返すかを描いたシナリオ
└通常の設計における「画面設計図」など

▼ユーザビリティ評価の2つの方法は?
【1】総括的なユーザビリティ評価「パフォーマンス測定」
└数十名のユーザに製品を使ってもらって「タスク達成率」「タスク達成時間」「主観的満足度」を評価する

【2】形成的なユーザビリティ評価「思考発話法を使ったユーザテスト」
└5~6名のユーザに、思っていることを口に出しながら製品を使ってもらいテストする方法

▼ユーザビリティ設計する上での10個のルールとは?
【1】システム状態の視認性
└システムは今ユーザが何をしているかを、常にユーザに知らせなくてはいけないというルール
└例えば「待ち状態を示す砂時計カーソル」「登録や購入完了を示す確認画面」

【2】システムと実世界の調和
└システムの専門用語ではなく、ユーザがほんとに使っている言葉を使用すべきというルール
└例えば「MacやWindowsのゴミ箱」「オンラインショップの買い物かご」

【3】ユーザコントロールと自由度
└いったん実行した操作結果の取り消しや、やり直しをユーザができるべきというルール
└例えば「動画コンテンツは自動再生しない」「大きい画像ははじめは小さく表示、クリックすると拡大できる」

【4】一貫性と標準化
└ユーザが同じように操作すれば、同じ結果が得られることを保証すべきというルール
└例えば「ページデザインを統一する」「リンクラベルとページタイトルを一致させる」

【5】エラーの防止
└エラーが発生してからの対処じゃなく、エラー発生そのものを防止する
└例えば「デフォルト値を指定する」「入力フォームの必須項目には印を付ける」

【6】記憶しなくても、見ればわかるように
└ユーザが記憶しないといけない内容を、なるべく少なくするというルール
└例えば「ポップアップヘルプ」「入力候補を表示するオートコンプリート」

【7】柔軟性と効率性
└ショートカット機能やカスタマイズ機能を提供すべきというルール
└例えば「キーボードショートカットキー」「検索でのオプション絞り込み機能」

【8】美的で最小限のデザイン
└無駄な情報を詰め込んでユーザを圧倒したり、混乱させるべきでないというルール
└例えば「関連情報はリンクで別ページに」「見出しをつけて、ページ左右の空白や行間を空ける」

【9】ユーザによるエラー認識、診断、回復をサポート
└エラーメッセージはわかりやすく、ユーザーが問題を解決できるようにすべきというルール
└例えば「つづりが間違っていたら入力候補を表示」「誤入力がある場合は、メッセージを伝えつつ項目自体を目立たせる」

【10】ヘルプとマニュアル
└マニュアルなしでも利用できるデザインにしつつ、さらにユーザを補助するためにマニュアルを用意する
└例えば「FAQを用意する」「文字だけでなくイラストや動画を用意する」

▼評価のためのユーザテストの方法は?
【1】ユーザに「タスク」(作業)を実行するように依頼する
【2】ユーザがタスクを実行する過程で「思っていることを言葉にしてもらいながら(思考発話)」その様子を観察、記録する
▼ユーザテストで観察すべき内容は?
【1】ユーザが独力でタスクを完了できるかどうか
└独力でタスクを完了できない場合、ユーザビリティとして「効果問題」がある
└効果問題とは、例えばECサイトで購入を完了できないなど、そのサービスが「使えない」ということ
└数値として「タスク達成率」で表すことができる

【2】タスクを完了するまでに無駄な作業を行ったり、戸惑ったりしないかどうか
└タスク完了までに遠回りをしていれば「効率問題」がある
└効率問題とは、例えばECサイトで何度もカート投入と確認画面を行き来するなど、そのサービス利用に「時間がかかる」ということ
└数値として「タスク達成時間」で表すことができる

【3】タスクを完了するまでの不満の有無がどうか
└タスク完了までに不愉快な思いをしていたら「満足度問題」がある
└満足度問題とは、例えば会員登録時に必要以上のプライベートな情報を求められたと感じ「不満をもらす」ということ
└数値として「難易度」「好感度」「再利用意向」を5段階/10段階で聞くことで、表すことができる

▼ユーザテスト実施の流れは?
【1】ユーザをリクルートする(2週間程度)
【2】テスト手法設計(数日程度)
【3】テスト実施(1日~数日程度)
【4】テスト結果の分析とレポーティング(1週間~2週間程度)

思ったこと

表面的な画面デザインの使いやすさを意識したユーザビリティの大事さに加えて、ユーザがあなたのサービスや製品を使うことを通して、どんな体験を実現できるかという、ユーザエクスペリエンスまで踏み込んでまとめられている本でした。

そして、ユーザエクスペリエンスやユーザビリティを計測するために、アンケート調査などの「量的に数値化できる方法」を取り入れるのではなく、インタビューによる調査や、ユーザテストによる評価など、質的なヒアリングを繰り返して行おうぜということを提案してくれています。

確かに、アンケートとかをやると簡単にデータが集まるし、加えて数値化がしやすいので、客観的に相手を説得するためには有効な気がします。でも、それだけに注力すると、どうしても「ユーザが何に満足して、何に不満をいだいたのか?」という文脈がごっそりと抜け落ちてしまうんでしょうね。

とはいえ、インタビューもユーザテストも、なかなか時間や予算の関係上でカットされがちな部分だったりします。でもだからこそ、たとえインタビューもユーザテストもできなかったとしても、現場に行って、あなたのサービスや製品を使ってくれている人に話しをきいて、その結果を受け止めて改善を繰り返すっていう、「対話」くらいはどんな形であれしていかなきゃですね。

あーWEBの世界に身をおいてると現場のちからを時々無視しちゃうし、時間がかかるからこそ、そういった現場から遠のく傾向ばっかりが強くなっちまってますね。気をつけなきゃ。

ありがとうございました!

関連する記事