$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

ユーザーニーズを理解する手法を学ぶ - 「はじめてのUXリサーチ」読んだ

最近、ユーザーのニーズを理解して定性的な意見から施策の優先度をちゃんと決められるようになりたいと思っている。そこでUXリサーチについて学習しようと決めた。そこでまずは「はじめてのUXリサーチ」を読んだ。

この本では質的リサーチの方法について、さわりの部分を全体的に学べる。何もわからないところからの入門として最適だと感じた。特にいろんな事例を交えて説明してくれることがありがたい。

個人的に印象に残ったのは以下の点。

  • UXリサーチには「何を解くと良いか、正しい問いを立てるため」の探索のリサーチと、「どのように解くと良いか、正しい解決策を作るため」の検証のリサーチがある。この二つは目的や状況に応じて使い分けたり、組み合わせたりする必要がある
  • インタビューなどで質的リサーチを入れることで、数値分析などの量的リサーチの仮説も妥当性の高いものになる
    • 気づき: 確かに量的リサーチをするときは、仮説立案段階ではある程度主観で決めるしかないのだが、その参考になるというのは良いと感じた
  • UXリサーチを行う前準備として、調査結果がどのようにプロジェクトで活用されていくかを明確にイメージしておくと良い
    • どのような意思決定を起こしてもらうことで、どのようにプロジェクトが前進するか
    • そのために、UXリサーチの「どのような結果」が「どのように共有される」と良いか?
    • 気づき: まずは報告の形式を考えるところから始めるのは確かに良さそう。ブログを書くときも「誰にどのような読後感を持ってもらうか」を先に考える方が良い記事ができるが、それに似ていると感じた

そのほかインタビューの具体的な質問の作り方、当日の進め方、インタビューテクニック、インタビュー後の分析手法などが解説されていて、実際にリサーチを行うときに参考になりそうな内容がたくさんあった。ユーザーのニーズを探す方法を知りたい人はPM・デザイナー・エンジニア問わず一度読んでみると良いと感じる。

読書ノート

- UXリサーチは探索と検証の2つ 32 ⭐️
- インタビューなどで質的リサーチを入れることで、量的リサーチの仮説も妥当性の高いものになる 26 ⭐️
- UXリサーチをするときは、ユーザーの生活や考え方を理解する時間も取る 26
    - ユーザーはどういう人なのか、どのようにサービスを使っているのか、どういう利用状況にいるのか
- 質的リサーチと量的リサーチを使い分ける 34
    - 質的リサーチはユーザーの考えを知れるが、量的にどの程度起こっているか分からない。たとえばうんざりしているというのが100人に1人しか起こっていないかもしれない
    - 量的リサーチは、どこで、何が、どの量で起こっているか調べられる。しかしなぜそのようなことが起きたかは分かりにくい
- UXを時間軸で考えると、サービスの利用前、利用中、利用後、利用全体の4種類の期間がある 38
- UXリサーチの対象は抽象軸と時間軸の2つの掛け合わせでマトリクスに整理できる 40
- UXリサーチを行う前準備として、調査結果がどのようにプロジェクトで活用されていくかを明確にイメージしておくと良い 82
    - どのような意思決定を起こしてもらうことで、どのようにプロジェクトが前進するか
    - そのために、UXリサーチの「どのような結果」が「どのように共有される」と良いか?
- 共有形式については、調査・分析に同席してもらう、レポートにまとめて共有する、調査結果を活用するワークショップをするの3パターンがある 83
- インタビュー当日のガイドを作るときは、調査の前後の流れまで含めてまとめておくと良い 92
    - どのように調査協力者を迎えるのか、最初の挨拶はどうするのか、謝礼をご案内するタイミング、最後にお見送りする時はどうするかなど
- UX調査企画書のテンプレート 95 ⭐️
- UXリサーチの手法 102
- インタビューの質問項目の作り方 105
    - あらかじめ立てた問いを明らかにするために、質問を思いつく限り書き出す。ひとつの質問を思いついたら5W3Hの観点でさらに広げる。そもそもどういう人なのか、どういう生活をしている人なのかなどの趣味嗜好や生活を理解する質問も入れる
    - 質問項目を分類してトピック名をつける
    - トピック名から優先順位を決める
- ユーザーインタビューの序盤・中盤・終盤の流れ 111
- インタビューテクニック 112
- KA法による質的データの分析 138
    - 元データの参照番号を書く
- UXリサーチを導入するには、引き込みたい相手の視点から語り、UXリサーチと言う単語を使わない 158
    - 事業上にxxと言う課題があり、それを解決するにはxxを明らかにする必要がある(からUXリサーチを活用する)

サービス開発の施策に納得できない時にエンジニアができるアクション

サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。

このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。

そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。

納得できないケースは大まかにどのようなものがあるか

納得できないケースでは大まかに2つのケースがあるのかなと思っている。

  • (1) 施策をしたい目的や仮説自体に納得できていない
  • (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない

1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか?」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか?」「この指標に繋がると言っているが、繋がる理由がわからない」といったものだ。

2つ目は、たとえば「目的は良さそうだけど、課題解決の手段になっていなそう」「この手段を実装しようとすると半年かかってしまうため、施策のインパクトに見合わないのでは」といったものだ。

それぞれアクションが全然異なるので、アクションを起こす前に何に納得できないかについては自分の中でちゃんと言語化しておくと良い。

ではこのような時にどうアクションすると良いだろうか。

大前提: 施策の草案を作ってくれた人に敬意を持つ

ここで話が少し逸れるが、何らかのアクションを起こす前に大前提がある。それは施策の草案を作ってくれた人に敬意を持つことだ。アクションを起こすにあたって、喧嘩腰で行動する・嘲笑気味に行動するなど、敬意のない形で提案しても何も進まないことが多い。

まず第一に敬意を持ち、相手は自分の知らなかった情報を持っているからこの施策案が出ているのではないかなどと考え、謙虚な姿勢で臨むと良い。

目的や仮説自体に納得できていない時のアクション

自分がよくやっていることを2つ挙げてみる。

目的や仮説について質問する

ここが間違っているのではないですか?みたいに正論をぶつけるのではなく、施策の目的や仮説がより明瞭になるように質問を繰り返す。以下のような部分が明らかになるように質問をしている。

  • どういう層のユーザーが
  • どの程度の人数がいて
  • そのユーザーたちはどういう課題を感じていて
  • 課題を解決することでどういうユーザー体験となり
  • その結果サービスのどの指標にどの程度繋がるか

仮説の妥当性が精緻に検証されている必要はなく、まず言語化してもらうことが大事。言語化できれば、エンジニア側でその仮説の妥当性を事前に検証することもできる。

仮説の妥当性を示す数字を出す

仮説が言語化されているなら、エンジニア側でその妥当性を数字で出してみると良い。自分が納得できていない部分が「対象ユーザーの数」なのであれば、その数を調べることで仮説の妥当性が検証できる。

この時、フラットに検証するように心がける。納得できない時は反証を探してしまう傾向にあるが、自分の直感に反して仮説が妥当ならそれで良いのだ。

達成する手段に納得できていない時のアクション

こちらも2つほど挙げてみる。

手段を実装する概算工数を知らせる

施策案が膨大な規模になっていて実装工数が大きすぎると感じた場合は、PM視点では工数が大きいとは思っていなかったというすれ違いが発生していることが多い。そういう場合はエンジニア側で概算工数を出すことで、PMが再検討しやすい状態にできる。

目的を達成する最小のスコープを提案する

概算を出した上で、目的を達成する最小のスコープをエンジニアから提案しても良いだろう。最小スコープの提案はエンジニアの得意領域だと思う。たとえば「ブログのアクセス数をグラフィカルに時系列で可視化したい」みたいな施策案があった時、「まずは直近7日のアクセス総数を出すだけで仮説を検証できませんか?」と提案するようなものがあり得る。

この時、PMにとって手段の中のどの部分が重要と考えているかを先にヒアリングしておくと、より良い提案になるだろう。

提案するときは以下のポイントを押さえておくと良い。

  • なぜそのスコープで目的を達成できると考えているか
  • そのスコープだと、ユーザー体験としてどういうデメリットがあり得るか
  • 施策案として提案された手法と比較して、どの程度実装工数が異なるか

まとめ

サービス開発時に施策案に納得できない時にエンジニアからどうアクションを起こすかの例を記事として書いてみた。端的にいうと、何が納得できないかを自分で言語化し、施策案を考えた人に敬意を払って、前向きに提案すると良い。

画面リニューアルの時には本番データを使ってモックを作れるFigma Google Sheets Syncが便利

最近画面リニューアルの仕事をした時に、本番データを使ってモックを作れるFigma Google Sheets Sync Pluginを使い、非常の便利だったのでまとめる。

画面リニューアル時のよくある失敗

何らかのユーザー体験を満たしたく画面リニューアルを計画することがある。その時まずはFigmaなどを使ってモックを作り、PM/デザイナー/エンジニアで認識合わせをしながら進めることが多い。モックが良いとなれば、それを参考に実装してリリースすることになる。

一方、モックは良いと考えたのに実際にリリースして本番のデータが入るようになったら思ったものと違い、想定したユーザー体験を満たせなかったという失敗を何回か経験した。たとえば、モックで考える時は理想的なデータや多様性のあるデータで考えてしまい、実際の本番データが入ると違っていたみたいなケースだ。こうなるとユーザー体験を満たすために追加で開発するか、もしくは多少微妙なユーザー体験で妥協するという結果になってしまう。

Figma Google Sheets Sync Pluginでモック時点でリリース後の姿を見えるように

もしモック時点で本番データを当てはめることができれば、その段階でリリース後の姿を具体的にイメージしながら話すことができるはずだ。そこで使えるのが本番データを使ってモックを作れるFigma Google Sheets Sync Pluginだ。

このプラグインは、次のような3ステップで簡単にFigmaのモックにデータを入れることができる。

これだけでExamplesに載っているようなモックを作ることができる。

あとはこれを応用することで本番データを入れられる。自分の場合はRedashで本番データからリニューアル画面に当てはめたいデータを作り、Googleスプレッドシートにインポートし、プラグインを適用する方法を取った。また少し凝ったモックを作るためにSpecial data typesShow / Hideなども活用した。

まとめ

今回は、モックでは良いと思ったけどリリースして本番データが入ったらイメージと違った...となるのを防ぐため、Figma Google Sheets Sync Pluginを使いモック時点で本番データを使って確認する方法について記事を書いた。

開発のできるかぎり早い段階でリリース後の姿を確認できるツールとして非常に便利なのでおすすめ。