事業の成功率を上げるUX/UI検証 実践編~プロジェクト後期~
こちらの記事はプロジェクト中期段階で行うUX/UI検証のご紹介です。
プロジェクト中期は検証的調査を行います。
プロジェクト初期から見たい方はページ下部にリンクがございますので、そちらからご確認ください。
プロジェクト後期段階
プロジェクト後期ではここまで実施してきたデプスインタビュー・受容性調査の結果を基に、実際のプロトタイプに落としていきます。今回はUX/UI検証のお話しのため、体験からデバイスへの落とし込み（情報設計・UI設計）はどこかでまたご紹介致します。
ユーザーテストの設計方法
情報設計・UI設計をして、ある程度プロトタイプが出来上がったらユーザーテストを実施します。ユーザーテストは主に以下の要素を検証していきます。
ユーザーは与えられたタスクを迷わず達成できるか
(機能性・操作性・単純性)プロダクトに触れて心地よい体験ができたか
(信頼性)プロダクト内の各機能はユーザーにとって効果的だったか
(利便性)
以前書いた記事でも紹介していますが、良いUXにするには機能性・操作性・単純性・信頼性・利便性をデザインすることが重要です。この5つの指標を測るために上記３つの要素を明らかにしていきます。
1.ユーザーは与えられたタスクを迷わず達成できるか
（機能性・操作性・単純性）
ユーザーテストを行うためには２つ用意するものがあります。
一つ目は実際操作できるプロトタイプ。このプロトタイプはエンジニアがコードを書いてプロトタイプ化したものではなく、Figma上でデザイナーがプロトタイプ化したものを指しています。
ユーザーテストの段階で完璧を追い求めすぎるのはやめましょう。どうせテスト後修正するので、修正する時に一番スピーディーに修正反映できる状態のプロトタイプを使用することがベストです。
用意するもの２つ目はスクリプト（質問表）です。スクリプトは被験者にどういうタスクを与え、どんな画面を表示し、何をヒアリングするのか具体的に書かれたものになります。スクリプトには以下を記載してください。
▼ユーザーの状況説明
例：あなたは今時間があるので漫画アプリで漫画を探そうとしています。
▼デバイスを使って操作して欲しいタスク
例：〇〇という漫画を購入してみてください。
▼タスクを完了した時の感想
例：一連の流れを体験してみてどうでしたか？
▼各画面の仮説に紐づいた質問
例：（仮説）漫画購入時に暗証番号を入力させた方が安心なのではないか。
（質問）漫画購入時に暗証番号を入力する機能はどうでしたか？
上記４点を予めスクリプトに記載して用意しておくことで、迷わずタスクが達成できたのか、自分達が考えている仮説は立証されるのか検証できます。
テスト被験者への聞き方は、最初に状況を説明し、タスクを渡して、自由に操作してもらい、スムーズに達成できるのかを観察した後に、一連の流れを細かくヒアリングするのが良いです。
観察中に「あ、ここで迷ってそう」「関係ないボタンをタップしてる」という事象が起きたら、それはその被験者にとってユーザビリティが良くないというファクトなので、なぜそのような反応・行動になったのか深掘りしてください。ファクトに対して理由を深掘りすることで、被験者の5人中5人が迷ったら改善すれば良いし、被験者の5人中1人が迷ったらなぜその人だけ迷ってしまったのかを理由やその人の普段の生活などから考えて、改善またはそのままにするのか議論できます。
スクリプト作成の注意点
プロのデザイナーでもよくやるのですが、スクリプトを作成する際に仮説もないのに質問文を作ってヒアリングしようとしていることがよくあります。探索的調査の場合は仮説がなくとも被験者自身の深掘りするために必要なことではあるんですが、検証的調査の場合は仮説から出来上がった操作・機能がどのような反応をされるのか検証するのがメインなので、仮説と質問はセットで考えることをおすすめします。
そうすることで検証後のレポーティングも楽になります。
以下の仮説があったとします。
「漫画購入時に暗証番号を入力させた方が安心なのではないか。」
その仮説を検証するために質問内容を
「漫画購入時に暗証番号を入力する機能はどうでしたか？」
にしたとします。
そして回答が5人中4人がいらないと答えて、
「漫画は高額取引じゃないからそこに安全性は必要ないし、それよりもボタンひとつですぐに読みたい」
という回答が返ってきたら、以下のように検証後のレポーティングには仮説に対しての評価数値とそれに紐づく理由が付与できるようになり、ユーザーテストを聞いてない人でも簡単に検証結果が理解できます。
仮説
「購入時に暗証番号を入力させた方が安心なのではないか。」
結果
欲しい 1人
いらない 4人
理由
「すぐに読みたいのに1ステップ挟んで欲しくない」
「高額取引ではないので漫画アプリに安全性は求めていない」
「生体認証なら良いかもだけど、暗証番号を入力するのはめんどくさい」
2.プロダクトに触れて心地よい体験ができたか（信頼性）
この観点は1の「迷わずタスクを達成できたのか」と同時に深掘りします。タスク完了後に「一連の体験どうでしたか？」という質問でそのユーザーがどれだけ心地よく使えたのかヒアリングします。
ただしこの信頼性を問う質問は、その人のブランドへの信頼度合いによって答えが変わることがあります。
例えば銀行アプリを使って送金する時に毎回認証をする機能を入れたとします。
「〇〇銀行は昔から使ってて大手だし信用してる分、毎回認証してもらって安全性を担保して欲しい」
という場合もあれば、
「〇〇銀行はネット銀行で使いやすさ重視で利用してるだけだから、使いやすさ重視で認証はいらないかなー」
という回答が出てきたりします。
そのためどれだけ心地よい体験ができたかは、もちろんプロダクトのクオリティによる部分が大半ですが、ブランド観点での回答も出てくるため、検証結果を分析する際、プロダクトとしてどう改善するのかは深く議論するようにしてください。
3.プロダクト内の各機能はユーザーにとって効果的だったか（利便性）
1.2で行うようにユーザーの生の声を聞いて各機能がどれだけ効果的だったのか定性的に確かめることはできます。
それに加えて各機能がプロダクトにとって、なくてはならない機能なのか可視化できる検証方法があります。
機能の効果を可視化できる「狩野モデル」
顧客の求める品質は決して一つの型にはまるものではなく、顧客が感じる満足度はさまざまです。こうした顧客の求める品質をモデル化したものとして、東京理科大学名誉教授の狩野紀昭氏が1980年代に提唱した「狩野モデル」があります。このモデルは海外でも“Kano Model”として広く知られており、品質と顧客満足度の関係を捉える上で使用されています。
プロダクト開発で使用する狩野モデルは、各機能に対して「魅力性」「当然性」「重要性」を測定していきます。３つを測定することで、機能を実装した方が良いのか、もう少し違う形で改善したほうが良いのか、そもそも機能自体削除したほうが良いのか判断する重要な調査材料になります。
狩野モデルの使い方
「魅力性」「当然性」「重要性」を測定するために３つの質問に対して選択肢を設けて、回答してもらいます。
〇〇機能について答えてください。
1.この機能があったらどう思いますか？（魅力性）
あると最悪 / 好まない / あまり好まない / 普通 / まあまあ嬉しい / 嬉しい / とても嬉しい
2.この機能がなくなったらどう思いますか？（当然性）
ないと嫌だ / 好まない / あまり好まない / 普通 / まあまあ嬉しい / 嬉しい / ないと嬉しい
3.この機能はどのくらい重要ですか？（重要性）
重要ではない / まあまあ重要 / 重要 / とても重要 / 絶対必須
上記を1機能1セットでヒアリングします。
狩野モデルを実施する際は、人の目を気にせず被験者に回答して欲しいので、ユーザーテストでプロトタイプを一連全て触ってもらった後に、Google Formで各機能に対して回答してもらうことをおすすめします。
プロトタイプを触った後はどういう体験の流れで触った機能なのか記憶が新鮮なうちに回答できるため、回答精度が高まります。
狩野モデルの集計方法
各回答に対して点数を割り振ります。
業界標準ではネガティブな回答はポジティブな回答よりも弱いので、ポジティブな方をスケールアップします。
この機能があったらどう思いますか？の回答の点数付けは以下の通り。
あると最悪（-3点）
好まない（-2点）
あまり好まない（-1点）
普通（0点）
まあまあ嬉しい（2点）
嬉しい（4点）
とても嬉しい（6点）
この機能がなくなったらどう思いますか？の回答の点数付けは以下の通り。
ないと嫌だ（6点）
好まない（4点）
あまり好まない（2点）
普通（0点）
まあまあ嬉しい（-1点）
嬉しい（-2点）
ないと嬉しい（-3点）
この機能はどのくらい重要ですか？の回答の点数付けは以下の通り。
重要ではない（1点）
まあまあ重要（2点）
重要（3点）
とても重要（4点）
絶対必須（5点）
上記の点数付けを人数分行い、平均値を出します。
そうすると各機能の「魅力性」「当然性」「重要性」が明らかになってきます。
以下のような表組みに平均値をマッピングすることで各機能の評価が可視化されます。
X軸は当然性、Y軸は魅力性、円の大きさで重要性を表します。なので右上の高効果が一番評価が良く、「あると嬉しいし、ないと不満」な機能ということになるので、優先的に開発すると、事業の成功を手助けしてくれる可能性が高いです。
逆に左下に機能がマッピングされると「逆効果」となります。この機能を開発してしまうとプロダクト自体への嫌悪感が出てくる可能性があるため、そもそも機能自体削除したほうが良いということになります。
「変化なし」にマッピングされた機能は、ユーザーの声を聞いて改善するべきか、削除したほうが良いか議論すべき機能になります。変化なしエリアの中で右上にマッピングされたのであれば、改善すれば「高効果」になる可能性がありますし、ちょうど真ん中にマッピングされてるけど重要度の円が小さければ削除しても良いかもしれません。
開発工数やビジネス的観点で残すか削除するか決めても良いです。
ユーザーテストでヒアリングした実際の声と照らし合わせながら、方向性を探っていきましょう。
ユーザーテストの注意点
必ず被験者の顔と手元を観察できるようにセッティング
テスト時は必ず、被験者の顔とプロダクトのどこを触っているのか確認できるような状態にしましょう。
オフラインであれば手元と被験者の顔にフォーカスを当てたカメラを２台用意します。
オンラインの場合は被験者にはPCとスマホを用意してもらい、PCで顔を映しながら、スマホで画面共有してもらうことで、どの画面を触っていてどんな表情で操作しているのか観察が可能です。
自分たちはプロトタイプを作ってないと良い嘘をつく
被験者は目の前のインタビューする人がプロトタイプを作ったのでは？と思ってしまうと気を使った発言が多くなります。率直な感想を引き出したいので、本当に自分が作ったプロトタイプだとしてもインタビュー前に必ず「私は実際にこのプロトタイプを作った人間ではないので、気にせずポジティブな面もネガティブな面も自由に思ったことを発言してください。」と話しておきましょう。
UX/UI検証でよく出てくる疑問点
「一回の検証でどのぐらいの人数に聞けば良いの？」
どのプロジェクトでも検証を行う前によく聞かれます。ほとんどの企業は定量調査は実施していることが多いので、定量と同様に定性も大人数検証しないと意味がないのでは？と、疑問を持たれる方が多いです。
ユーザビリティ領域の専門家として有名であるヤコブ・ニールセンは検証的調査のユーザーテストを実施する際は5人に検証できれば十分であるという研究結果を発表しました。
上記の図はユーザビリティの新たな課題発見とその発見をするために必要な被験者数を表した図です。3人にヒアリングした時点で約65%の課題が発見できており、5人で約80%、それ以降は緩やかな発見率となっています。この研究結果からヤコブ・ニールセンは一回のユーザーテストに対して5人に検証することを推奨しています。
私自身の経験でも3人だと少なすぎて物足りなさがあり、7人だと多く途中から同じようなことの繰り返しになるため、5〜6人が適正人数だと考えています。
多くのリソースと時間があれば100%の課題発見に近づけるために15人に聞けば良いのですが、基本プロジェクトはリソースと時間は限られています。
15人に聞くのであれば3回異なるテーマで5人ずつ検証した方が新たな課題が効率よく発見できる可能性が上がるため、1回のユーザーテストで完璧を求めすぎないようにしましょう。
探索的調査の場合
検証的調査のユーザーテストではなく、探索的調査の場合はまだターゲットも絞りきれていない状態なので、5人に絞り込むことが難しい可能性があります。その場合は聞きたい属性に対して３人ずつヒアリングすることをおすすめします。「属性数x3人」のようなイメージです。
また属性を考える際は以下の観点を意識しましょう。
プロダクトをすでに利用している場合、他ユーザーに比べて多く利用している人、なんで利用しているのかわからない人は優先的にリクルーティングする（チームが把握してない価値を見出している可能性が高いため）
男女、年齢、居住地、家族構成、世帯収入などの基本属性はできる限りばらけさせる
プロダクトに関連する体験をしている人8割、関連する体験をしていない人2割ぐらいのイメージで集める
「インタビュー後の分析時間はどのぐらい見積もっておけば良いの？」
（インタビュー時間x1.5倍）x インタビューした人数 = 分析時間
例：1時間のインタビューを5人ずつに実施
（1x1.5）x 5 = 7.5時間
インタビューした内容をポストイットでメモを取り、クラスタリング分析して、「こんな傾向がありそう」と見えてくるまでの目安の見積もり時間です。
今ではAIを利用してクラスタリング分析はある程度可能なので、AIを使いながら行うとより効率的にできると思います。
ここからどこにみんな興味関心があるのかなど顧客インサイト、ニーズを定義していきます。ここはまとめる人の慣れや分析の状態によって変わるのでなんとも言えないですが、資料化することも考えると3~7日間見積もっておくと良いと思います。
最後に…
ここまで読んでくださりありがとうございます。紹介した方法以外にも検証方法は存在しますが、紹介した方法はプロダクト開発でよく使用しており、一定の効果を発揮できる方法になります。初めて検証する方は「時間かけて実施したにも関わらず発見がなかったらどうしよう」と不安になると思いますが、きちんと手順を踏んで検証を行えば、自分たちが予期しない新たな発見や証明ができると思います。
共に良いものを作っていきましょう！
プロジェクト初期・後期のUX/UI検証 実践編はこちらでご紹介しています。
またなぜUX/UI検証を実施するのかはこちらでご紹介しています。
Xも最近ちゃんと投稿しはじめたので、よかったらフォローお願いします。毎日サービスデザイン、UX/UI、生成AI関連の情報共有をしています。
https://twitter.com/yutomi1414