今日のアジェンダ

1. ユーザーテストの目的と進め方を知る
2. 他チームとプロダクトをテストし合う
3. フィードバックを分類して、改善の優先順位を決める
4. プレゼンテーションの構成を知り、準備を始める

なぜ、人に使ってもらうのか

作った本人は、初めて見る人の気持ちに戻れない

• どこを押せば何が起きるか、作った人は全部知ってしまっている
• 「分かりにくい場所」は、作った人にはもう見えない
• ペルソナ・シナリオ・要件は、ここまでは全部 仮説
• 動くプロダクトができた今、仮説を 実物で確かめられる

ユーザーテスト：ユーザーにプロダクトを実際に操作してもらい、その行動を観察して問題を見つける方法

少人数でも、問題は見つかる

ユーザーテストは、大がかりな調査でなくていい

• ユーザビリティ研究の定番の知見：5人テストすれば、問題の大部分 (約85%) が見つかる (ニールセンの調査)
• 1人目のテストから、作った人が気づかなかった問題が出てくる
• 人数を増やすより、直してはまた試す 回数を増やす方が効果的
• 今日は、他チームのメンバー2〜3人に使ってもらう

テストは「タスク」で進める

「自由に触ってみて」では、観察したい場面にたどり着けない

• タスク：ユーザーに達成してもらう具体的なお題
• ユーザーシナリオの「望む変化」を、そのままお題の形にする
• 1回のテストで2〜3個。達成できたかを判断できる形にする

例 (発表練習アプリの場合)：

あなたは明日、3分間の発表をします。このアプリで発表原稿をチェックして、直す場所を1つ決めてください。

タスク文に、操作手順を書かない

操作を書いてしまうと、「説明されなくても使えるか」を確かめられない

• 悪い例は、答え (操作手順) を先に教えている
• 良い例は、ゴールだけ を伝えている。どう操作するかはユーザーが探す
• ユーザーが道に迷うこと自体が、貴重なデータ

考えていることを、声に出してもらう

思考発話法 (Think Aloud)：操作しながら、頭に浮かんだことをそのまま話してもらう方法

• 「たぶんここを押すのかな」「あれ、戻れない」が、すべてデータになる
• 行動だけでは分からない「なぜそうしたか」が見える
• ユーザーが黙ってしまったら、進行役が「いま何を探していますか？」と声をかける
• 話しながらの操作は少し不自然になるが、得られる情報の方が大きい

テストの役割分担

2チームでペアを組み、それぞれの席で同時にテストを進める

ラウンドごとにユーザー役を交代して、全員が「使う側」と「観察する側」の両方を経験する

進行役の心得

テストを始める前に、ユーザー役へ必ず伝える

• 「テストされるのはプロダクトで、あなたではありません」
• 「うまく操作できなかったら、それはプロダクト側の問題です」

テストが始まったら

• 操作方法を教えない。手も口も出さない
• 質問されたら「どうなると思いますか？」と質問で返す
• 詰まっても、すぐ助けない。どこで詰まるかが今日一番の収穫
• どうしても進めなければ、そのタスクを打ち切って次へ

記録役の心得

解釈やまとめではなく、起きた事実 をそのまま書く

• 詰まった場所：どの画面の、どの操作で手が止まったか
• 想定外の操作：作った側の想定と違うボタン・違う順番
• 発言：「これ何？」「どこ押すの？」を原文のまま
• 結果：タスクごとに「達成 / 助けが必要だった / 未達成」

「UIが分かりにくかった」(解釈) ではなく、「原稿を貼る場所を探して3回スクロールした」(事実) と書く

作った側が、やってはいけないこと

フィードバックの受け取り方が、テストの質を決める

• 誘導しない：「ここを押せばできますよ」
• 弁解しない：「それはまだ作ってなくて」「本当はこう使うんです」
• 反論しない：「いや、そこは分かるはずです」
• その場で直し始めない：メモに残して、テストを続ける

説明したくなった場所は、説明なしでは伝わらない場所。すべてメモする

記録を4つに分類する

集めたメモは、種類によって扱い方が違う

タスクを達成できなかった原因になっているものから、順に見ていく

最終プレゼンの概要

第1回で説明した通り、バグや完成度そのものでの減点はしない
課題の捉え方・作る過程・そこからの学びを評価する

発表の基本構成：課題 → 解決策 → デモ → 振り返り

ライブデモの準備

デモは一番伝わるパートで、一番事故が起きるパートでもある

• 台本を決める：見せる操作の順番を固定して、通し練習する
• 入力データを用意する：その場で文章を考えない。原稿や画像は事前に準備する
• 動く状態をcommitしておく：発表直前に新機能を足さない (第6回)
• 保険を用意する：動かないときに備えて、操作の様子を 画面録画 しておく
• 当日の環境を想定する：教室のWi-Fiとプロジェクタで動くか、事前に確認する

今日のまとめ

次回：第8回 最終プレゼンテーション

チームごとに最終プレゼンテーションを行う。発表内容は、課題定義と解決策、動作するプロダクトのライブデモ、開発プロセスの振り返り (技術選定・チーム分担・AI活用の工夫)、ユーザーテストの結果と改善点など。講師と受講生全員による質疑応答や感想共有の時間をとる。

提出物：スライドPDFを発表前日の23:59までにMoodleへ。当日は、動くプロダクトが入ったPCを持参してください

a日程：7/21 (火)　b日程：7/28 (火)