ユーザビリティテストの解像度をあげようの巻
こんにちは！川上です！
今月号は『ユーザビリティテスト』について、解像度が上がっている今のうちに備忘も込めてのばっくりまとめ発信です！
noteなど、ネット上に蓄積されているさまざまな記事を拝見しましたが今回特に時間をかけて読ませていただいた本はこちらの2冊です。
右：UXリサーチの道具箱Ⅱ
学びの内容を抜粋・要約、私なりの解釈を加えながらのアウトプットとなりますことをご了承ください。
基礎～応用まで、困ったときのお守り本として重宝しています😌
すでに2024年出会えてよかった書籍たちです。ありがとうございます。
そもそもユーザビリティテストって？
1．「ユーザビリティテスト」は実装されている“UI”や“デザイン”の問題点を明らかにすることが目的であり「ユーザーテスト」とは違う
2．テストの際は『改善思考』をもって臨む。なぜその結果が出たのか？どうしたら改善できるか？各視点から全員で考える
3．テストで出てきた問題はすぐに改善する（すぐに改善できる環境をつくる）
これまで「ユーザーテスト」は何度か経験がありましたが、「ユーザビリティテスト」に触れるのは初だったのでユーザビリティテストとユーザーテストは別物であるということを改めて認識することができました。
また、『ユーザビリティテストは改善が無ければやる意味がない』とあるように問題の改善はマスト。
「工数が多くなる」「今さら作り直せない」事態を避けるために、早い段階からユーザビリティテストを実施することが大切だということも学びました。
改善はユーザーのためのもので、ステークホルダーの要望にだけフォーカスしない。（ユーザーを置き去りにしない！）
鶴の一声でプロダクトの方向性が変わらないようにするためにはチーム全員が問題を共有し、同じ認識を持つことが重要。＝極力テストには全員で参加。
《モデレーター側👀》ユーザビリティテストのポイント
最大のポイントは、ユーザーが製品を使用する際の行動を観察して問題点を発見すること。最初から最後まで“ユーザーの声聞くべからず”。
正直わたしは初見で「えっ」と思いましたが、ユーザーがきちんと操作中に思考を“発話”できていればそれ以上何も聞くことは無い。という理解をしました。
テスト中の観察ポイントは以下３つです。
1．ユーザーは独力でタスクを完了できるか
2．ユーザーは無駄な操作をおこなったり、戸惑ったりしないか
3．ユーザーは不安や不満を感じてないか
ユーザビリティテストは効率問題（＝ユーザーの無駄な操作や戸惑い）を発見するものと思われがちですが、最も大切なのは効果問題（＝ユーザーがタスクを完了できない）が潜んでいる可能性を意識してテストをすること。
ここを見落とすと、リリースしても使い物にならない製品になる恐れがあるということです。
効果・効率・満足度のすべてを満たしてはじめてユーザブル（使用可能）であると言えます。
そしてなにより、ユーザビリティテストにおいての肝はタスク設計。
スタートとゴールの定義を必ず明確にし、スムーズにタスクに取り組んでもらえるよう事前のセットアップを入念におこなうことが重要です。
タスクについては「サービス名称を使わない」「具体的にし過ぎない」など、ユーザーに種明かしをしてしまわないように注意することも大きな学びでした。
以下、実例を挙げておきます。
EPOS側からユーザーにやってほしいこと
「ピンチ回避」から、「分割」or「リボ」を実行してほしい
😭NGタスク例：
『支払いがピンチなので、ピンチ回避ボタンを押してください』
😄OKタスク例：
『支払いがピンチなので、支払額を減らせる方法を実行してください』
タスクの言い回しを少し工夫するだけで、ユーザーに自然とピンチ回避導線に気づいてもらうこと、さらには分割変更・リボ変更のどちらに進むかの選択肢をより広く提示することが可能になります。
《見学者側👀》ユーザビリティテストのポイント
見学者は『司会者のパートナー』であり「見物人」ではありません。司会者とは異なる視点で、ユーザーの言動を観察することが求められます。
見学者がテスト当日までにやっておくべきことは以下３つです。
1．どのようなユーザーがくるのか知っておくこと
2．どのようなタスクを実行してもらうのか把握しておくこと
3．どのような行動が起きうるのか考えておくこと
事前のアンケート情報や属性を頭に入れておくことで、ユーザーの言動がインプットしやすくなります。
また、ユーザーに実行してもらうタスクを自分自身で実際にやってみておくことでユーザー心理を考えやすく、仮説も立てやすくなります。
少し心配症になって、「この画面で間違えるのでは？」「○○に戸惑うのでは？」と、どのような行動が起きうるか考えたこと/感じたことがチェックポイントになります。
テスト時は、ユーザーの行動や表情に目を向けてわずかな迷いやミスを見逃さず、なぜそのような行動をとったのかに目を光らせます。
「たどり着けた！よかった！」ではなく、ユーザーがタスクを完了するまでの過程（行動）や些細な表情をメモしておくと振り返り（分析）の際の参考になります。
PdM・エンジニア・デザイナー・・・それぞれの視点から多くの気づきをいただくことができ、いつもチームに救われています。心から感謝です😊
まとめ
📌ユーザビリティテストとは
実装されている“UI”や“デザイン”の問題点を明らかにすることが目的であり「ユーザーテスト」とは違う
📌《モデレーター側👀》ユーザビリティテストのポイント
ユーザーが製品を使用する際の行動を観察して問題点を発見すること。最初から最後まで“ユーザーの声聞くべからず”
📌《見学者側👀》ユーザビリティテストのポイント
見学者は『司会者のパートナー』であり「見物人」ではない。司会者とは異なる視点で、ユーザーの言動を観察することが求められる
最後に
今回このようなインプットをさせていただいたお陰で、自身の解像度が上がったと同時にチーム全体への共有も進み、実りある時間を創ることができたと感じています。
初めての取り組みを実施する際には、まずは自分が一番に学ぶ姿勢を必ず持ち、プロダクトに関わる全てのメンバーが同じ気持ちや温度感で臨めるよう今後も努めていきたいと改めて思いました🧐
次なるミッションに向けて全力で走り続けます！！！
最後までお読みいただきありがとうございました💌