見出し画像

ユーザーからのフィードバックをもらう

hakuro

Unity Learn Junior Programmerをやっています。
「ユーザーのフィードバックとテスト」の項目をメモに残します。

気になるかたは、Unity Learn Junior Programmerをやりましょう。
もっと理解が深まるかもしれません

概要

ユーザー テストとフィードバックは、プロジェクトの「現実性をチェック」する機会です。制作前に作成したユーザー ペルソナと照らし合わせて、理想的には、開発サイクル全体を通じてデザイン、プロトタイプ、リアルタイム 3D エクスペリエンスをレビューする実際の人々と比較してください。 。

ユーザーテストとフィードバックの目的は？

デザインとその現在の実装が、ユーザーの要望をどの程度満たしているかに関して、定性的、定量的に情報を収集することです。
ユーザーテストは一度やったらおわり、ではありません。
実稼働段階全体に組み込む必要があります。
これにより、高品質の最終製品が保証されます。
ユーザーフィードバックプロセスに参加することは、特定のユーザーニーズに対応するソリューションの範囲設定、設計、実装のスキルを向上させることに役立ちます。

まだ準備できてません、完成したらみてもらいますので！
という気持ちはよくわかるのですが、途中途中で適切なフィードバックを重ねるほどに、最終製品はより良いものになります。

ユーザーテストの段階は4つ

テストの計画設計、目標の定義
セッションの計画
セッションの信仰
結果の評価

ユーザーテストを計画しよう

目標の定義
　・プロジェクトについて知りたい事はなにか
　・フィードバックを引き出すためにユーザーに表示するものはなにか

質問の準備
　自由回答形式の質問
　クローズド質問、はいやいいえで回答するもの

両方のタイプの質問を使用すると、テスターによっては直接話すよりも正直で批判的なフィードバックを得られることがあるため役立ちます。

テストセッションを計画しよう

テストの質問を定義したら、検討すべき事項があります。あなたがすべき：

  • 最適な日時を特定します。

  • 対象ユーザーからテスターを見つける方法を決定します。

  • 理想的なテスターの数を特定します。

  • テスト セッションの議題を作成します。

  • セッションを記録する計画を立てます (該当する場合)。

  • チームで作業している場合は、セッションのリーダーとメモを取る人を選択します。

テストセッションの実行準備をしよう

効果的にテストを実施するのは難しい場合があります。
計画したらそれを促進する準備が必要なのです。

・ガイドするのではなく観察する
・デザインの選択を説明したり、正当化したりしない
・テスト中に問題を解決しない

テストセッションの目的はユーザーの経験について洞察を得て、問題についての深い情報を入手することです。表面的に解決したら、それで終わりになってしまいます。
解決するかわりに、テスターの話に積極的に耳を傾け、観察の役割を続ける準備をしてください。また、テスターに次の問題、質問へ優しく誘導する準備もできます。
これを行うことが難しい場合は、他のクリエイターと一緒に練習してみてください。

セッションの進行

テスト セッションを構築する方法はさまざまですが、ファシリテーターは通常、次のような大まかな構造を使用します。

  • グループでテストする場合は、自己紹介を行います。

  • セッションの目標を特定します。

  • 録画ポリシー (該当する場合) を説明し、これに対するテスターの同意を確認します。

  • テスト用の資料を提供し、テスターがそれを使用したりレビューしたりする様子を観察します。

  • 用意した質問をしてください。

  • 説明を目的として、参加者の回答の要約を提供します。

  • セッションを閉じます。

ファシリテーションのためのヒントとコツ

ここでは、ユーザー テスト セッションを促進するのに役立つヒントとテクニックをいくつか紹介します。

  • あなたはあなたの製品ではないことを思い出してください。すべての製品はフィードバックによって改善されますが、それはユーザーの意見に注意を払っている場合に限ります。

  • 参加者の体験を枠組み化します。各テスターが到着したら、彼らと話し、ユーザー テストとは何なのかを説明します。すべてのフィードバックが必要であることを強調し、実際には肯定的なフィードバックよりも否定的なフィードバックの方が役立つ場合があります。製品を使用したり資料をレビューしたりする際に、できるだけ話すか「ナレーション」をしてもらい、彼らの思考プロセスをより深く理解できるようにします。

  • テストが始まったら、必ず会話をやめ、観察結果を詳細に記録してください。記憶だけに頼っていると、その瞬間には明確に見えることでも、簡単に曖昧になってしまいます。ユーザーは何に悩んでいますか? 意図どおりに使用されていない機能はありますか? 彼らは意味がないと思われることをやっているのでしょうか？

  • ユーザーがしばらく話すのをやめた場合は、室内モノローグを再度オンにするよう優しく伝えますが、それ以外の場合はマジックミラーの後ろにいるふりをします。

  • テスターのグループと会話する場合は、必ずテスター全員を含めてください。静かなテスターに​​意見を優しく促し、彼らの洞察が含まれていることを確認します。

セッション終了後

テスト セッションの直後に、次のことを行う必要があります。

  • セッションが記録されていることを確認してください (該当する場合)。

  • 追加のメモや観察があれば書き留めてください。

  • 他のチームメンバーと報告します (該当する場合)。

  • 対処すべき領域を強調した要約文書を作成します。

  • 収集したデータとフィードバックに基づいて、何を変更するか、変更しないかを決定します。

フィードバックを評価し、それに基づいて行動する

すべてのフィードバックを収集したら、それを評価し、どのように対応するかを考えます。メモとアンケートをよく読み、肯定的か否定的かにかかわらず、結果の概要を書き留めます。これは、次のようなステートメントの箇条書きリストである必要があります。

  • 「ユーザーはさまざまな種類のタワーがあることに気づきませんでした。」

  • 「ユーザーは、コンテキスト内メニューが理解しやすく、使いやすいと感じました。」

これを完了したら、改善が必要な各問題に対処するために実行できるアクションと、これらのアクションが持つ可能性のある依存関係を検討します。これは、特定された問題に対応するためのオプションを評価するのに役立ちます。

すべてのユーザー テスト結果に対してアクションを起こす必要はありませんが、ユーザーが何を言おうとしているのかに耳を傾けることは重要です。製品の重要な部分がうまく動作しない場合は、一部の機能を削除して、そこにあるものを修正することに集中する価値があります。

演習: ミニ製品評価

このチュートリアルを完了する前に、少し時間を取ってユーザー テスターの役割を果たしてください。自分の考えを記録して整理するには、開いた文書または紙切れが必要です。これをする：

1.特によく作られていると思う製品 (デジタルまたは物理的) を 1 つまたは 2 つ選択します。たとえば、特に優れたユーザー エクスペリエンスを備えたゲームやソフトウェア、またはスタイリッシュでありながら機能的なキッチン用品などです。

2. なぜその製品がそんなに好きなのかを考えてみましょう。次の質問を参考にしてください。

  • ユーザーのどのようなニーズに対応できるでしょうか?

  • ユーザーとしてのあなたにとって、このエクスペリエンスのどのような点がポジティブでしょうか?

  • 使った感じはどうですか？

  • 使い始めたときの学習曲線はどれくらい急でしたか?

  • 他の人にも勧めますか？正確に誰に勧めたいのか、そしてそうする理由を特定して、この回答を拡張してください。

3.これはとても気に入っている製品ですが、改善の余地がある部分を特定してください。次の質問を参考にしてください。

  • 関連するユーザーのニーズがあり、それが適切に対応できていませんか?

  • ニーズではなく、それが対処できない願望はありますか?

  • 使用体験を改善できる領域はありますか?

  • 製品を設計、製造した人たちに一言言えるとしたら何と言いますか?

4.製品について書いたフィードバックを評価してください。あなたが設計開発チームの一員である場合、これにより次のことを行うのに十分な情報が得られますか?

  • あなたの製品のユーザーエクスペリエンスのプラス面とマイナス面を明確に特定していますか?

  • ユーザーの問題点に対処できる可能性のあるアクションを特定し始めますか?

そうでない場合は、その情報を得るために追加の質問を特定してください。これは、取り組んでいる何かをユーザー テストする準備をするときに、質問の範囲を絞るのに役立ちます。

あなたの経験を共有してください

製品に対して与えられた評価の深さに驚きましたか? 一部のテスターのように、回答を深めるために多くの追加の質問を特定する必要がありましたか? 時間を割いて演習の簡単な感想を共有し、チュートリアルのコメントで他の人の洞察を探ってください。

まとめにかえて

このチュートリアルでは、ユーザー テストを設定するプロセスを、そのプロセスが抱える課題とそれがもたらす利点の両方を考慮して確認しました。

特にフィードバックが否定的な場合、ユーザー (テスターなど) の意見に真に耳を傾けるのは難しい場合があります。結局のところ、あなたはデジタル エクスペリエンスを作成するために熱心に取り組んでいます。そして、これがあなたが選んだ個人的なプロジェクトである場合は、おそらくあなたにとって明確で説得力のあるビジョンを持っているでしょう。

ただし、可能な限り最高のリアルタイム エクスペリエンスを作成するには、製品が自立できることが重要です。あなたが本当に気に入ったゲームのカットシーンにテスターが飽きてしまった場合、それは何らかの形でプレイヤー エクスペリエンスにとって機能していません。テスターがアプリのコントロールが複雑すぎると言ったら、それはあなたが作成した複雑なシステムを評価していないからではなく、ユーザーとしてのニーズを適切に満たしていないからです。

フィードバックとエクスペリエンスを批判的に評価し、ターゲット ユーザー向けに特定されたニーズに適切に対処するための変更を実装することで、エクスペリエンスの品質を向上させることができます。

次のポートフォリオ プロジェクトに向けて、クリエイター仲間と非公式のテスト セッションを計画して実行してみてはいかがでしょうか? 得られる洞察に驚くかもしれません。

この記事が気に入ったらサポートをしてみませんか？