ユーザビリティテストのやり方｜手順・人数・手法の選び方

観察される側になると、急に手つきが丁寧になります。

いつもなら勢いで押すボタンも、誰かが見ているだけで一度読みます。僕も同じです。冷蔵庫を開けて何を探していたか忘れたときでさえ、後ろに人がいると、最初から目的があったような顔をします。

だから観察とは、透明人間になる技術ではありません。人が少しよそ行きになる前提で、それでも現れる行動を見る仕事なのだと思います。

先に一行だけ置きます。

ユーザビリティテストでは、指摘の数より「行動が止まった箇所」を記録したほうが、改善につながります。

その中で、教科書どおりのテストが役に立つ場面を何度も見ました。一方で、指摘をきれいに回収しても、実際の利用が変わらない場面も見ました。

今日は、ユーザビリティテストのやり方をひと通り確認したうえで、指摘の数だけでは見えないものの話をしていこうと思います。この話に出てくるのは、飲食店の予約アプリを作るプロジェクトです。僕は企画からユーザビリティテストまでを担当しました。この記事では、予約操作をテストし、本番の利用につなげる工程を扱います。

前置きはさておき、本題に入ります。

① 教科書どおりに、テストしてみる

ユーザビリティテストの基本をすでにご存じの方は、② そのとおりに回して、詰まるから読み進められます。

進め方は、次のSTEPで見渡せます。各STEPの記録を一つ残してから次へ進むと、準備不足を本番の問題と取り違えません。

1. STEP1：実施目的と評価する行動を決める

2. STEP2：手法と実施時期を選ぶ

3. STEP3：対象者、タスク、体制を準備する

4. STEP4：パイロットテストで進行を確かめる

5. STEP5：思考発話を使いながら本番を実施する

6. STEP6：結果を分析し、改善の優先順位を付ける

7. STEP7：修正して再テストする

ユーザビリティテストとは

ユーザビリティテストとは、対象の製品やサービスをユーザーに使ってもらい、使いやすさをユーザー視点で明らかにする評価です。画面を見せて感想を聞くだけではありません。目的の操作をしてもらい、どこで迷い、止まり、戻ったかを観察します。

目的は、作り手の想定と実際の行動のずれを見つけることです。作り手には、画面の構造も言葉の意味も分かっています。初めて触る人には、その前提がありません。必要性は、この知識差を会議室だけでは埋めにくい点にあります。

問題が出たときは、ユーザーの理解力ではなく、まず製品側を疑います。「説明を読まなかった」という記録で終えず、説明を読まなくても進める構造だったかまで見ます。つまり、責任を人へ返さないことが、テストの出発点です。

ユーザーテストとの違い

「ユーザーテスト」は、企画や価値を含めて、ユーザーの反応を広く確かめる意味で使われます。ユーザビリティテストは、その中でも利用時の有効さ、効率、満足度に焦点を置く呼び方です。ただし、現場では両者を同じ意味で呼ぶこともあります。名前より、今回何を確かめるかを先に合わせます。

専門家評価との詳しい使い分けは、後の「ヒューリスティック評価・認知的ウォークスルーとの使い分け」で整理します。

実務では、依頼文に「価値の評価」か「操作の評価」かを一行で書きます。ここが曖昧だと、操作テストの場で事業案への賛否を集め、結論が混ざります。

UIテストとの違い

UIテストは、画面部品の表示や操作、実装上の動作確認を指す場合があります。ユーザビリティテストは、部品が仕様どおり動くかだけでなく、利用者が目的を理解し、迷わず達成できるかを見ます。

「ボタンが押せる」はUIの確認、「申込みたい人がそのボタンを見つけて完了できる」はユーザビリティの確認、と依頼書に対象行動を書き分けます。

ヒューリスティック評価・認知的ウォークスルーとの使い分け

ヒューリスティック評価は専門家が原則に照らして問題候補を探し、認知的ウォークスルーは初めての利用者が手順ごとに次の操作を見つけられるかを点検します。実ユーザーを集める前でも実施できます。

ユーザビリティテストは、実際の人が予想外に止まる、戻る、読み違える行動を捉えます。まず専門家評価で明らかな問題を除き、その後に重要タスクを利用者へ試してもらうと、参加者の時間を既知の不具合だけに使わずに済みます。

実施目的——何が得られるか

得られるのは、ユーザーが目的へ進む途中で止まる場所と、その直前の行動です。満足した人数を集める場ではなく、次に直す箇所を決める証拠を取る場と定義します。開始前に「この結果で何を決めるか」を一文にすると、質問の増やしすぎを防げます。

何をもって使いやすいと判断するか

評価基準は、「有効さ」「効率」「満足度」の三つで整理できます。有効さは目的を達成できたか、効率は余計な手順や時間が増えていないか、満足度は不安や負担がなかったかです。

画面では、ナビゲーション、文字の可読性、フォームの入力、端末に応じたレスポンシブ表示などを評価項目にできます。ただし、項目を点検表として埋めるだけでは、利用の流れが切れます。

たとえばフォームなら、「ラベルが読める」だけでなく、入力を始めたあとに何度戻ったかを見ます。レスポンシブ表示なら、崩れの有無だけでなく、押したい操作が画面内に残るかを見ます。評価項目は、ユーザーが達成したい行動と結びつけます。

ニールセンの5指標で測る

ニールセンの整理では、学習しやすさ、効率性、記憶しやすさ、エラーの起こりにくさ、満足度の5指標でユーザビリティを見ます。前述のISO 9241-11にある有効さ・効率・満足度とは別の軸で、初回利用、再利用、誤操作まで分けて観察するために並べます。

指標	テストで見る行動
学習しやすさ	初回に説明なしで入口を見つけられるか
効率性	覚えた後に余分な往復なく終えられるか
記憶しやすさ	間を空けた再利用で手順を思い出せるか
エラーの起こりにくさ	誤操作の頻度と、自力で戻れるか
満足度	終了後に不安や負担が残っていないか

定性と定量

ユーザビリティテストには、定性と定量の見方があります。定性では、迷い方、戻り方、言葉の解釈を見ます。定量では、完了できたか、操作にどれほど手間がかかったかなど、条件をそろえて比較します。

どちらか一方が正解ではありません。定量は変化の大きさを比べる助けになり、定性は変化の理由を考える材料になります。まず少人数の定性観察で詰まり方を見つけ、その後に条件をそろえて確認する進め方もできます。

ただし、測りやすさを優先すると、軽い迷いを大量に数えがちです。実務では、数字の前に「どのタスクの、どの行動を測るか」を固定します。数字は目的ではなく、同じ状態を比べるための目印です。

SUS（システムユーザビリティスケール）

SUSはSystem Usability Scaleの略で、システムの使いやすさを10項目の質問で測る標準化された尺度です。回答を所定の方法で換算し、0〜100の得点として同じ条件の版や製品を比較します。

得点だけでは、どの画面をどう直すかは分かりません。実施条件と対象者をそろえ、行動観察で見つけた停止箇所と併記して、変更前後の全体的な受け止めを確認します。

定量で測るときの人数

定性テストの「5人」は問題を発見して反復する目安であり、割合や平均値を安定して比較する定量調査へそのまま使えません。定量では、比較したい群、想定する差、結果のばらつき、許容する誤差から必要人数を設計するため、通常は別の桁になります。

まず比較する指標と群を決め、統計設計ができる担当者に必要標本数を確認します。少人数の完了率を市場全体の割合として報告しないことが実務上の境界です。

手法の種類

代表的な手法には、操作をそばで見る観察型、体験を言葉でたどるインタビュー、目的を渡して完了まで進めてもらうタスクベース、回答をまとめて集めるアンケートがあります。組み合わせると、行動と理由の両方を扱えます。

一方、一次データはユーザーの言葉より行動に置きます。「簡単でした」という感想があっても、同じ画面を何度も行き来していれば、その動きを記録します。言葉を疑うのではありません。言葉と行動が違ったとき、改善する画面を決められるのは行動だからです。

聞く手法を深めたい場合は、デプスインタビューは「答え」ではなく「場所」を探すも参考になります。なお、操作のしやすさと、そもそも使いたい理由があるかは、同じ問いではありません。

いつやるか

実施のタイミングは、完成後に限りません。企画の初期、設計中、開発途中、公開前、公開後のどこでも行えます。早い段階なら、紙のワイヤーフレームも評価対象物になります。押せない紙でも、「次にどこを押すと思うか」は観察できます。

上位の実務知では、一発勝負より、早く小さく繰り返す考え方が共通しています。完成後に大きく直すより、粗い状態で見つけて直し、また確かめるほうが変更しやすいからです。

現場では、画面の完成度ではなく、判断の締切から逆算します。「この画面を作り込む前に、入口の理解だけ見る」のように、今回の判断を一つ置けば、未完成でもテストできます。

プロトタイプの段階でもテストできる

紙に描いた画面、Lo-Fi（低忠実度）のワイヤーフレーム、クリックできる試作品でもテストできます。紙なら情報の順序や次に押す場所、クリック試作なら遷移やラベルを、実装前に確かめられます。

未実装の動作は進行役が画面を差し替えて再現し、参加者には動く範囲を最初に伝えます。見た目の完成度を評価させるのではなく、「入口を見つけられるか」など、その試作で答えられる問いを一つに絞ります。

同僚に頼む簡易型でもできる

募集の前に、製品知識が少ない同僚へ重要タスクを試してもらう簡易型も使えます。タスク文の誘導、壊れたリンク、録画漏れなど、テスト設計の不具合を早く見つける用途に向きます。

同僚は組織の用語や背景を知っているため、顧客の代わりにはしません。発見を確定結論にせず、外部ユーザーへ試す前の修正候補とパイロット結果として扱います。

準備でやること

準備では、最初に目標を定めます。「使いやすさを見る」では広すぎます。「初めて来た人が、目的の申込みを始められるか」まで絞ります。次に仮説を置きます。「入口の文言から、自分向けだと判断できないのではないか」という形です。

仮説は、正解を当てる宣言ではありません。何を観察するかをそろえる道具です。仮説と違う行動が出れば、その違い自体が成果です。

そこで僕は、目標、想定する行動、観察する箇所を一枚にします。関係者が「良い反応を得たい」と考えていても、観察箇所が決まれば、好意的な言葉を取りに行く進行を避けやすくなります。

タスク設計

タスクは、ユーザーが現実に達成したい目的として書きます。「右上の申込みボタンを押してください」と操作を教えるのではなく、「条件に合う申込み方法を探してください」と渡します。シナリオには、置かれた状況と目的を含め、正解の場所は含めません。

質問項目も先に作ります。開始前には普段の利用状況、実施中には考えていること、終了後には不安が残った箇所を聞きます。ただし、質問順を守るために観察を中断する必要はありません。

良いタスクか迷ったら、「その行動は、指示されなくても現実に起こるか」と考えます。タスクを与えた瞬間、参加者には実行する前提が生まれます。そのため、操作の完遂と、日常で自発的に選ぶことを混同しない設計が必要です。

質問の作り方（1タスクに最大3問・開かれた聞き方）

一つのタスクに添える質問は最大3問を目安にし、開始前、停止時、終了後の役割を分けます。「分かりにくかったですか」ではなく、「次に何が起きると思いましたか」「どこを探しましたか」と、答えを限定しない開かれた聞き方にします。

質問が増えると操作の流れ自体を変えてしまいます。各問に「この回答で何を判断するか」を書き、行動観察で分かる問いは削ります。

誰に、何人やってもらうか

被験者は、想定ユーザーの条件から集めます。年齢や所属だけでなく、対象行動の経験、利用する端末、困りごとの状況まで考えます。身近な社員で代用すると、製品の言葉を知りすぎている場合があります。

人数では「5人」がよく目安になります。背景には、一度に大人数を集めるより、少人数で問題を見つけ、直して再び試すほうが効く、という整理があります。ただし、「何の問題に対しての5人なのか」を先に決めます。

一つの利用場面を一つのユーザーグループで見るなら、少人数でも行動の重なりを確認できます。初心者と経験者、管理する人と利用する人のように複数グループがあるなら、全員を一つに数えません。各グループで確かめたい問題を分け、人数を配分します。

つまり、人数より先に利用場面の数があります。募集条件表には「誰か」だけでなく、「どの場面の問題を見る人か」も書きます。

当日の体制と機材

当日は、進行するモデレーター、記録係、必要に応じて別室のオブザーバーを置きます。機材は、対象端末、画面や手元の録画、音声、メモを用意します。録画には、事前に目的と扱いを伝え、同意を得ます。

機材より重要なのは、記録係が何を書き取るかです。時刻、タスク、止まった画面、直前の操作、次に取った行動を並べます。「迷っていたようだ」ではなく、「入力後に前画面へ戻り、同じ説明を再び開いた」と書きます。

本番前にはパイロットテストを行います。社内の人でも構いません。タスクの文に答えが含まれていないか、録画範囲が足りるか、進行時間が偏らないかを確かめます。リハーサルで見るのは製品の良し悪しではなく、テスト自体の不具合です。

使う道具

対面では対象端末、カメラ、画面録画、タイマー、記録表を組み合わせます。リモートではZoom、Google Meet、Microsoft Teamsなどで同意を得て画面を共有し、Figmaなどのプロトタイプや実装画面を操作してもらえます。名称は用途例であり、順位を示すものではありません。

録画の有無にかかわらず、時刻とタスクを記録表へ残します。事前に通知や個人情報が映る範囲を確認し、必要な画面だけを共有する設定をリハーサルします。

評価項目のチェックリスト

チェックリストには、目的の達成、入口の発見、用語の理解、手順の往復、エラーと回復、完了の認識、負担の発言を並べます。画面ごとの見た目ではなく、タスクの開始から終了まで同じ項目で追います。

項目には「確認済み」だけでなく、観察した時刻と行動を書きます。該当しない項目を無理に埋めず、今回の目的に関係する項目だけを開始前に選びます。

パイロットテスト

本番と同じ説明文、タスク、機材で一度通し、所要時間と記録漏れを確認します。修正対象は製品ではなくテスト設計です。「参加者が迷った理由が製品か、曖昧な指示か」を判別できない箇所があれば、タスク文を直してから募集対象者へ進みます。

当日の流れ

当日は、目的と録画の説明、同意の確認、事前質問、タスクの提示、操作と観察、終了後の質問、振り返りの順で進めます。これは基本の流れであり、タスクごとに短い確認を挟む形でも構いません。

冒頭では、参加者を評価する場ではないと伝えます。問題が出たら、ユーザーではなく製品の問題として扱います。助けを求められても、すぐ正解を教えません。まず「今、どうしようと思いましたか」と尋ね、止まった理由を残します。

実務では、救済条件も決めておきます。同じ場所で操作が進まなくなり、観察したい事実が取れたら、次へ進むための最低限の案内をします。放置して困らせることは、観察ではありません。

思考発話法

操作中に見ているものや次に起きると思うことを声に出してもらいます。モデレーターは答えを教えず、沈黙時には「今、何を見ていますか」と現在の状態だけを尋ねます。⑥では、僕があとからこの名前を知り、行動記録へ接続した経緯を扱います。

対面とリモート

対面は、手元、視線、姿勢を含めて観察しやすく、機材の不具合にも対応しやすい方法です。リモートは、場所を問わず参加してもらいやすく、普段の端末や環境に近い状態を見やすい利点があります。

オンラインでは、接続確認、録画同意、画面共有、タスク提示、操作、終了後の確認という順で進めます。通知や個人情報が映る可能性を説明し、必要な画面だけ共有してもらいます。通信の停止と、製品上の停止は記録上で分けます。

期間を短くしたい場合は、簡易版も選べます。対象タスクを一つに絞り、最低限の体制で実施し、その日のうちに観察をまとめます。簡易版でも、募集条件、同意、誘導しない進行は省きません。短縮するのは範囲であり、参加者への配慮ではありません。

直して、もう一度やる

ユーザビリティテストは、一度で完成判定を出す方法ではありません。問題を見つけ、改善し、再テストする反復で機能します。早く小さく繰り返すほど、変更前後の違いも追いやすくなります。

現場では、直す前に、参加者ごとに止まった箇所が同じかを確かめます。停止が同じなら、画面側の原因を検討できます。停止が違うなら、一つの修正案へ急いでまとめません。

再テストでは、前回の指摘が消えたかだけでなく、目的の行動が進むようになったかを見ます。文言を直して別の迷いが生まれることもあります。改善とは指摘を消す作業ではなく、行動の流れを変える作業です。

結果の分析・優先順位付け

記録をタスク順に並べ、停止箇所が同じものを一つの問題として束ねます。優先するのは、目的を達成できなくなる問題、頻繁に起きる問題、後続の複数タスクへ影響する問題です。⑧の記録シートでは、この判断を行動単位へ落とし込みます。

問題点を画面に対応づける

問題ごとに、画面名、要素、発生時刻、直前の操作、次の行動を対応づけます。「検索が分かりにくい」ではなく、「結果画面の絞り込み見出しで止まり、検索画面へ戻った」と記録します。

同じ発言でも発生画面が違えば別の問題として残します。画面キャプチャへ番号を振り、観察記録と修正チケットに同じ番号を使うと、解釈だけが実装へ渡るのを防げます。

ヒートマップ・クリックログと併せて見る

ヒートマップは注目やクリックの分布、クリックログは多数の利用者が実際に押した位置や順序を示します。テストで見た少人数の停止が本番でも広く起きているかを確かめる補助になります。

分布だけから理由を断定せず、テストの発話と行動で原因仮説を作り、ログで広がりを確認します。個人を追跡しすぎない計測範囲と保存期間も事前に決めます。

記録シート

記録シートには、参加者条件、タスク、時刻、画面・要素、観察した行動、発言、解釈、修正仮説を分けて書きます。⑧の実録用シートと同じく、感想だけを独立した票にしないことが軸です。

開始前に空のシートで模擬記録を行い、記録係が一つの停止を一行で残せるか確認します。終了後は録画と時刻を照合し、事実と解釈が混ざった行だけ直します。

本文で挙げた列をそのまま並べたシートです。XLSX版でダウンロード／PDF版でダウンロード

公表されている実施事例

外部から中身まで確認できる事例は、行政に多く残っています。東京都は「テストしないものはリリースしない」を掲げ、庁内のサイト・アプリ・システムを開発するときにユーザーテストを実践する方針を示し、実施手順をまとめた「ユーザーテストガイドライン」を公開しています。初版は令和3年9月、その後に3つの手順書を1つへ統合したVERSION 2.0が公開され、実際のテスト事例を踏まえた改訂が続いています。

民間の事例は、支援した会社が書いた紹介記事として出ていることが多く、対象範囲と前提が読み取れません。事例を探すときは、実施した組織自身が手順まで公開しているものから読みます。手順が付いていない事例は、成果の数字だけが残り、自社で再現する手がかりになりません。

テストで分からないことの限界

テストで分かるのは、与えたタスクと環境の中で操作できたかです。日常でその製品を選ぶか、価値に対価を払うか、市場で需要があるかまでは証明できません。

結果には「今回答えた問い」と「答えていない問い」を並べます。完遂したのに本番で使われない場合は、利用ログ、現場観察、価値検証を別に行い、画面の問題と採用理由を分けます。

費用の考え方

費用は、対象者の見つけにくさ、募集人数、実施場所、機材、録画、タスク数、分析の細かさで変わります。実額を一律に置かず、社内で行う工程と外部へ依頼する工程を分けて見積もります。

最初に意思決定へ必要なタスクを一つ選び、募集、実施、分析、再テストの工数を積み上げます。削るなら観察の目的を狭め、同意や個人情報への配慮は削りません。

期間の目安

期間は、設計、募集、パイロット、本番、分析、修正、再テストに分けます。対象者の条件が細かいほど募集が長くなり、録画を詳細に起こすほど分析が長くなります。

公開日から逆算し、少なくとも修正と再テストの時間を先に確保します。「本番実施日」を完了日にせず、同じ重要タスクで変更を確認した日を完了日にします。

よくある失敗パターン

失敗は、操作を指示するタスク、参加者を助けすぎる進行、感想の件数だけで付ける順位に集まりやすくなります。各タスクについて「現実の目的として書いたか」「救済前の行動を残したか」「停止箇所で束ねたか」を確認します。どれかが欠けた結果は、画面修正の根拠にせず再確認します。

うまくいくテストの条件

条件は、判断したい問いが一つに絞られ、対象者が実際の利用場面に合い、観察者が誘導せず、修正後の再テスト日まで決まっていることです。実施回数より、結果を誰がいつ変更へ反映するかを先に確保します。

② そのとおりに回して、詰まる

予約アプリでここまでの進め方を試すと、ちゃんと機能しました。実際に店を探して予約してもらうと、作り手だけでは見えない言葉の誤解や、戻る操作が見つかります。観察し、記録し、優先順位を付ける流れも役に立ちました。

ところが、指摘リストが長くなるほど、改善した気になりやすくなりました。「文言が分かりにくい」「ボタンが見つけにくい」「説明が長い」。一つずつ直すと、一覧には完了の印が増えます。

それでも、予約アプリの使われ方は変わりませんでした。操作は通ります。テスト中の反応も悪くありません。指摘も減ります。なのに、本番へ置いたあと、日常の予約行動になりません。

僕は最初、まだ指摘を拾い切れていないのだと考えました。そこで質問を増やし、観察メモも細かくしました。しかし、意見の量は増えても、利用されない理由には近づきませんでした。

③ どう気づいたか

予約アプリで店を探し、予約を完了するテストは完遂されていました。それなのに本番では使われない。この場面を見て、以前、社内向けにRAG（検索拡張生成。手元の文書を検索して、その内容をもとにAIが答える仕組み）を作ったときのことを思い出しました。検索精度は約95%まで上がり、デモでは評価されました。質問すれば、求める情報が返ります。タスクとして操作してもらえば、完遂できます。

しかし、本番に置いて1か月でアクセスはほぼゼロになりました。操作上の大きな問題が残っていたわけではありません。原因は置き場所と速さでした。普段使う画面から遠く、返ってくるまで待つ必要がありました。

デモでは、参加者は「今から検索する」というタスクに向き合います。本番では、別の仕事をしている最中に、わざわざ遠い場所へ移動するかを選びます。予約アプリでも、テストでは「今から予約する」に向き合い、本番では普段の店探しの途中でこのアプリを選ぶかを決めます。この違いを、僕は同じ利用体験として扱っていました。

もう一つ、自社EC事業を1年運営した経験も重なりました。僕らが想定した価値は物流の仕組みでした。ところが、実際に利用を動かしたのは、客室のドアノブに掛けた紙とテーブルに貼ったシールでした。ある1日は、スタッフが案内した経由のダウンロードが21件、誰も案内していない掲示物経由が46件です。

どちらも、画面内の使いやすさだけを磨いても見えないずれでした。そこで、テストで見ている行動と、本番で選ばれる行動を分けて考え始めました。

④ 原因を1つに特定

原因は一つでした。タスクを与えた時点で、「採用しない自由」が構造的に消えていたことです。

ユーザビリティテストで見つけやすいのは、「使いにくさ」です。タスクを完遂できなかった。途中で困った。終えたが不満だった。この三つは、操作中の観察で捉えられます。

しかし、第四の状態があります。「できたし、困らなかったが、使わない」です。参加者は、渡されたタスクを実行します。「今日は使わない」「別の方法で済ませる」という選択は、テストの進行上、取りにくくなります。

予約アプリも、予約するよう頼めば使えました。社内RAGも、検索するよう頼めば使えました。問題は、普段の行動の途中で、そこまで移動して待つ理由がなかったことです。使いやすさのテストが失敗したのではありません。テストで答えられる問いの外に、利用されない原因がありました。

だから、操作できることを確かめた結果から、「日常でも採用される」とまでは言えません。テストで見える範囲を狭く理解することが、結果を正しく使う条件でした。

⑤ 直してみる — 1箇所だけ直す

僕が直したのは、テストの種類ではありません。記録の単位を「意見」から「行動が止まった箇所」に変えました。

「説明が長い」という意見が出ても、それだけでは改善案にしません。予約アプリのどのタスクで、どの画面に来たとき、スクロールが止まり、前の画面へ戻ったかを残します。意見は、その行動にひもづけます。

すると、指摘の件数で順位を付けなくなりました。同じ停止に複数の感想が付いているだけなら、問題は一つです。逆に、誰も不満を口にしなくても、目的の直前で行動が止まれば、改善候補になります。

また、「止まらず完遂した」という結果も明確になります。その場合は、操作画面を直し続けるのではなく、採用しない自由が戻る本番の導線を見ます。普段いる画面から遠くないか、待つ負担がないかを確認します。

この一箇所の変更は、AI UX/UIデザインで改善を設計するときにも使っています。見栄えの好みを集める前に、目的の行動がどこで止まったかを置きます。

⑥ あとで知った — すでに名前があった

あとで整理してみると、僕が頼りにした見方には、すでに公知の名前がありました。「行動観察」と「思考発話法」です。

とくに後者は、やり方まで定型化されていました。

思考発話法

思考発話法では、操作中に考えていることを声に出してもらいます。「今、探しているもの」「次に起きると思うこと」を話してもらうと、行動だけでは分からない解釈を補えます。

モデレーターは、答えへ誘導しません。「そこにボタンがあります」はもちろん、「この言葉は分かりにくいですか」も答えを狭めます。沈黙が続いたら、「今、何を見ていますか」と、現在の状態を尋ねます。

ここでも、言葉より行動を一次データにします。「分かります」と言いながら止まったら、分かるという発言と、止まった事実を両方残します。参加者の矛盾を指摘するためではなく、設計が生んだ迷いを見つけるためです。

行動観察では、人がしたことを見ます。思考発話法では、その瞬間に考えていることを声にしてもらいます。僕が記録を「止まった箇所」へ変えたのは、行動を軸にし、言葉を解釈の補助に戻すことでした。

ただし、この二つも「使う理由」を自動で示すわけではありません。与えたタスクの中で何が起きたかを見る方法です。観察方法の名前を知ることと、観察できる範囲を知ることは、セットでした。

新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか

最も変わったのは、予約アプリのテスト結果の報告です。以前は指摘を並べ、件数の多い順に見せていました。今は、店を探して予約する流れに沿って、行動が止まった場所を示します。

「不満が多い画面」ではなく、「目的の行動を妨げた画面」として話せます。直したあとも、意見が好転したかではなく、同じ場所を通過できたかを確認できます。

一方で、代償があります。止まった箇所の観察は、意見の回収より1回あたり時間がかかります。時刻と直前の操作を照合し、同じ停止かを判断する必要があるからです。

そのため、何でも詳しく記録しません。重要なタスクを絞り、停止の前後だけを丁寧に残します。時間をかける場所を限定すると、分析の重さを管理できます。

自社ECで見えた価値のずれも、同じ見方で整理できました。物流という想定だけでなく、ドアノブの紙やテーブルのシールを見て動いた行動を残しました。この経験は、oh!Bagの事例にもつながっています。

⑧ 現場で使うなら、この記録シート

現場では、次の形で記録します。参加者の感想を消す必要はありません。ただし、感想だけを独立した票にせず、行動と同じ行に置きます。

タスク	止まった箇所	その場の行動	直す仮説
目的の入口を探す	入口の説明	説明を読み、前の画面へ戻る	入口で対象者と得られる結果を示す
必要事項を入力する	入力後の確認	入力画面と説明を往復する	確認に必要な条件を入力前に置く
完了後に次の行動へ進む	完了画面	画面を閉じ、次の操作へ進まない	次に取れる行動を一つ示す

「止まった箇所」には画面名だけでなく、要素まで書きます。「その場の行動」には解釈を入れません。「困惑した」ではなく、「同じ文を読み直した」「前画面へ戻った」と書きます。

「直す仮説」は決定事項ではありません。停止を減らせそうな変更を一つ置き、再テストで確かめます。複数案があるなら行を増やすのではなく、最初に試す案を一つ選びます。

なお、表のすべてが埋まっても、日常で使う理由までは証明できません。完遂したのに本番で使われない場合は、普段の導線、待ち時間、別の選択肢との関係を別に観察します。

結果の分析

分析では、観察記録を付箋などに分け、画面やタスクの流れへマッピングします。その後、問題の深刻度と頻度をマトリクスで見ます。頻繁に起き、目的の達成を妨げる問題から優先します。

ただし、記録の単位は「意見」ではなく「行動が止まった箇所」に置きます。「文字を大きくしてほしい」を一件と数えるより、どのタスクのどの画面で読む動きが止まったかを一件にします。同じ停止に複数の意見が付くこともあります。

優先順位は、深刻度と頻度だけで機械的に決めません。目的の行動へ与える影響も見ます。軽い違和感が多く出た画面より、一度でも先へ進めなくなった入口を先に直す場合があります。付箋は票ではなく、行動の位置を共有する道具です。

分析会では、まず参加者ごとの時系列を崩さずに読みます。画面別に付箋をまとめる前に、「入口を探す」「条件を理解する」「入力する」「確認する」「完了後に次へ進む」というタスクの流れへ置きます。同じ画面でも、入口を探して戻った人と、入力内容を確かめるために戻った人では原因が違うからです。

次に、観察した事実、参加者の発言、分析者の解釈、修正案を別の列にします。「迷った」は解釈です。「確認画面から入力画面へ戻り、同じ項目を二度開いた」が事実です。「入力条件を確信できなかった」は仮説で、「条件を入力欄の前へ移す」は修正案です。この四つを一文に混ぜなければ、別の分析者が修正案だけに反対しても、元の観察まで消えません。

区分	書く内容	記入例
観察した事実	画面、操作、時刻、直後の行動	確認画面から入力画面へ戻った
参加者の発言	その場で話した内容	「どちらを選んだか確認したい」
解釈	なぜ止まったかの仮説	選択結果を確認画面で確信できない
修正案	次に試す変更を一つ	確認画面へ選択条件を表示する

問題を束ねるときは、似た言葉ではなく同じ行動でまとめます。「分かりにくい」という発言が三つあっても、止まった箇所が異なれば三つの問題です。反対に、「不安」「長い」「見つからない」という別々の発言が同じ入口で起きていれば、一つの停止に複数の解釈が付いている可能性があります。付箋の枚数をそのまま人数や問題数として報告しません。

優先度は、次の順で判断します。最初に、目的を達成できない、誤った結果になる、取り返しのつかない操作につながる問題を見ます。次に、複数人または複数タスクで繰り返された問題を見ます。最後に、修正によって後続の流れまで改善できるかを見ます。頻度が低くても、申込みを完了できない問題は先に扱います。頻度が高くても、表記の好みだけで行動が変わらない問題は後に回せます。

優先度	行動への影響	現場での扱い
最優先	完遂できない、誤った結果になる、回復できない	公開や次工程の前に修正し、同じタスクで再テストする
高	自力で回復できるが、大きな往復や時間を要する	原因仮説を一つ選び、次の反復へ入れる
中	完遂できるが、複数人に同じ停止がある	他の変更と干渉しない範囲で試す
保留	感想はあるが行動への影響を確認できない	本番データまたは次回観察で確かめる

修正案は、一つの問題に一つだけとは限りません。ただし、同時に複数箇所を変えると、どの変更が行動を変えたか分からなくなります。入口の名称、位置、説明量の三案があるなら、最も原因へ近い一案を選びます。選ばなかった案も消さず、採用条件と一緒に残します。再テストで同じ停止が続いたとき、次の案へ戻れるからです。

担当者と期限は、修正作業だけでなく再確認まで置きます。「文言を変更して完了」ではなく、「文言を変更し、同じ募集条件とタスクで入口を通過できるか確認して完了」とします。実装が重い場合は、紙やクリックできる試作で先に順序と名称を試せます。変更量を小さくするのは、対応を楽にするためだけでなく、観察と原因の関係を保つためです。

報告時には、見つけた問題の総数を成果にしません。今回答えた問い、答えられなかった問い、次に変える箇所、再テスト日を冒頭に置きます。参加者がタスクを完遂しても、本番でその行動を選ぶとは限らないことも注記します。ユーザビリティテストで確認した範囲と、利用ログや現場観察で別に確かめる範囲を分ければ、テスト結果を事業全体の評価へ広げすぎません。

⑨ この考え方が効き続ける理由

製品の画面や技術が変わっても、人の言葉と行動が一致するとは限りません。「使いやすい」という評価は、その場の礼儀や期待にも影響されます。一方、止まる、戻る、読み直すという行動は、改善する場所を残します。

また、行動を単位にすると、ユーザーを責めにくくなります。「理解してくれなかった」ではなく、「ここで前画面へ戻った」と共有できるからです。問題が出たら製品を疑うという原則が、報告書の書き方にも残ります。

そして、テストで分からないことも明確になります。操作が止まらなかったなら、さらに指摘を探す前に、本番で採用される条件を見ます。「使いにくさ」と「使う理由がない」を混ぜないためです。

少人数で早く試し、止まった箇所を直し、もう一度見る。この反復は今後も使えます。ただし、テストの成功を利用の成功とは呼びません。答えられた問いの範囲を守ることが、次に見るべき現実を教えてくれます。

僕らは、行動が止まる箇所の観察から改善を設計しています。

費用と期間の考え方

費用と期間は、被験者の集め方、対象者の見つけにくさ、録画の有無、実施場所、タスク数、分析の粒度で動きます。「時間と費用がかかる」で止めず、どの条件が重いかを分けて見積もります。

たとえば、既存ユーザーへ協力を依頼できる場合と、細かな条件で新たに探す場合では、募集の手間が違います。録画をすべて見直して行動を詳細に起こす場合と、当日の記録を中心にまとめる場合でも、分析期間が変わります。

まず、今回の意思決定に必要な証拠を決めます。入口の迷いだけなら、タスクを絞れます。複数の利用場面を比較するなら、募集と分析が増えます。費用を決めるのは「テストをするか」ではなく、「誰の、どの行動を、どの細かさで残すか」です。

よくある質問

ユーザビリティテストとは何ですか？

対象の製品やサービスをユーザーに使ってもらい、使いやすさをユーザー視点で明らかにする評価です。画面を見せて感想を聞くだけではなく、目的の操作をしてもらい、どこで迷い、止まり、戻ったかを観察します。目的は、作り手の想定と実際の行動のずれを見つけることです。

ユーザーテストとの違いは何ですか？

ユーザーテストは企画や価値を含めて反応を広く確かめる意味で使われ、ユーザビリティテストはその中でも利用時の有効さ、効率、満足度に焦点を置く呼び方です。現場では同じ意味で呼ぶこともあります。名前より、依頼文に「価値の評価」か「操作の評価」かを一行で書いて先に合わせます。

ユーザビリティテストは何人でやればいいですか？

5人がよく目安になります。背景には、一度に大人数を集めるより、少人数で問題を見つけて直し、再び試すほうが効くという整理があります。ただし僕は「何の問題に対しての5人なのか」を先に決めます。初心者と経験者のように複数グループがあるなら、全員を一つに数えず、各グループへ人数を配分します。

ユーザビリティテストはいつ実施しますか？

完成後に限りません。企画の初期、設計中、開発途中、公開前、公開後のどこでも行えます。早い段階なら、紙のワイヤーフレームも評価対象になります。押せない紙でも「次にどこを押すと思うか」は観察できます。画面の完成度ではなく、判断の締切から逆算して実施します。

タスクはどう作ればいいですか？

ユーザーが現実に達成したい目的として書きます。「右上の申込みボタンを押してください」と操作を教えるのではなく、「条件に合う申込み方法を探してください」と渡します。シナリオには状況と目的を含め、正解の場所は含めません。迷ったら「その行動は、指示されなくても現実に起こるか」と考えます。

思考発話法とは何ですか？

操作中に考えていることを声に出してもらう方法です。「今、探しているもの」「次に起きると思うこと」を話してもらうと、行動だけでは分からない解釈を補えます。モデレーターは答えへ誘導せず、沈黙が続いたら「今、何を見ていますか」と現在の状態を尋ねます。

対面とリモートはどちらがよいですか？

対面は手元、視線、姿勢を含めて観察しやすく、機材の不具合にも対応しやすい方法です。リモートは場所を問わず参加してもらいやすく、普段の端末や環境に近い状態を見やすい利点があります。オンラインでは通知や個人情報が映る可能性を説明し、通信の停止と製品上の停止を記録上で分けます。

ユーザビリティテストの費用と期間はどう見積もりますか？

被験者の集め方、対象者の見つけにくさ、録画の有無、実施場所、タスク数、分析の粒度で動きます。既存ユーザーへ依頼できる場合と、細かな条件で新たに探す場合では募集の手間が違います。費用を決めるのは「テストをするか」ではなく、「誰の、どの行動を、どの細かさで残すか」です。

テスト結果はどう分析しますか？

観察記録を付箋などに分け、画面やタスクの流れへマッピングし、問題の深刻度と頻度をマトリクスで見ます。ただし記録の単位は意見ではなく「行動が止まった箇所」に置きます。同じ停止に複数の意見が付くこともあります。軽い違和感が多い画面より、一度でも先へ進めなくなった入口を先に直す場合があります。

何を記録すればいいですか？

時刻、タスク、止まった画面、直前の操作、次に取った行動を並べます。「迷っていたようだ」ではなく、「入力後に前画面へ戻り、同じ説明を再び開いた」と書きます。僕は記録の単位を意見から行動へ変えたことで、指摘の件数で順位を付けなくなりました。感想は消さず、行動と同じ行に置きます。

ユーザビリティテストで分からないことは何ですか？

「できたし、困らなかったが、使わない」という状態です。タスクを渡した時点で、参加者には実行する前提が生まれ、採用しない自由が構造的に消えます。僕が作った社内RAGは検索精度95%でデモも通りましたが、本番では置き場所と速さが理由で1か月後にアクセスがほぼゼロになりました。

AI UX/UIデザインについて相談する／お問い合わせ

最後に余談です。

観察メモを取り始めると、日常でも人の手元が気になります。券売機の前で止まる人を見ると、画面より先に記録シートが頭に浮かびます。もちろん、知らない人の後ろでメモを取ると、別の問題が始まります。

以上です。