すべてのテスターに同じタスクを与える
誰かに、1 つのレベルを完了するか、目標スコアに到達するか、またはコーチングなしで指定されたメカニックの 1 つを試してもらいます。どこで一時停止したか、何をクリックしたか、どの指示を 2 回読んだかを記録します。最初の試行中に遊び方を教えることは避けてください。説明では、改善が必要な正確な手がかりが隠れてしまう可能性があります。
短いフィードバック スクリプトを使用する
試した後、「それを押したとき、何を期待していましたか?」と尋ねてください。 「不明瞭なルールはどれですか?」そして「次は何を試しますか？」提案は観察とは別にしてください。さらに多くのレベルを要求する人がいますが、現在の最初のレベルがその目標を伝えているかどうかはわかりません。
フィードバックを小さな修正に変える
入力ミス、気づかないゴール、わかりにくい再スタートなど、特定の瞬間ごとにメモをグループ化します。最も頻繁に繰り返される摩擦ポイントを選択し、1 つの命令またはキューを修正して、新しいテスターに同じタスクを繰り返すように依頼します。最も発言力の高い参加者だけをチューニングしないでください。個々の観察を対象読者および設計目標と比較します。
共有バージョンは公開されているため、公開リンクを使用するように人々を招待し、共有しても問題のないフィードバックのみを残してください。ゲームのプロンプトにプライベートなプレイテストのメモや個人の参加者情報を含めないでください。リビジョン ログは、テストした人のラベル付けではなく、ゲームの動作に重点を置いてください。
視聴者と一緒にゲームをプレイテストするについての質問
テスターにどのような機能が必要かを尋ねるべきでしょうか?
後でアイデアを収集することもできますが、最初に、彼らが何を期待し、何が起こったのかを尋ねてください。動作と混乱により、ウィッシュリストの範囲が拡張される前に現在のループが機能するかどうかがわかります。
何人でテストすればよいですか?
明らかな混乱を特定するためにいくつかの個別のセッションから始めて、焦点を絞った改訂後に再度テストします。調査結果は、多数の聴衆から得られた普遍的な結果としてではなく、調査すべきシグナルとして扱います。
関連情報
古い情報を見つけましたか？ 訂正を連絡