教科書通りにはいかない？ユーザビリティテストのリアル
こうした社風のもと、私が所属するプロダクトデザイングループでは社内の多様なメンバーと協力してUIデザインに取り組んでいます。
UIの制作過程で行うユーザビリティテストでは、実際のユーザー像に近い方々にUIを試してもらうことで、「学習しやすいか」「効率がいいか」「満足感はどうか」などを客観的に検証します。基本的なテストのプロセスは仕組み化されており、テスト経験がないメンバーでも日々の業務に取り入れやすいよう、ガイドラインが整備されています。
また、AIを導入して作業を効率化するなど、ガイドラインは常にアップデートされ、基本的なテストは容易に実施できるようになっています。しかし、複雑な課題に対しては「標準的な設計」だけでは不十分なこともあり、プロジェクトごとに創意工夫を凝らしています。
ここからは、標準的な設計だけでは不十分だった2つの課題についてご紹介します。
課題1：テストという「非日常」をいかに「日常」に近づけるか
1つ目の課題は、テストという非日常的な環境下では、率直なフィードバックを得づらいという点です。
基本的にテストでは、参加者には操作中に思ったことを可能な限り声に出してもらう「思考発話法」という手法を取り入れています。これにより、「何を手がかりに情報を探しているか」「どのようなキーワードを想像しているか」といった、ユーザーのメンタルモデルを把握する重要なヒントが得られます。
私たち作り手は仕様を熟知しているため、どうしてもバイアスが生じ、欠点を見落としがちです。そのため、ユーザーの生の声から自分たちのバイアスに気づかされるこの手法は、非常に有効だと実感しています。
しかし、この手法を過信しすぎるのは危険です。
「発話しながらの操作」自体が非日常的ですし、第三者に観察される特殊な環境下では「正しく操作しなければ」という緊張感から、無意識に普段とは異なる挙動をとってしまうことも考えられます。得られた発言や行動を鵜呑みにするのではなく、その背景を慎重に解釈する必要があります。
そこで重要になるのが、テスト前の雰囲気づくりです。
アイスブレイクを丁寧に行い、「間違えてもいい」「むしろそれがヒントになる」と伝えることで、話しやすい雰囲気を作ります。加えて、当日の発言だけに頼るのではなく、シナリオ設計の段階から確認ポイントを明確にし、事後インタビューで深掘りするなど、テスト全体を通じた柔軟な調整が不可欠です。
課題2：毎回同じテスト設計では本当の課題を抽出できない
2つ目の課題は、毎回同じ設計では課題を抽出できない場合があるということです。
入社前、私はユーザビリティテストの目的を漠然と「使いやすさを確認すること」だと考えていました。しかし実際には、「目的を達成できるか」「正しく使えるか」といった「使用可能性」や「有効性」を検証するものへと認識を改めました。
アプリを利用する方が上手く機能を使えない場合、そもそもその機能が「学習しやすいか」という観点から改善案を検討する必要があります。テスト中には、色や形、レイアウトが原因で発生する問題もありますが、「メッセージの意味がわからない」「画面で何が起きているか把握できず、次に進めない」といった、認知や理解のフェーズにおける問題も発生します。
こうした問題は、タスクの完了率といった定量データだけでは、改善案が本当に有効かを評価しきれません。そのため、言葉選びやエラーメッセージ、機能のコンセプト自体が意図通りに理解されているかの検証も行います。
シナリオやタスクの設計はもちろん、事後インタビューの設計や、実際の使用感に近いプロトタイプの準備など、ユーザーの思考プロセスを可能な限り可視化する工夫が必要です。ユーザビリティテストは複数回の実施を前提とし、各回でシナリオやタスクを最適化しながら改善案の検証を繰り返していきます。
【具体例】標準設計では捉えきれなかった3つのケース
ここからは補足として、標準的なテスト設計だけでは捉えきれなかった3つの具体的なケースをご紹介します。
ケース1：新機能における「サービス全体の理解度」
新機能や新しいUIデザインへの理解度に焦点をあてたテストでのことです。
普段アプリを操作するとき、多くの方は無意識に「これは自分の知っているあのアプリと同じだろう」と予測を立てて操作しています。しかし、デザインの意図がその予測とズレていると、どれだけボタンを目立たせてもユーザーの手は止まってしまいます。
実際のテストでも、「この画面で何ができるか」は理解できても、「その行動が全体にどう影響するか」が見えないために手が止まるということがありました。
何となく操作はできるが、納得感がないという状態です。
このような場合、ただ操作しているだけでは「なぜ間違えたのか」がわかりづらいため、少し変わったテスト設計を行うことがあります。例えば、具体的な操作を指示せずに一通り画面を触ってもらい、その後の事後インタビューに時間をじっくり使ったり、2回目・3回目のテストでは指示内容や順番を変えたりしながら、何が原因だったのかを探り当てます。
ケース2：エラーメッセージが「解決」に導いているか
機能によっては、エラーメッセージがユーザーの行動を阻害していないかを検証します。
単なる状況説明に留まらず「次に何をすべきか」が明確か、ユーザーが自力でリカバリー（復旧）できる内容になっているか、といった観点です。
あるプロジェクトで、日常的に実施するテストの多くが、スムーズに進行する「正常系」に偏りがちであることに気づきました。
エラーなどが発生する「異常系」のテストを実施する場合、過去の事例があったとしても画面ごとに仕様が異なるため、単にガイドラインを適用するだけでは実際の利用者の行動に即さないことが多々あります。
そこでグループで議論し、あるプロジェクトの手続きタスクにおいて、敢えてエラーを発生させるシナリオを設計しました。
参加者に「誤ったパスワード（ダミーの認証情報）」をお伝えして操作してもらうというものです。当然、参加者は情報が間違っているとは想定していません。 かといって「情報が間違っている可能性があります」と伝えては誘導になります。
いかに誘導を避けつつ、参加者が自力で「情報が違うかもしれない」と気づき、混乱せずに次の行動へ移れるか。この塩梅を探るテスト設計には非常に苦労しましたが、これを繰り返すことで当初の課題を解消する具体的なUIデザイン案を提案することができました。
ケース3：最初にボタンを押すまでの心理的なハードルはないか
最後に「ボタンが見えていること」と「押せる（押したくなる）こと」は別物であると再認識したお話です。
操作方法は理解できていても、「このボタンを押すと後戻りできない変化が起きるのではないか」「面倒な入力が始まるのではないか」といったリスクの予見が、ユーザーの判断を鈍らせることがあります。これは単純な操作性の問題ではなく、期待値と不安のバランスの問題です。
例えば、手続きを開始するボタンの先に「あと何工程あるのか」「何を用意すべきか」が不透明だと、「今はやめておこう」と離脱を招く要因になります。また、文言の意味はわかっても「押した後の具体的なイメージが湧かない」という理由で敬遠されることもあります。
単なる視認性というスペックの問題にとどまらず、ユーザーに「次へ進む安心感」をいかに提供できるか。数値やデータだけでは測れないこの課題に、唯一の正解はないと考えています。しかし、ユーザーが納得して使い続けられるデザインを提供できるよう、事後インタビューを通して「行動の裏にあるインサイト」を深く掘り下げる工夫を、プロダクトデザイングループでは続けています。