適切なタイミングでの貴重な洞察: ユーザー テストの設計忠実度の理想的なレベルを決定する

Intercom の製品開発の原則の 1 つは、大きく考え、小さく始め、すばやく学習することです。

私たちが素早く学ぶ方法の 1 つは、評価研究を実施して、私たちが追求している製品設計の方向性に自信を持たせることです。 コードが書かれるずっと前に、製品開発プロセスの非常に早い段階で製品のコンセプトをユーザーの前に出すことを目指していることがよくあります。

ユーザー テストに対するこのアプローチは、重要かつ進行中の質問を提起します。調査参加者に提示する適切な設計忠実度レベルはどれか? それらの概念をテストしている人々から正確な洞察を引き出すためには、それらの概念が最終的な設計にどれだけ近づく必要がありますか? 「粗野だが初期」と「洗練されているが遅い」の適切なバランスをどのように見つけますか? どのレベルの設計抽象化がスイート スポットに当たるか?

「参加者に何を見せるかについて社内で話すときは、 『デザイン』という用語を使用しない方がよいことがわかりました。私たちは『研究刺激』を使用することを好みます。」

言葉は重要

まず第一に、デザインの忠実度について話しますが、ユーザー テスト中に参加者に何を表示するかについて社内で話すときは、「デザイン」という用語を使用しない方がよいことがわかりました。「研究刺激」を使用することを好みます。 「研究の刺激」や「挑発的な人工物」などの用語は、少し奇妙に聞こえますが、参加者に見せるものは、特定のデザイン機能ではなく、全体的なコンセプトについての洞察を引き出すためのツールであることを伝えるのに役立ちます.

問題を特定する

研究刺激を作成するときに、入手可能な最新の最も洗練された設計ファイルを使用したくなるかもしれませんが、これには考慮しなければならない特定のコストが伴います。 参加者は、あなたが提供する最高レベルの忠実度に注意を払います。コンセプトに価値があるかどうかに関心がある場合、CTA のマイクロコピーに関する参加者のコメントを聞くと、探しているフィードバックにノイズが追加される可能性があります。

代わりに、私たちが学ぼうとしている問題から始めて、それをユーザーテスト中に調査参加者に示すものの忠実度と一致させることが役立つことがわかりました.

したがって、正しい設計の忠実度を判断するには、解決しようとしている次の問題を特定する必要があります。

• 概念のテスト: このアイデアには価値がありますか?
• システム設計のテスト: ユーザーはこのシステムを「十分に」理解できますか?
• ユーザビリティのテスト: 人々はこの製品を使用できますか?

解決しようとしている問題が決まれば、研究刺激に必要な設計忠実度のレベルを決定するのに役立ちます。

事前に問題を明確にすることは、デザイン、製品、およびエンジニアリングの分野を超えたパートナーと連携するのにも役立ちます。研究刺激の作成は共同作業であり、所有権が不明確になる可能性があるため、なおさら重要です。

「初期段階では、彼らがどのように反応するかには関心がありません。 あなたはそれが彼らにとって価値があるかどうかに興味があります。」

概念のテスト: このアイデアには価値がありますか?

この段階での問題は、「このアイデアには価値があるか」ということです。 具体的には、顧客はこのアイデアが苦労している問題の解決に役立つと思いますか? 初期段階では、彼らがそれとどのように相互作用するかに興味はありません。 あなたは、それが彼らにとって価値があるかどうかに興味があります。

テスト自体では、解決しようとしている問題を参加者が実際に経験していることを確認し、概念を示して、価値のある方法で問題を解決することを期待しているかどうかを評価します。

この時点では、テスト刺激はインターフェイスのように見える必要はありません。 実際、そうでない方がおそらく良いでしょう。概念をインターフェースとして提示することを選択した場合、参加者はそれとどのように相互作用するか、それが残りの部分とどのように関連するかについて考えることに飛びつく可能性があることに注意してください。あなたの製品、そして彼らがビジュアルデザインについてどう思うか。 この種のフィードバックは提供しやすいため、参加者は、コンセプト自体や、経験している問題にどのように対処できるかについて深く考えるのではなく、自然にフィードバックに引き寄せられます。 研究の刺激は、テストしているアイデアを伝えるだけでよく、それ以外はほとんどありません。

簡単なテキストの説明、ストーリーボード、ランディング ページのモックアップ、Google スライドの図、またはホワイトボード スタイルの落書きはすべて正当なオプションです。 不要なコピーをぼかし、わかりやすいプレースホルダー グラフィックを使用することで、シンプルで焦点を絞ったものにします。

システム設計のテスト: ユーザーはこのシステムを「十分に」理解できますか?

製品チームは、インターフェースやフローではなく、システム全体の構築に取り組んでいる場合があります。 この段階で調査を行うときの疑問は、おそらく、チームがこれまでに考えたことに基づいて、ブロックされたり混乱したりせずに製品を使用できるようにする機能的なメンタル モデルをユーザーが形成できるかどうかということです。 これの最良の証拠は、ユーザーがシステム内で代表的なタスクをどのように実行するかについて正確な予測を行えるかどうかです。

単純にシステムの抽象的な図を示して、ユーザーがシステムとどのようにやり取りすることを期待するかを尋ねることもできますが、これには生態学的妥当性はあまりありません。 ユーザーインターフェイスのように見える刺激を実際に示すことで、研究がより現実的に感じられます。 繰り返しになりますが、参加者に実際にプロトタイプを使用してもらうことで、参加者の注意をインタラクション デザインに向けさせないようにすることはほとんど不可能であることがわかりました。

現実的な問題を提示し、モックアップされたインターフェイスを使用してどのように対処することが期待されるかを説明するように依頼することを検討してください。その間、あなたは画面を共有し、製品を通じてユーザーを動かす特定のインタラクションを管理します。 これにより、デザインの方向性に自信を持つ前に完全にインタラクティブなプロトタイプを作成したり、まだジャンクだとわかっているインタラクションで参加者を苛立たせたりするリスクを回避できます。

ユーザビリティのテスト: 人々はこの製品を使用できますか?

この段階では、ユーザーが現実的なレベルのサポート (たとえば、最終製品で提供する可能性が高い以上のオンボーディングは行わない) で製品と対話し、問題を表すタスクを実行できるかどうかを知りたいと思うでしょう。解決しています。

ユーザビリティ テストにはさまざまな種類がありますが、そのすべてにおいてインタラクション デザインがより重要になります。 参加者に実行してテストしてもらいたいタスクが明確かつ具体的であり、それらを可能にするために必要な対話がプロトタイプでサポートされていれば、さまざまなレベルの忠実度のプロトタイプでユーザビリティをテストできます。

要約すれば

これらのフェーズ間の境界線は曖昧であり、状況に適したプロトコルに到達するのは難しい場合があります. セッションごとに調査の刺激と質問の両方を微調整する準備をしてください。

最後に、調査の刺激ではなく、調査セッション自体をどのように見つけたかを参加者に尋ねても問題はありません。 混乱や欲求不満は、やるべきことがまだあるというサインです。 行き詰まった場合は、問題から始めることを忘れないでください: ユーザー テスト セッションから正確に何を得ようとしているのか?

私たちのチームと一緒に働くことについてもっと知りたいですか？ 私たちの価値観、働き方、オープンな役割については、こちらをご覧ください。