ユーザー調査とユーザーテストの違いを関係者に説明するにはどうすればよいですか？
ユーザー調査を実施することをお勧めしましたが、クライアントは調査とテストを同じ概念であると考えています。研究とテストの違いをわかりやすく説明する方法がわかりません。
ここの誰かがこれについて私に助言してくれますか？
@sclarkeはすでにそれを置いているので、テストの前にresearchが行われます。食材が分からないと、料理はできません。 UXと同様に、テストの内容がわからない場合はテストを開始できません。
何をテストする必要があるかを知るには、対象者を知る必要があり、調査する必要がある対象者を知る必要があります。
ユーザーテストは、ユーザーを調査するための1つの方法にすぎません。
ユーザー調査には、インタビュー、観察、調査など、さまざまな方法が含まれます。ユーザビリティのスペシャリストの役割は、プロジェクトの利用可能なリソースとビジネス上の制限を考慮して、適切なユーザー調査方法を選択することです。
これが私の見解です。ユーザー調査はより広範な取り組みであり、ユーザビリティテストも含まれます。
ユーザー調査には、おそらくあなたが行う最も重要な作業も含まれます。何かを設計する前に、ユーザーとそのタスクについて知る必要があります。この情報を収集する最善の方法は、ユーザーをシャドウイングして、単にユーザーが何をしているかを観察することです。この知識は、あなたが行う設計上の決定を通知します。理想的には、構築するものを決定します。
（最近のプロジェクトの影を隠した後、私は彼らが使用するツールは完全に素晴らしいと結論しました。ユーザーは、各タスクで参照する印刷物のより良いレイアウトが必要でした。もちろん、ソフトウェア開発チームはそれを聞きたくありません。 ）
その他の回答では、適切な詳細な説明がいくつか提供されますが、素人の言葉で簡単な回答が必要な場合：
「夕食に何が欲しい？」と尋ねるユーザー調査です。
ユーザーが数秒間戻るかどうかを確認するのはユーザーテストです。
「それで、どうでしたか？」両方。
短い答え：同じではありません。
長い答え：ここでクライアントが何を懸念しているのか考えてみましょう。両者の違いがよくわからない場合は、彼自身が正式に研究やテストを行ったことはないと思います。ほとんどの人が非公式にそれを行いますが、間違っている確率とコストははるかに高くなります。
研究とテストは、設計サイクルの反対側に存在します。調査段階は、問題を定義し、この問題の影響を受ける人々についての視点を開発するのに役立ちます。何でこれが大切ですか？これは、発想が多様化するプロセスの基盤であり、アイデアが生成され、選択肢の量によって、エンドユーザーが満足する結果が得られる可能性が高くなります。研究は、その理想的な未来とそこに到達するために何が必要か（またはそこに行く価値があるかどうか）のより明確なビジョンを描くことです。
テストではプロトタイプに変わった単一のアイデアのパフォーマンスについてのみ知ることができますが、テストによって設計の欠陥が明らかになった場合、研究の基盤がないため、そこに戻って反復する場所がありません。
調査せずにテストを行い、製品またはサービスを繰り返し修正する場合、製品をテストしている人のフィードバックのみに基づいて、不明確な目標を持つ製品またはサービスを設計することになり、それがどの側面に影響を与えたかわからない成功または失敗。テスト結果だけを見るだけで、フレーミングバイアスを採用し、肯定的な結果をより強調して、潜在的なリスクを無視するのは簡単です。
適切な研究により、バイアスが存在することが明らかになり、これを設計によって克服する方法が提供されます。私たちは皆偏見があり、それが研究を必要とする理由です、私たちも完璧ではないので、テストする必要があります。また、予算も無限ではないので、失敗のリスクを減らすことについて賢くする必要があります。
編集：研究は設計プロセスのどの段階でも行うことができます。この場合、私はあなたが最初の発見段階で研究を持ち込もうとしていると想定しています。
私はそれを本当に短く、要点を付けたいと思います。
User ResearchはUser Testingの親です。つまり、テストプロセスも含みます。
User Researchは、観察手法、タスク分析、および他のフィードバック方法論。 Mike Kuniayskyはさらに、それは「聴衆に対するデザインの影響を理解するプロセス」であると述べています。 ここに参照
これには、初期設計または最初のプロトタイプの反復（相互作用の研究）から製品のライフサイクルが含まれ、次にbetaバージョン（Testing Research /ユーザーテスト）、最後に製品バージョン/アップデート（Usage Analytics）
ユーザーテストは調査です。
形成的研究あり情報を提供しますアイデア-フィールド調査、インタビュー、その他の発見の宿題、グーグル、フォーカスグループ、カードの並べ替えなど。-と総括的研究これは評価アイデアを、たとえばツリーテスト、ユーザーテスト、ヒューリスティック評価、エキスパートレビューなどで評価します。 。
本質的には、問題の定義を事前に行い、その定義に対して設計作業を実行して測定するたびに、UXデザインを調査してブックエンドを作成します。
私の意見では、それは必要なだけの専門用語です。研究はすでに、部門の懸念のように感じる定義やニュアンスがないと十分に困難です。
UXはまだ非常に若い分野であるため、多くの用語が適切に定義されておらず、互換性があります。
ただし、それらの使用方法から判断すると、簡単に言えば、ユーザーリサーチはユーザーが誰で何が欲しいかを見つけることであり、ユーザーテストはユーザーが製品と対話する方法を見つけることです。
クライアントを混乱させる可能性があるのは、変更を加えるのに最適な場所を見つけるためにユーザーが製品の現在のイテレーションとどのように対話するかを発見しようとしている場合、ユーザーテストがユーザーリサーチの一部を形成できることです。改善。
用語を明確にします。簡単に言えば、それぞれの設計プロセスでwhenを指定します。
次のように伝えます。「最初に、ユーザーの実際のニーズと行動が設計要件に確実に反映されるようにするために探索的ユーザー調査を行います。この事前調査には、実際のユーザーへのインタビューとコンテキスト内での行動の観察が含まれます。プロトタイプがあり、ユーザーがそれをテストして、期待どおりに機能するかどうかを確認します。これは評価ユーザー調査です。これには、ユーザビリティテストが含まれます。」
ユーザーの調査を説明するだけでなく、デザインプロセス全体で必要な理由について、単純で専門用語のないケースを作成することも不可欠です。幸運を！
概念的には、補完的であり、おそらく密接に関連しすぎて2つの異なるアクティビティーに分離できない2つのアクティビティーについて話しています。
各アクティビティに適用する実際のラベルに関係なく、基本的に行っていることは、ユーザーについて理解しようとすること（つまり、ほとんどの人が「ユーザー調査」と呼ぶもの）を理解することです。ユーザーは、製品やサービスを設計するときに、その動作についていくつかの仮定を行うことができます。
ただし、これらの仮定を検証して、ユーザーについて得られた知識を特定の方法で適用し、その有効性をテストする必要があります（つまり、ほとんどの人が「ユーザーテスト」と呼ぶものです）。ある程度のあいまいさがあるのは、仮定を検証するプロセスを通じて、ユーザーについての理解を深めることです。
ですから、それは意味論だと思いますが、研究を行うプロセスには、対象の観察、一般的な結論の引き出し、そしてそれらの仮定をテストして、それらが設計に引き継ぐのが賢明かどうかを確認することが含まれます。これは反復的で進化するプロセスであり、2つの異なるアクティビティに分離することは困難です。
ほとんどの人が混乱する理由がはっきりしているといいのですが。