Unity Learn のチュートリアル1を個人的にまとめたかったので，メモしておく．
要約
このチュートリアルで学ぶこと：
- ユーザーフィードバックの目的
- ユーザーテストを設計・開発プロセスにどのように組み込むか．
- フィードバックセッションを実施し，ターゲットユーザーから実用的なフィードバックを得るためのヒント．
概要
リアルタイム3D体験を作成するとき，ターゲットユーザーへの調査に基づき，ユーザーニーズに対応する必要がある．
ユーザーテストとフィードバックは，理想的には，開発サイクルを通じて，デザイン，プロトタイプ，リアルタイム3D体験をレビューする実際の人々と一緒に，プロジェクトを「現実的に」チェックする機会である．
ユーザーテストとフィードバックって何？
ユーザーテストの目的は，製品を体験としてテストすること．
ユーザーテストのアウトプットは，作成中の体験を評価し，改善するために使用できる実用的なフィードバックとなる．
ユーザーテストは，一度のみではなく，制作の全フェーズを通じて実施すると，ユーザーのニーズを満たす製品を作ることができる．
また，ユーザーフィードバックのプロセスに参加することで，特定のユーザーニーズに対応するソリューションのスコープ，設計，実装のスキルを発展させることにもつながる．
なぜ構造化されたユーザーテストを実施するのか？
ユーザーテストは，単に製品を前にして感想を聞くだけではない．
ユーザーテストは，テスターからできるだけ多くの具体的で有益な情報を得るために設計された，構造化されたプロセスである．
また，ユーザーテストに協調的に取り組むことで，様々なユーザーからデータを収集し，その反応を比較して，評価と改善の決定をサポートするためのより良いデータセットを得ることができる．
理想的には，いかなるプロジェクトでも，プロジェクトの設計と開発の様々な段階でいくらかユーザーテストを行う必要がある．
「まだ準備できていない．できたら人に見せてフィードバックをもらおう！」と思うのが自然な気持ちですが，
プロジェクトが洗練された状態になるころには，フィードバックによって明らかになるかもしれない大きな変更ができなくなる可能性が高い．
代わりに，早く，そして頻繁にテストをしよう！テストと改良をやればやるほど，最終的な製品はより良いものになるはず．
ユーザーテストのフェーズ
ユーザーテストのプロセスのハイレベルな構造：
- 目的を定義する．
- セッションを計画する．
- セッションを促進する．
- 結果を評価する．
ユーザーテストの計画
目的を定義する
ユーザーからフィードバックを得るための質問を用意する前に，決めておくべきこと：
- プロジェクトについて学びたいこと
- ユーザーからフィードバックを得るために見せるもの
- 例：枠組み，デザインモックアップ(設計モデル)，プロトタイプなど
質問を準備する
次に，ユーザーからのフィードバックの指針となる質問を用意する必要がある．
求めるフィードバックの種類によって，自由形式(open-ended)の質問，選択形式(closed-ended)の質問，あるいはその両方を組み合わせて質問する．
自由形式の質問の例：
- 設計・プロトタイプ・製品はどの程度ユーザーニーズに対応していると思いますか？
- テスト中に困惑した瞬間とその理由を教えてください．
- この体験をどのように改善しますか？
これらの質問は，会話を通じることでより効果的になる．
フォローアップの質問をすることもできるし，テスターの考えをより深く理解することができる．
選択形式の質問の例：
- ユーザーの反応を評価するためのステートメント
- 例：1から5までで評価してください．
- Yes/Noで答えられる質問
これらの質問は，調査やアンケート形式で行うのが効果的．
テストセッションを計画する
物流(logistics)を考慮する：
- 最適な日時を特定する．
- ターゲット層からテスターを見つける方法を決める．
- 理想的なテスターの人数を特定する．
- テストセッションのアジェンダを作成する．
- セッションを記録する．(該当する場合)
- チーム開発のとき，セッションのリーダーとノートテイカーを選ぶ．
セッションを実行するための準備
ユーザーテストは，効果的に実施するのが難しい．
セッションを計画したら，促進の準備をする必要がある．
以下のヒントを参考にして，準備をしよう．
ガイドよりも観察する
テストを直接行う場合，ユーザーが体験を試したり，デザインをレビューしているとき，何も言わず座っていることは非常に困難かもしれないし，ユーザーが苦労しているときは口をはさんでやり方を教えたくなるかもしれない．
ここで，バランスをとる必要がある．
もし，テスターが基本的なことで悩んでいて，製品をテストできないときは，少なくとも30秒待って，それをメモし，どうすればいいかを教えて，より情報を得られるようにしよう．一方，テスターが問題を解決できたとき，その解決策はデザインを改善するための貴重な情報に得る．
デザインの選択を説明や正当化をしない
質のいいフィードバックを得るとき，例えば，テスターと会話することで，再び物事を説明したり，プロジェクトの現在の実装を正当化したりしたくなるかもしれない．
これは，テスターの理解を「修正」することになるので，気持ちのいい子とかもしないけど，
それではテストしているものを修正することはできない！
テスト中に問題解決をしない
テスト中に出てきたユーザーの洞察を見ると，すぐに問題解決モードに入り，出てきた問題をどう修正するかを考えるかもしれない．
テスターも，自分の体験に集中するのではなく，自分の考える解決策に可能性を探り，これに集中し始めるかもしれない．
これらの解決策の提案に価値がないわけではないが，テストセッションの目的は，ユーザーの経験についての洞察を得ること，ユーザーの問題についての深い情報を得ることである．
代わりに，観察者の役割に徹し，テスターが語ることを積極的に聴く準備をしよう！
また，テスターが説明していた問題や次の質問に戻るようにやさしく誘導する準備もできる．
もし自信がなければ，同僚のクリエイターと一緒に練習してみるのもいいかも．
セッションの促進
テストセッションの構成：
- グループとしてテストするとき，自己紹介をする．
- セッションの目標を明確にする．
- 録音方針を説明し(該当する場合)，テスターの同意を確認する．
- テスト用の素材を提供し，テスターがそれを使用またはレビューするのを観察する．
- 用意した質問をする．
- 参加者の解答を明確にするために，要約を提供する．
- セッションを終了する．
促進するためのヒントとコツ
- どんな製品もフィードバックによってより良いものになるのだと，自分に言い聞かせる．
- 参加者のために，体験の枠組みを作る．
テスター一人ひとりと会話し，ユーザーテストが何であるかを説明する．
いかなるフィードバックも必要であり，ネガティブなフィードバックの方がポジティブなものよりも役に立つことがあることを強調する．
製品の使用中やレビュー中にできるだけ多くのことを「ナレーション」してもらうことで，彼らの思考プロセスをより深く理解することができる． - テストが始まったら，必ず話を中断して，観察したことを詳細に記録する．
ユーザーが困っていることは何か？意図したとおりに使えていない機能はないか？意味のない操作をしていないか？ - もしユーザーがしばらく話すのをやめたら，もう一度内面的なモノローグをオンにするようにやさしく注意するが，それ以外は一方通行の鏡の後ろにいるふりをする．
- 複数のテスターと会話する場合は，必ず全員を参加させること．
テスターの洞察が含まれていることを確認するために，静かなテスターの考えをそっと促す．
セッションを終えて
テストセッションの直後：
- セッションが記録されていることを確認する(該当する場合)
- その他の注意事項や観察事項があれば書き留める．
- チームメンバーとディブリーフィング(報告会)(該当する場合)
- 取り組むべき分野を強調した概要文書を作成する．
- 収集したデータやフィードバックに基づき，何を変え，何を変えないかを決定する．
フィードバックの評価と対応
メモとアンケートをよく読み，結果の要約を箇条書きにする(以下は例)：
- 「ユーザーは塔の種類に気づいていなかった」
- 「ユーザーはインコンテキストメニュー(GUI)を理解しやすく，使いやすいと感じた」
そのうえで，改善が必要と思われる各課題に対して，どのような対応が可能か，
また，それらの対応に依存するものがあるかどうかを検討する．
ユーザーが何を伝えようとしているのかに耳を傾けることは重要である．
もし，製品の重要な部分がうまく機能していないのであれば，修正することに集中するために，
いくつかの機能をカットすることに価値がある．
ミニ製品評価
ユーザーテスターを自分に割り当てる．
- あなたがよくできていると思う製品を数個選ぶ．
例えば，ゲームやソフトウェア，キッチン用品でもなんでもいい - なぜその製品が好きなのか，理由を考えてみる．
- どのようなユーザーニーズにこたえてくれるか．
- ユーザーとして，プラスになることは何か．
- 使ってみた感想は？
- 使い始めてからの学習曲線はどれくらいの勾配だったのか．
- 他の人に薦めたいと思う？また，その理由は？
- 改善すべき点があるかどうか，今一度考えてみる
- その製品では，十分に対応できない，関連するユーザーニーズがあるか？
- ニーズというより対応できていない欲求があるのでは？
- 使用感をもっと改善できる部分はあるのか．
- 製品を設計・製造した人たちに一言伝えるとしたらどんなこと？
- 書き上げた製品へのフィードバックを，もし自分が開発チームの一員のとき，十分な情報を与えてくれるものか，評価する．
- ユーザーが製品を使用する際のプラスとマイナス面を明確にしているか．
- ユーザーの問題点を解決するために，どのようなアクションが考えられるか．
そうでない場合は，その情報を得るための追加の質問を特定してほしい．
これは，何かのユーザーテストの準備をするときに，質問の範囲を広げるのに役立つ．
経験を共有する
ポケモンが好きなので，最新作の剣盾について書いてみました．
このPDFファイルに貼っておきます．
これに関してフィードバックをくれる方がいらっしゃったらうれしいです．
追記
字が汚くてすみません．
サマリー
このチュートリアルでは，ユーザーテストを設定するためのプロセスを確認し，
ユーザーテストが持つ課題と利点の両方を考慮した上で，ユーザーテストを設定した．
ユーザーの声に真に耳を傾けることは，特にネガティブなフィードバックの場合，難しいかも．
しかし，最高の体験を実現するためには，製品が単独で成立することが重要である．
ネガティブなフィードバックは，製品を評価していないのではなく，
ユーザー体験に機能していなかったり，ニーズを満たしていないからである．
フィードバックと自分の体験を批評的に評価し，
ターゲットに対して特定されたニーズによりよく対応するための変更を実施することで，
体験の質を向上させることができる．