何考えてるかオシエテ！ユーザーテストってナ二
現在5人グループで制作しているのアプリのユーザーテストを先日行いました！
初・体・験！😘
授業の一環だったのでユーザーテスト当日は先生やら他の生徒さんの前で発表する形で行ったのでかなり緊張しましたが、いい経験でしたので忘れないうちに書き残しておきたい、ということで書いていくゥ((φ(-ω-)ｶｷｶｷ
そもそもユーザーテストって何のためにやるの？
「ユーザビリティ検証（デザイン上の問題を見つけること）」のためにやります。
要は「スタートからゴールまで迷わず行けるかの検証」。
より使い勝手のいいアプリ開発のため、Fact（事実）収集を行います。
今回のユーザーテスト当日の流れ
▼登場人物👨👩
・モデレーター（インタビュー、進行する人）🎤
・モニター（テストを受ける人）👤
・録音・録画係（会話の録音や操作する手元を映す）📷
・記録係（モニターの言動、会話、操作する手元を書き残す人）👩💻
・タイムキーパー🕑
☝️この体制でユーザーテストは進んでいきました。
ユーザーインタビューとも合わせて50分。そのうちの30分くらいをユーザーテストにの時間にあてました。（ユーザーインタビューに関しては別記事で書きます）
私たちが設定したタスクをモニターに実行してもらいます。
私たちのユーザーテスト計画
前提：私たちの制作アプリ概要
学生時代、毎朝何も考えず制服を着ていた頃のように、今日のコーディネートを提案することによって日常生活の選択の時間を短縮するための服装提案アプリを制作中。
メイン機能①：普段の1週間分のコーディネート提案
メイン機能②：宿泊を伴う遠出に必要なコーディネート提案（要は旅行とか出張とか）
🔷タスク設計🔷
1.ユーザーテストで何を得たいかを確認
→開発中アプリのメイン機能のユーザビリティ調査
2.検証する体験を決める
検証する時間は限られているので、（私たちは30分でした）その中で得たい情報を明らかにするためのタスク（検証項目）を決めます。
・アプリに手持ちの洋服を登録する
・旅行に行く時のコーディネートを確認
▼1つ目のタスク
制作中のアプリはユーザーが洋服の写真をアプリに登録せんことには始まらないアプリでした。
なので、一番最初にするであろうアクション、「洋服登録」は本当にラクに、かつ躓いてはならないステップだと思い、ひとつ目のタスクに選ばれました。
▼2つ目のタスク
このアプリの二つ目のメイン機能は、宿泊に必要な服装を旅先の気温なんかにあわせて丸ごと全部提案してくれるので、パッキングのおともに便利！
と言うものなのですが、このアプリを知らない人が果たしてこの機能を使いこなせるのか、、と言うことで検証することに。
3.上記で決めた検証する体験に必要な画面を洗い出し、スタートとゴール（完了画面）を決める【ツール：Figma】
上記で決めた二つのタスクから得たい情報を明らかにするためには、どの画面からスタートして何を完了させられたらそれが達成したことになるのかを考えて決めます。
4.デザイン、プロトタイプを組む【ツール：Figma】
元々デザインはあらかた制作していたので、プロトタイプを組んで自分たちで試しては修正、の繰り返しで人に試してもらえるレベルのプロトタイプまで繰り返し修正作業をしていきます
5.画面ごとに仮説をたてる【ツール：スプレッドシート】
「ユーザーがデザイン、プロトタイプのどこで躓くか？」と言う観点で、検証する画面ごとに仮説をたてます。
・「ラベルがわからないのではないか」
・「次の画面に進めないのではないか」
・「ボタンに気付けないのではないか」
など
2つの検証項目をそれぞれページ分けて操作フローを細かく分解し、スプシに書き出していました。
スプシじゃなくてもいいと思うのですが、ここに後々Fact（事実）や質問を書き込んでいくので照らし合わせやすくて良かったと思います。
6.質問を考えておく【ツール：スプレッドシート】
こちらも検証する画面ごとに想定される質問を書き出していました。
・「今何を探していますか？」
・「どうして手を止めていますか？」
・「（このボタンを押すと）何ができると思いましたか？」
あらかじめ用意しておくとテスト中テンパった時のために便利です。
ただ、当日はモニターの操作する手元や表情を集中して観察しなければいけないので、考えておいたとてスプシを見る暇も正直無かったです。
なので書き出した質問は大枠を頭に叩き込んでおく程度でいいと思います。
7.状況設定をする【ツール：パワーポイント】
ユーザー（モニター）の日常に近い状況を考えて設計するとタスクが伝わりやすいと言うことで、状況（シナリオ）を設定していきます。
そもそも開発者の意図をモニターは把握していないので、「洋服の登録をしてください」といきなり言われても？？？です。
と言うことでユーザー視点でなるべく操作指示にならないように設計しまし
た。
▼状況設定
・あなたは洋服を買いました
・このアプリに新しく買ったデニムパンツと白のTシャツを登録しようと思っています
・洋服はすでに写真を撮ってスマホ内に画像データあります
▼実行していただきたいこと
このアプリに今日購入した洋服2点を登録してください
ユーザーテスト中は上記内容を声で読み上げて説明をしましたが、パワポを印刷してモニターがいつでも状況とタスクは確認できるようにしておきました。
→口で説明しても操作中、「あれなんだっけ？」と思ってそうな様子が結構あったので、用意して良かったです。
🔷ユーザーテスト最中🔷
▼モデレーター
7で設定した状況を説明していざモニターにはタスクを実行してもらいます。
モニター自身がタスクが完了したと思ったら「完了しました」と私に伝えてもらうようにしていました。
どの画面が完了と認識しているかを確認したいためです。
なので「完了しました」の一言があるまでは一連の操作をじっと観察して口を挟むのをガマン⁝( `ᾥ´ )⁝！
「この画面の表示時間が長いけど何を考えているんだろう」
「このボタンのタップを繰り返しているけど、どんなアクションが起こると思ってタップしているんだろう」
「このボタンを押さなかった理由はなんだろう？」
などなど聞きたいことを最後にまとめて質問します。
全部記憶しておかなければな結構大変でした。
また、「この画面でここに遷移した後、また戻ってこのボタンを押していましたが、なぜ戻ったのですか？」など一連の長れに対して質問したりもするのですが、モニターは結構「そんな動作したっけ？」と忘れているので（無意識だからかな）、モデレーターの私がその時の操作の流れを再現したりして思い出してもらっていました。
これはその時何を考えていたか聞くのに結構良かったかなと思います。
▼記録係
・5,6で用意したスプシに操作メモ欄を作り、ひたすら事実（Fact）を書く
・切り抜きの際にトリミングボタンを押した
・設定を押してから戻ってイベントボタンを押した
・この画面の表示時間が長かった
ここで注意なのがFact（事実）と解釈をごちゃ混ぜにしないことです。
「この画面では表示が長く次の行動に悩んでいた」
などは開発側の解釈であり、悩んでいたかどうかはモニターにしかわからないので事実とは違います。
バイアスのかかった分析にならないよう、事実は事実、解釈は解釈で分けて記録を残しましょう。
・モデレーターが質問した内容についての回答なども全て書き残す
🔷ユーザーテスト後🔷
検証画面をひとつひとつフロー順に並べてFigjamに貼り付け、先ほど書き残した事実（Fact）を元にインサイト（仮説）を付箋で書き残していきました。
カードのチェックボックスを連打していた（事実）
なぜ？→アイテムを編集できると思った（モニターの回答）
👉ミートボールメニュー（noteでも使われている三点リーダーのアイコン）に切り替え、アイテム編集出来るようにしたら想像通りの動きを再現できるのでは（仮設）
👉タップでカードを非アクティブにすれば、確認済みというのが視覚的にわかりやすいのではないか（仮設）
こういったインサイト（仮設）を元にネクストアクション（改善案）を考え、よりユーザビリティの良いアプリへ修正していきます。
感想
アプリ画面をデザインすることはあるのに恥ずかしながらユーザーテストの流れを知らなかったのでこういった流れを知ることができて本当に良かった、、！
細かい反省点は無限にあるのですが、一旦ここでしめようと思います。
これはぜひ実務でも活かしていきたい、、！
おまけ
▼ユーザーテストする前に
会社の上司をはじめいろんな人にプレに付き合ってもらいました。
結構モニターさんを前にするととても緊張するので（想定外なことだらけだし）プレやって良かったです。
▼今回務めたモデレーター役に対してのフィードバック
「チュートリアルを読んでいただいたかなと思う」ではなく、
「チュートリアル画面に時間をかけていたように見受けられた」と
事実ベースで質問した方が吉。
モニターさんは「読んでないです」と回答していたので、
読むこと以外の別のことで時間がかかっていたことにもっと早い段階で気づけるのでは。
→「読んでいたかどうか」はモニターさんしかわからないので「読みましたか？」「どんなアプリと感じましたか？」聞いた方が事実（Fact）を集められそう
ボリューミーな文章を書くのに慣れてないので誤字脱字多いかも、スマセン！😭
最後まで読んでいただきありがとうございました！
※アプリ制作と言っても授業の課題なのでプロトタイプまでです