# はじめてのUXリサーチ
###### tags: `デザインの勉強`
https://www.amazon.co.jp/dp/4798167924

- 全体構造
- Chap1-2: 心づもり、基礎知識
- Chap3:　設計の仕方
- Chap4:　手法の説明（調査・分析）
- Chap5-6: 拡張のための仕組みづくり
- Chap7: 実例紹介
- Chap8: 社外への共有

## Chapter1 UXリサーチの捉え方
- なぜ大事
- 体験の品質が重要: 情報の流動性、プロダクトはすぐ模倣される
- 市場変化が激しい
- ユーザーの多様性が高い

- メリット
- リリース前に小さく失敗しながら学びを増やせる
- データ解釈の精度を上げられる
- 組織づくりに使える: サービスのあるべきを考え直すきっかけになるので、そこからチーム間のコミュニケションや再編につながる

- ポイント
- 仮説検証だけでなく、ユーザーの生活を理解する時間を20-30分取る
- 共通のユーザー理解につながる
- リサーチすることではなく、それ起点に議論・意思決定されることが重要

- UXリサーチの分類
- 探索、検証のリサーチ
- 探索: 正しい問いを立てるためのリサーチ
- 検証: 正しい解決策を立てるためのリサーチ


- 量的リサーチと質的リサーチ
- 質的の代表例　デプスインタビュー
- 組み合わせ方の例
- 質でインサイト得る→量で頻度確認
- 質的は個人の解釈入りやすいので扱い方気をつける
- 量的リサーチは主観(アンケートなど)と客観(行動ログなど)がある。主観はユーザーの考えを知るのに向いてる。行動ログは正確な値を得るのに向いてる

- 何をどこまでやるか：　5x4のマトリクスで分析
- UXの階層構造(情報の抽象度)：戦略、要件、構造、骨格、表層
- 今自分たちがどのレイヤーを考えてるのか？
- 例：ナビゲーション -> 骨格
- 表層は本当に見た目
- 抽象度が高いレイヤーの方が難易度高い
- UXタイムスパン: 利用前、利用中、利用後、利用全体

- UXリサーチとマーケティングリサーチの違い
- 当事者(not利用者。サービスの原点になる悩みを持っている人)個人を理解するか、市場という全体を理解するか
- 個人のことを深く追求し、個人の間の共通点・違いを理解していく
- 起点の目的は違うがお互い補い合える存在
- 定義理解に囚われず、小さく始めてみるのがよし

(感想)絶対的な解を解くものじゃない、人によって着眼点や深掘りポイントが違うもの。

## Chapter2 UXリサーチをはじめるために
- UXリサーチの目的を明確にしておく。リサーチが目的になるとだめ
- 気負わない．相手のことを知りたい気持ちと、相手に対する尊敬を忘れなければOK。実践しながら改善！
- まずは30分話を聞いてみるとこから
- 使ったことないユーザーに対して、操作をしてもらいその画面を撮る
- UXリサーチしよう！というスタンスではなく、ユーザーのことを理解しよう(思い返せばUXリサーチしてた)くらいのはじめ方で

### どのようなUXリサーチから始めるのがいいか？
1. 探索のリサーチ: 何を解くべきか特定するためのリサーチ
- どんなときにやる？
- 課題がなにかわからないとき
- 課題の優先順位がわからないとき
- ユーザー理解が足りないとき
- サービス知ったきっかけ、なぜ使ってくれてるのか、時系列で使い方を聞く
- 例: ユーザーインタビュー、現在のプロダクトを使ったユーザビリティテスト

2. 検証のリサーチ
- どんなときにやる？
- 課題が明らかで、解決策のアイデアもあるとき
- 例: コンセプトテスト、プロトタイプでのユーザビリティテスト

3. 既にあるデータの活用
- 過去データの読み込み

### UXリサーチの成功とは
- UXリサーチ成功の定義は難しい
- 調査がうまくいっても活用がうまくいかない場合もある
- ひとつでも前進したら良いと捉える
- 改善したい点はやっていくうちに改善したらいい

### より良いUXリサーチを目指す工夫
- ウォークスルーをやってみる
- 自分の言動を録音や録画で振り返る
- 他の人にフィードバックをもらう
- 他の人のやり方を学ぶ。モニター体験もよし

## Chapter3: UXリサーチの組み立て方

### UXリサーチの組み立てについて
- やることは大きく2つ
- パート1:なぜやるかを明らかにする
- 状況理解した上で問い立案し、結果活用をイメージする
- パート2:どうやるのかを決める
- 1回で決めるのではなく、これらのパートを何回か反復する

- UXリサーチには7つのプロセスが、これの①-③に当たる

①状況理解: プロジェクトの状況を場合して、なぜUXリサーチが必要か明確にする
②問い立案: UXリサーチで解決したい問いを明確にする
③手順設計: リサーチの全体手順や手法を考える
④調査準備: モニター募集や機材準備を始める
⑤調査実施
⑥データ分析: 洞察を得る&他の人に伝えるためにまとめる
⑦結果活用:調査結果や洞察を他の人に伝える


### ①-③：組み立てるフェーズの詳細
#### ①状況理解
- プロジェクトの状況: どういう目的で、どういうことをしようとしてるか。どんな判断材料が欲しいか
- リソース: UXリサーチに当てられるヒトモノカネ
- 権限

#### ②問い立案
- 身の丈に合った問いを立てる。そのために『明らかにしないこと』を明確にする
- 例　「eKYCの利用前や利用中に、ユーザーが使いづらい、使いたくないと感じる要因はなにか？」

- 結果の活用を考えるには <- これが大事
- 調査結果がどのようにプロジェクトで活用されていくのかを明確にイメージする
- 何を明らかにすることでどのような意思決定を起こしたいのか、どのようにプロジェクトを前進させたいのか関係者と話し合って、結果の活用イメージの共通認識を持てるようにしておきましょう
- この活用に応じて適切な手法が変わってくる
- 活用イメージに合った手法が見つからないときは問いや活用イメージを描き直す
- アウトプットイメージをつくる
- 共有相手と共有方法を整理

#### ③手順設計
- 調査対象を考える: 問い(知りたいこと)によって適切な対象者は変わる
- 調査・分析手法を学ぶ: 詳細は4章。インタビューなら質問項目や時間配分を決める
- どのようなスケジュールで進めるか
- どのように調査を実施するか
- ガイドをつくる。(説明事項や質問事項を書いた「これがあれば他の人でもリサーチ実施できる」もの)
- 実際社内で模擬でやってみてブラッシュアップする

コラム

調査企画書を作ったほうがよい。
目的がブレにくくなる、抜け漏れなくなる、次につながる

## Chapter4: UXリサーチの手法を知る

### 調査手法
#### ユーザーインタビュー
- 組み立て方
- デプスインタビュー(1対1): UXリサーチでは一人一人の意見を理解することを重視するため、この利用が多い
- グループインタビュー(1対N)

- 事前に質問することをどれくらい決めるか
- 構造化: 一問一答、事前に用意した質問以外はしない
- 半構造化: 事前に質問用意するが、流れで柔軟に変える。構造化よりスキル必要
- 非構造化: 質問項目を用意しない。高いスキルが必要、分析難しい。

- 質問項目の検討
- まず質問項目を思いつく限り書き出す(質より量)。1つ質問を思いついたら、5w3hの観点で広げる
- where（どこで）
- how（いかに）
- what（何が、何を）
- why（なぜ）
- how much（いくら）
- when（いつ）
- who（誰が、誰を）
- how often（どのくらいの頻度で）
- サービスに関してではなく、どういう人か・どういう生活をしている人か...など調査協力者を理解する質問も重要
- 質問項目のグルーピング
- グループごとの優先順位決め&順番決め。優先度低いのは削り時間内に収まるように。ウォークスルーしながら調整。後続質問にバイアスかけてしまう質問順になっていないか？

- 調査実施
- 序盤: 協力者に不利益を与えないよう、参加同意を得る
- 書面で同意を得る
- どのようなデータを取得するのか
- データの保管方法などの取り扱い
- 取得したデータに対する権利・利用範囲・利用目的、参加が任意であること
- 中断・中止による不利益が発生しないこと　...など
- （未公開の情報を調査協力者に見せる場合) 秘密保持契約

- ポイント
- 中立な立場で臨む。
- 欲しい回答に誘導しない
- 割った入ったり反論したりしない
- 「つまりこういうことですよね？」と要約しない⚠️

- いきなり本題に入らず軽い世間話でアイスブレイクするのも良い

- 中盤
- インタビュアーの発言は最小限に⚠️
- 脱線しすぎず、予めの質問項目を聞き切るよう調整

- 終盤
- これまでの解釈が間違ってないか確認
- 聞き忘れたことや、追加で聞きたくなった質問をする
- 最後に言っておきたいこと/サービスに伝えたいこと　を聞くと、思いがけぬ本音が聞けるし本人の満足度も高まる

- 終了時
- 必要な説明事項を忘れずに伝える（謝礼の手続きや、何かあった際の問い合わせ先など）
- 手続きがない場合は「これ以上のお手続きは必要ありません」と伝えておくと安心感につながる

#### ユーザビリティテスト
- ユーザビリティとは？
いろんな定義があるが、有名なヤコブニールセン氏の定義

●学習のしやすさ 　ユーザーがそれをすぐ使い始められるシステムか 　簡単に学習できるようになっているか 
●効率性 　一度学習すれば、あとは高い生産性を上げられるか 　効率的に使用できるようになっているか 
●記憶のしやすさ 　ユーザーがしばらく使わなくても、再度使用する際にすぐ使えるように覚えやすくなっているか 
●エラー発生率 　エラーの発生率を低くできているか 　エラーが起こっても回復できるようにし、かつ致命的なエラーは起こらないようになっているか 
●主観的満足度 　ユーザーが個人的に満足できそうか 　ユーザーが楽しく利用し、好きになれそうか

- 目的
- リリース前に行う場合: プロトタイプや開発環境。サービスフローに課題がないかを確認、特定機能の使いにくさ改善
- リリース後に行う場合: ユーザーの利用実態の把握、ログ的に問題ありそうな部分の調査

- 組み立て方
探索と検証どっちにも使えるので、どっちにするかによって設計を変える。探索なら案をいくつか準備して当てる。検証なら案を1つ持っていく

- タスクとシナリオを実行する
- ユーザビリティテストはユーザーに何かタスクを実行してもらうテスト
- やってほしいタスクを言語化する
- タスク中特に気をつけてみたいポイントも言語化

- 時間目安
1機能あたり20-30分

- 対象者について
- 対象を選ぶより気軽に反復できる方が大事(ユーザビリティはどんな人にも関わること)
- 1回に人数はそんな要らない。5人くらいを繰り返す
- 有名な話として、ヤコブ・ニールセン氏の「5人のユーザーでテストすれば、ユーザビリティ問題の85%を発見できる」という説がある

- 実施手順
- ①事前インタビュー
協力者自身のこと、タスク経験(経験あるからできたのか、完全初心者だけどできたのか)
- ②タスクの実行
シナリオやタスクを説明し、タスクを実行してもらう。それを観察する
- ③事後インタビュー
タスクの感想。観察時に気になったことを聞く

##### 実施時のポイント
- 思考発話をお願いする: 独り言みたく、操作時に考えてることを発言してもらう。どういうことを考えてるのか、悩んでいるのか
- グッと堪えて観察する: 使い方を勘違いしてたり、操作に苦労してたりするとサポートしたくなるが🆖　もし操作方法を質問されても、協力者自身で考えてもらうよう促す「合ってる合ってないは気にしなくて良いので、あなたのイメージを教えていただけますか？」
- 目撃者を増やす: 記録しておいて事後に共有する

##### 注意すること
- 準備は念入りに: ウォークスルーマスト
- タスク実行順序に注意: テストしたいタスクが複数あるとき、まっさらな状態でやってほしいタスク/他タスクの前提条件があって操作しても問題ないタスクを分けて順番を設計。また、2つの案を並列に検証するのは難しいので参考程度に
- 良い悪いの結果にとらわれない: タスク完了率などより、学びを得るのが大事

#### コンセプトテスト

実際にサービスを作り始める前に現状の仮説やアイデアがユーザーのニーズを満たす可能性があるのか、魅力的に思ってもらえそうなのかを検証できる調査手法
- 形式: コンセプトボード、ストーリーボード、ビデオなど様々
- メリット: 早い段階で工数をかけずに仮説検証が行えること

想定ユーザーにこのコンセプトボードを提示して、「利用シナリオのような悩みを実際に抱えているのか？」「本書でできることは、お悩みに答えられるのか？」などを検証する

#### 実施手順
- ①事前インタビュー
その分野にどれくらい知識、経験があるか？など

- ②コンセプトの提示
コンセプトを読んでもらい印象や疑問点を自由に話してもらう

- ③コンセプト評価
事前に用意していた評価軸でコンセプトを評価してもらう
例： わかりやすさはどうでしたか？５段階評価、どれくらい使ってみたい？5段階評価

##### 注意点
- 具体的エピソードを聞きながらニーズを探る
- 具体的にどういうときに使いそうか、どれぐらいの頻度で発生しそうか、代替手段はあるか、...などユーザーの生活背景
- そう考える背景になった経験など

#### アンケート
- どういう時使うか: 量的比較、集団の調査や比較

- 組み立て方
- 計画を立てる
- 対象者を選ぶ: 事前にアンケートとるなどしてスクリーニングする
- 必要な回答が得られるよう、回答率を考慮して配信数を聞く
- 質問を設計する　

- 実施手順
- アンケート実施
- 結果分析

- 注意点
サービスへの印象が良い人は回答集まりやすい、というバイアスを忘れずに

#### フィールド調査
探索の調査に向いてる。サービス利用の全体像理解にも繋がる

- 参与観察: 調査対象の生活に入り込む
- 訪問調査: 調査対象を訪問
- 行動観察: 行動の背景はわからないのでユーザーインタビューと組み合わせるのあり

#### ダイアリー調査対象
探索のリサーチ、サービス利用全体像を理解するのによい
調査対象者に、利用状況を1週間記録てしてもらう

### 分析手法(質的調査の)
#### KA法
①KAカードに顧客の発言、行動を書き出す
②各カードの心の声を推測する
③各カードに、心の声から価値を推測して書く
④モデリング: カードどうしをグルーピング〜関係性をまとめる

#### SCAT
- 小さな質的データの分析に向いている。小数ユーザーを深く分析するときなど。
データをまとまりで切り、コーディング（区切ったテキストに”コード”をつけていくこと）する

コーディング手順
1. データの中の注目すべき語句を抜き出す
2. 1を、より一般的なデータ外の語句で言い換える
3. 2を説明する語句を書き出す
4. 1-3で浮かんできたテーマ・概念を記述する

4のテーマ・概念を膨らませてストーリーラインを記述
→そこから理論を記述

#### mGTA
じっくり時間をかけて人の行動や考えを理解するための手法
時間がかかるのでUXリサーチの実務にはあまり向かない

#### KJ法
じっくり時間をかけて人の行動や考えを理解するための手法
時間がかかるのでUXリサーチの実務にはあまり向かない

#### ペルソナ
UXリサーチで得た洞察をペルソナとして表現することで、リサーチに参加していなかった他の関係者に伝えるのに役立つ
ペルソナを作ることを目的とするのではなくサービスづくりに活かすためにペルソナにどのような情報が 必要なのかを意識する
一度作って終わりではなくアップデートし続ける

#### カスタマージャーニーマップ
顧客の体験を俯瞰してみて新しい課題を発見する・全体的な視点で課題をとらえ直して優先度をつけたりするのに役立つ
部署間をまたいで理解・議論をするため

#### サービスブループリント
顧客にかかわる一連の流れ（システム側含め）を、客観的に把握したいときによい。複数間のステークホルダーがいるとき

## Chapter5: UXリサーチを一緒にやる仲間の増やし方
あまりOCには関係なさそうなのでスキップ
OCでも使えそうなことだけ

- 関連ミーティング
- キックオフミーティング
- 関係者の目的に対してUXリサーチがどう役に立ちそうか、どういうリサーチをすると良さそうかを共有
- リソース・スケジュールをベースに具体的な進め方・誰がどこまでかかわるか認識合わせ
- ラップアップミーティング
- 速報ミーティング
- 詳細なデータ分析をする前に、協力者がどういう人だったかを共有
- 呼ぶのは中心関係者のみ
- 熱いうちに次のリサーチへのヒント（気になるところ、深掘りたいポイント）を出しておく
- 報告会
- 分析した結果・得られた洞察を共有
- 関係者全員に幅広く
- 調査結果や得られた知見は参照しやすい形でまとめておく

## Chapter6: UXリサーチを活かす仕組みの作り方
UXリサーチを継続し、もっと活かしていくためには
- ResearchOpsとは
- リサーチの運用を品質高く続ける仕組みづくりのこと
- 6要素ある
- リクルーティングの効率化：調査協力者の募集・選定・管理・謝礼支払いなどのプロセス効率化
- ガバナンス：安全で倫理的な調査を行うために、同意書の用意やプライバシー配慮、データ保管に関するプロセスやガイドラインの作成
- ツール：ツールやプラットフォームの戦略的な調達管理
- ナレッジマネジメント：調査で得た知見を扱うプロセス・プラットフォームの管理
- コンピテンシー：誰でも調査ができるようにするためのガイド、テンプレ、トレーニング、オンボなどの整備
- 広報活動：社内でUXリサーチの価値を共有・広める活動
- 実践例
- リクルーティングの効率化
- プロセス全体を把握し、それぞれのやり方を型化
- 各プロセスのタスクを洗い出し、発生頻度・所要時間を書き出す
- 調査協力者のデータベースを構築する
- アンケートなどの型化や、効率化ツールの導入
- ガバナンス
- 案内すべきことの決定
- 同意書の準備
- 個人情報の管理ルールを作る
- ツール
- ソフトもハードも
- ナレッジマネジメント
- コンピテンシー
- 誰もが気軽にUXリサーチを始めるよう、一歩目のハードルを下げること
- テンプレ、マニュアル、学習コンテンツを整備
- 広報活動

## Chapter7: UXリサーチのケーススタディ
### ①利用上限金額の設定機能（メルペイスマート払い）
#### 状況
- 事前調査をもとに「クレカなどの後払いは使いすぎてしまいそう」という課題感があることが分かっていた
- サービスの開発（立案）が進んでいる状態
- リサーチの問い「課題感解消にはどのような機能を備えればいいのか」

#### 組み立て方
- 問いを3つに分解
- ①不安を感じる要因は何か
- ②要因を解消する機能はなにか
- ③↑の機能のわかりやすさ・使いやすさ改善
- コンセプトテストとユーザビリティテストを組み合わせて実施

#### 準備・実施・分析の進め方
- ①②の調査：サービスコンセプトをテキストで提示して「不安を感じるか」「感じるならその原因」を調査
- 調査結果をもとにアイデアを得て、再度コンセプトテスト -> 解消できることを確認
- ③の調査：デザイナー作成のUI案をもとに、ユーザービリティテスト


### ②maruhadaka PJ
#### 状況
- 機能をリブランディングしたタイミングで、認知・利用実態を把握するために実施

#### 組み立て方
- 関係者が多く、各々知りたいことが違った -> 発散させたうえでスコープを絞る
- キックオフミーティングで関係者でテーマについて話し合い、リサーチのスコープを決定
- スコープ
- リサーチ前後を点でとらえるのではなく、生活文脈を線で深く理解したうえでメルペイの位置づけを探る
- 中核の問「リブランディング後に利用頻度が増えたのはどういうお客さまなのか」

#### 準備・実施・分析の進め方
- デプスインタビュー
- 目的（利用歴を線でとらえた上で点を不可ぼっていく）から考えて、「簡単なジャーニーマップを協力者と一緒につくって」「そのあとで深掘りする」方式

- ダイアリー調査
- 明らかにしたいことを言語化しフォーマットを決める
- 形式（紙・専用ツール・LINE）を決める

- 関係者が多いのでキックオフ/ラップアップmtgは丁寧に行う
- ラップアップmtgの内容 <- 具体のエピソードを深く共有することに驚き
- 振り返り10分：調査協力者を振り返り印象的なエピソードを５つ付箋に書き出す
- ダウンロード30分：エピソードを紹介しあい調査協力者の理解を深める
- テーマを決める20分：共通点・もっと深掘りしたいテーマを議論

### ③おくる・もらう
- UXリサーチでやったこと
- 新規事業コンテストのための戦略検討
- 要件検討
- マーケプラン検討

- 戦略検討
- アイデアをもとに、コンセプトボードでコンセプトテスト
- 利用シーンも探っていき、戦略提案に活用

- サービス検討
- プロトタイプで要件~UIを検討
-

- マーケプラン検討
- キャンペーンのコンセプトを、複数案テキストで提示して比較してもらう

### ④定額払い
- 新機能、思い付きレベルでアイデアすら固まっていない状況
- プロジェクト状況が流動的なので、柔軟にリサーチ & 結果提供する方針で進める

#### 組み立て方
- デプスインタビュー
- 他社既存サービスの体験について、知見が不足している
- 問「購入代金を月々に分けて支払うサービスを使った体験にはどのようなものがあるか？」
- 事前に社内で他社サービスを使っている人を集めて調査　→　質問項目をブラッシュアップ

- 価値の構造化・ペルソナ像作成
- デプスインタビューで複数の体験タイプがあることがわかったので、KA法で分析して価値を構造化
- 価値の感じ方をもとにペルソナを4種類作成

- デザインスプリントで、3h*5日間かけて「どのようなアイデアを実現するか」を明らかにした
- asisの理解：他社サービスで「価値になっている体験」「悪い体験」の認識を合わせる
- アイデア出し：「asisをどう変えるのか」
- ユーザーにとって価値高く、サービス競争力につながるものを選出
- 利用シナリオ・手書きのWFを作成

- コンセプトテスト
- 問「お客さまの不安を払拭し、定額払いを安心して使ってもらえるような機能とはどのようなものか」
- 簡単なプロトタイプ&コンセプトボードで不安を軽減できるか検証

- 要件・UI作りこみ段階でユーザビリティテスト
- 問「今までにない機能の理解のしやすさや使いやすさを担保するにはどうしたらいいか？」

### ⑤初期設定フロー
#### 状況
- iD初期設定フローが他サービスにはない機能だった
- 設定すれば便利だが、設定には時間がかかる
- 問「初期設定フローのどの部分で、どのような不安を感じる可能性があるか？」

#### 組み立て方
- リサーチャーの稼働が限られていたので、新しく調査をするのではなく蓄積されていた質的データを分析
- どの時点で設定をやめているのかのログ（量的データ）はとれていたので、それと突き合わせる方針
- 質的データから「不安」に該当する文言を抽出 → 不安のタイプ/いつ感じるのかで分類
- 設定をやめるステップではなく、その前から不安が蓄積して中断に至ることが判明

### ⑥Weekly UXリサーチ
- 毎週・隔週でUXリサーチ枠を用意
- 1回90min * 4回
- 何をするかは柔軟に決める

- 具体的な仕組み
- 一番最初：外部に委託。実際にピックするところだけ社内でやり、事前アンケートや謝礼回りなどはすべておまかせ
- 内製化：リサーチアシスタントを採用し、コスト削減
- 効率化：スクリーニングアンケートで幅広い質問をしておくことで他のpjtとも協力者リストをシェアできるように

### ⑦リモート UXリサーチ
- 対面リサーチではできていたことができなくなる
- プロトタイプを端末で直接操作してもらう
- 横で操作の様子を見る
- 不完全なプロトタイプを手動で画面遷移させる
- 詳しく聞きたい画面について手動でプロトタイプ遷移させる ...など
- 仕組み：いろんなツールがあるので一例。pjt状況に合わせて選ぶべし
- リモートデスクトップでやる
- 調査する項目を絞る
- ○ 情報構造に関するユーザービリティテスト
- 情報を理解できるか
- 次に何をすればよいかわかるか
- 不安になる情報はあるか ...など
- × UIの細かい操作感についてのユーザービリティテスト

## Chapter8: UXリサーチの実践知の共有
これも現段階にはあまり関係ないのでスキップ