第24章 人間を見て確かめる
デザイナーが感じた違和感は、丁寧に言語化しても仮説です。人が実際に使う場面を見ると、予想した場所では止まらず、別の言葉で迷い、意図しなかった回復方法を見つけることがあります。
本章では、完成度を評価するためではなく改善点を見つけるための小さなユーザビリティテストを計画し、行動、発言、システム上の出来事を分けて記録します。一人の観察を大切にしながら、一人を「ユーザー全体」へ一般化しない方法を学びます。
24.1 デザイナーの違和感は、まだ仮説である
「カテゴリーの重複で迷うはず」「ボタンが小さくて押せないはず」は、観察計画を作る候補です。参加者へその言葉を伝えると、同じ問題を探させてしまいます。
仮説、反証条件、代替仮説を事前に残し、セッション中は起きたことを記録します。予想外の行動をエラーとして片付けず、タスク、プロトタイプ、説明、環境のどこに由来するかを後で考えます。
24.2 誰に、何をしてもらうか
「一般ユーザー」ではなく、利用経験、業務知識、使用機器、支援技術、言語など、仮説に関係する募集条件を定めます。人口統計だけで代表性を語りません。
タスクは「この青いボタンを押してください」でなく、目標と必要な文脈を示します。「来週火曜に最も早く届く商品を選び、購入直前まで進んでください」のように、UI の言葉を答えとして含めません。成功条件、開始、終了、中止、ヘルプを事前に決めます。
24.3 説明しない、教えない、助ける条件を決める
進行役は沈黙を恐れて答えを教えないようにします。ただし「絶対に助けない」ことも倫理的とは限りません。苦痛、危険、個人データの誤送信、時間超過では止めます。
介入を、沈黙、誘導しない促し、タスク再提示、ヒント、答え、セッション中止の段階に分け、時刻と理由を記録します。ヘルプ後の完了は、独力完了と別の結果にします。
24.4 止まる、戻る、間違える、読み飛ばす
クリックだけでなく、停止、往復、スクロール、読み飛ばし、修正、別経路、ヘルプ要求を時系列で記録します。「迷った」は解釈です。まず「カテゴリー A→B→A を選択し、12 秒操作がなかった」と書きます。
停止時間の長さだけで困難を決めません。読んでいる、考えている、休んでいる、通信を待つ可能性があります。質問時点と発言原文を別に残します。
24.5 「使いやすかった」という発言をどう扱うか
セッション後の「使いやすかった」は大切な報告ですが、タスク中の行動を上書きしません。礼儀、期待、比較対象、質問の仕方が影響する可能性があります。
「どの場面でそう感じましたか」「予想と違った場所はありますか」と具体例を聞きます。発言原文、質問文、時点を残し、完了、時間、エラーと別の根拠にします。
24.6 思考発話法の利点と干渉
思考発話法は、参加者にタスク中の考えを声に出してもらう方法です。語の理解、予想、選択理由の手掛かりを得られます。一方、話すことが注意、速度、戦略を変えます。
発話を求める条件を手順に明記します。成績を比較したい場合は、声を出さない条件や事後インタビューを検討し、思考発話法の時間を無発話条件の時間と無条件に比較しません。進行役の「なぜ？」も後付け説明を促す可能性があります。
24.7 完了率、時間、エラーと観察メモ
完了率には分母と成功定義、時間には開始／終了、エラーには分類と回復を付けます。システム側の失敗、進行役によるヘルプ、参加者中止、欠測を同じ失敗へ押し込みません。
観察メモは、数値が生まれた過程を説明します。少数セッションの割合を精密な母集団率として報告せず、「5 試行中 3 試行で観察した」と実数を併記します。発見の重大さは頻度だけでなくリスクと回復可能性も見ます。
24.8 一人を見る。一人で一般化しない
一人のセッションでも、実際の経路、言葉、環境について多くを学べます。その人の困難を「例外」として消しません。同時に「ユーザーは皆こうする」と書きません。
誰に、どのタスクと条件で起きたかを書き、次の参加者で同じ仮説と別仮説を確かめます。サンプル数は研究目的、利用者の多様性、リスク、期待する推定精度、資源で決めます。「5 人なら十分」という普遍ルールは置きません。
24.9 倫理、同意、録画、個人情報
目的、実施者、所要時間、録画・音声・画面・イベントの取得、利用範囲、閲覧者、保存期間、撤回、中止、謝礼、問い合わせ先を、参加前に理解できる言葉で伝えます。媒体ごとに同意を分けます。
本番アカウントや実際の個人データを使わせず、架空データを用意します。参加者 ID への置換は仮名化であり、匿名化ではありません。顔、声、画面、固有の支援技術、業務内容、時刻などの準識別子から再識別され得ます。募集連絡先、同意、謝礼、調査データを別の保管場所・別権限にし、必要最小限だけ取得します。
撤回用の識別番号は、連絡先と調査 ID を長期に結ぶ対応表を避ける一案ですが、万能ではありません。元データが削除可能な期間と、匿名化集計、バックアップ、既に共有・公開した引用など個別削除できない段階を同意時に具体的に伝えます。「いつでもすべて削除できる」と約束しません。
雇用・教育関係など断りにくい募集では、評価者を募集担当者にしない、参加しなくても不利益がない、謝礼を過度な誘因にしない等の対策を取ります。仮説を先に教えないことは、目的やリスクを偽ることと同じではありません。必要な非開示は本当に必要か、最小リスクか、直接質問へ真実を答えられるか、セッション後の事後説明とデータ再同意が必要かを事前審査します。
24.10 問い――何を見たら、この仮説を見直すか
問い
「カテゴリーの重複が商品探索を難しくする」という仮説を、どう観察しますか。
答えの例
対象業務に近い参加者へ、商品名を直接示さない探索タスクを行ってもらいます。同じ参加者が元の画面と重複を除いたプロトタイプを行う場合、条件順とタスク項目を割り付けて釣り合わせ、学習と疲労を記録します。参加者内反復を独立な人数として扱わず、分析単位を事前に決めます。成功、開始／終了、カテゴリー選択イベント、A→B→A の往復、検索利用、ヘルプを定義します。思考発話は探索戦略を変える可能性があるため、主な成績比較は無発話条件で行い、終了後に事後インタビューを行います。
重複を除いても往復が変わらない、発見が悪化する、またはラベル理解で止まるなら、重複だけの説明を弱めます。操作成立、タスク難易度、学習、順序も先に点検します。
別の答え方
重複は複数のメンタルモデルを支えるかもしれません。最短時間だけでなく、参加者が使った業務用語と分類理由を聞き、作者の情報設計資料と分けて解釈します。
よくある考え方
5 人に見せて、使いやすいか聞きます。
注意点
募集条件、タスク、成功、質問、条件、反証、倫理がなく、人数を万能ルールにしています。
別題――倫理判断
直属の部下へ、勤務時間中の録画テスト参加を上長本人が依頼しようとしています。どうしますか。
答えの例
上長を募集、同意取得、個別録画閲覧から外します。参加・不参加が評価へ影響しないこと、撤回範囲、謝礼、閲覧者を明示し、可能なら独立した募集担当者と外部参加者を使います。それでも自発性を確保できない、リスクに比べ必要性が低い場合は実施しません。
別の答え方
録画をやめれば十分とは限りません。観察メモやイベントからも個人が特定され、権力関係は残ります。集団ワークショップなど別方法でも同じ問題を点検します。
よくある考え方
同意書へ署名してもらえば問題ありません。
注意点
署名の有無だけで、理解、自発性、撤回可能性、過度な誘因、選択の公正さは保証されません。
セルフチェック
- 参加者条件と現実的タスクを定義した
- ヘルプ条件と中止条件を決めた
- 行動、発言、システムイベントを分けた
- 思考発話の干渉を扱った
- 分母、開始／終了、エラー分類を決めた
- 同意、撤回、保存、削除を実施前に決めた
参考
- ISO 9241-11:2018 — ユーザビリティを利用者、目標、文脈と利用結果で捉える規格です。
- GOV.UK Service Manual, “Using moderated usability testing” — タスク、議論ガイド、個人データ、支援技術を含む実務導線です。
- GOV.UK Service Manual, “Usability benchmarking a website or whole service” — タスク成功、時間等を測る入口です。
- NISTIR 7741 — 形成的／総括的な調査と思考発話の成績干渉を考える資料です。