web-dev-qa-db-ja.com

ユーザビリティテストに関する正直なフィードバックを得る

私はチームで唯一のUX担当者である小さな会社で働いています。現在、既存のクライアントデータを新しい形式に変換することを含む、システムの重要なセクションでユーザビリティテストを実施しています。この変更を元に戻す方法はないので、テストを通じてできるだけ多くの問題を解決する必要があります。

デザイナーがテストを行う際の危険の1つは、ユーザーが実際に思っていることではなく、聞きたいと思っていることをユーザーが伝える可能性です。

以前は、ユーザーをリードすることを避け、「正しい」答えが1つないように複数のオプションを提供することを試みるために、自由回答形式の質問を言いました。私たちは今、単一のソリューションに取り掛かる最終段階にあります。だから私はもうそのアプローチを使うことができません。

私はあなたがうそをつくことができる本をいくつか読んだことがあり、あなたはテストを実行しているだけでプロジェクトに関与していないので、テスターは彼らの批判について率直に言うことができます。ユーザーが私が唯一のデザイナーであることをユーザーが知っているので、これは私の場合のオプションではありません。

テスターから正直なフィードバックを得るのに役立つ他のテクニックは何ですか?

1
nightning

2つの調査方法を組み合わせる

@ Kit-Groseが提供した理由により、ユーザビリティテストを開始します。 X-researchの方法に関するこのNN/gの投稿 の図をざっと見て、どの方法がユーザーのパフォーマンスを洞察できるか、どの方法が彼らの意見や評価を調査できるかを理解してください。

次に、ユーザビリティ調査セッションの後に、人々が自由に話せる方法でその調査を行います。 MicrosoftがUテストセッションの最後にこの方法を適用するのを見てきました。

  1. ランダムなオブジェクトとシンボルの線画のページングをタイルのように配置して、参加者に1ページ分見せます。 (適切な画像を収集するには、以下のヒントを参照してください。)

Present at least 40 choices

  1. 参加者に「あなたが行った活動に最も関連する3つの写真を特定してください」と依頼します。 3つの画像を選んだら、「それらの絵が最適な理由を説明してください」と尋ねます。

それが機能するのは…。線画の機能は、参加者が批判しているという事実から参加者の注意をそらすことですあなた。代わりに、彼らはtheirsの選択を正当化しています。これは非常に異なるアクティビティであり、感情的にはるかに簡単です。参加者が特定の画像が当てはまる理由を説明するとき、参加者は自分が感じたことや体験についてどう思っているかを説明します。彼らが3つの画像を選んだ理由を説明すると、参加者の発言に驚かれ、あなたの製品やそれを試した経験についてほのめかします。

もちろん、画像の実際の選択はあなたには関係ありません。あなたが注意したいのは、参加者が彼らについて言っていることです。

この方法では、研究セッションの終わり近くに、参加者の時間が2〜3分かかります。

適切な画像を選択するためのヒント

  • 画像検索からさまざまなサンプルを選択して、小さな画像の独自のページを作成できます 小さな線画の場合はこれ または 100の線画の場合はこれ
  • 詳細ではなく、単純なオブジェクトを選択します。時計、救急車、丸太、リス、手、本、電卓、スマートフォン、アップル、ドア、犬、定規、開いた箱、車などの画像を選択しますオン。
  • ハートなどの褒め言葉を狙っている画像は避けてください。
  • 画像が同じ (明度または暗度)であることを確認します。方法は次のとおりです。ページに目を細めて画像がぼやけると、ページ上の他の画像と比較して相対的に明るいまたは暗いため、どの画像も目立ちません。ハイコントラストを避けます。

Avoid very light or very dark values when compared to the other images

3
JeromeR

ユーザビリティテスト(正直かどうか)から明示的なフィードバックを得ることを実際に期待するべきではありません。それがフォーカスグループなどの目的です。

ユーザビリティテストは、意見ではなく結果をテストする方法です。これは、ユーザーが特定のタスクセットを実行する際に、変更に顕著な改善(または少なくとも同等の効果)があるかどうかを確認する優れた方法です。ユーザビリティテストの参加者からフィードバックを求めることは、実際に良い考えではありません。目の前のタスクを実行しながら、フィードバックを有機的に伝えたいと考えています。デザイナーとしての参加者の専門知識を求めるのではなく、参加者が実行しようとしているタスクに関するドメインの知識を求めます。

3
Kit Grose