ユーザーテストがインターフェイスと製品全体の設計に大いに役立つことは明らかですが、何かをテストするには、完成した製品または少なくともプロトタイプが必要です。
プロトタイプを作成すると、テストのコストは大幅に削減されますが、かなりの労力と時間が必要になります。 また、プロトタイプを作成する前に、30分以上費やすことなく、テストするのに適したインターフェイスコンセプトのオプションがしばしばあります。 この場合、いわゆる「廊下テスト」は設計者を支援できます。 ハブでは、このトピックにあまり注意が払われていなかったため、私の経験からいくつかのトリックを共有することにしました。
回廊テストの意味は何ですか
紙またはお気に入りのプログラムでレイアウトを描き、オフィスを出て、オフィスの同僚に近づき、印刷形式で、またはラップトップ/タブレットでレイアウトを見せます。 レイアウトを使用してシナリオ全体をテストできる場合は、それらをいくつかのinvisionapp.comにリンクして、インタラクティブなプロトタイプを取得してください。
廊下テストが呼び出されるのは、通過する人からの文字通り廊下で、レイアウトに関するフィードバックをすばやく受け取ることができるためです。
廊下テストの実施方法
レイアウトを作成すると、どのシナリオで使用されているかが明らかに理解できます。そのため、プロトタイプを人に見せることで、少なくとも3種類の質問をすることができます。
- どこでクリックして何かを見つけますか
- このリンクまたはボタンをクリックするとどうなると思いますか
- このフレーズ/名前をどのように理解していますか？
どこでクリックして何かを見つけますか
この質問は、インターフェイスからのユーザーの期待をテストするときに尋ねられます。 ユーザーには、おそらく製品で完了する必要があるタスクがあります。 この質問のおかげで、ユーザーが目的の機能や情報を見つけられるかどうかをすぐに把握できます。
このリンクをクリックするとどうなりますか？
2番目の質問は、期待値をテストすることです。 これを使用すると、情報アーキテクチャだけでなく、情報の整理やリンクの名前付けだけでなく、システムの動作に対する期待もテストできます。 たとえば、ユーザーは「購入」ボタンをクリックしたときにチェックアウトに進むことを期待していて、製品がバスケットに入っていることを通知するポップアップウィンドウを設計したと答えることができます。
このフレーズ/タイトルをどのように理解しますか
3番目の質問は、インタラクティブなインターフェースだけでなく、 ボタンとリンク。 レイアウト上の情報がどれだけ明確かを理解するのに役立ちます。 質問は再定式化できます：「このフレーズ/グラフ/画像でユーザーに何を見せたいと思いますか？」
答えはあなたを非常に驚かせるかもしれません、そして、あなたは最初に定められた考えが完全に異なる方法で人々によって理解されることを認識するでしょう。
5秒のテスト
小さな追加は、5秒間のレイアウトテストです。 5秒間レイアウトを表示し、それを削除して、レイアウトで見たものや覚えているものを尋ねます。
おそらく、これはインターフェースをテストする場合の最良の手法ではありませんが、販促資料、ランディングページ、バナーをテストする場合はうまく機能します。 たとえば、5秒後に「レイアウト上のバナーは何ですか？」と尋ねることで、ポータル上のバナースポットまたはバナー自体のコンテンツの有効性をテストできます。
ちなみに、上記の質問はすべて、古典的なユーザビリティテスト中に尋ねることができます。
ラップトップまたは紙
廊下の人々にラップトップやタブレットを使ってアプローチしたり、紙に印刷されたモックアップでアプローチしたりできます。 一方で、レイアウトはユーザーが画面上で見るのにより馴染みがあり、他方では、紙のレイアウトでは、テスト担当者は何かを描くか、自分のビジョンを描くことができます。 私の選択は両方です。 可能であれば、タブレットを用意しますが、印刷版を用意してください。もちろん、鉛筆を持参することも忘れないでください。
廊下テストの長所と短所
廊下のテストは、スケッチに関する迅速なフィードバックを得て先に進むのに役立ちます。 一方、そのようなフィードバックはあまり代表的ではない場合があります。
- 実際のユーザーではなく、私の目を引いたユーザーに尋ねた
- 人々は通常コンピューターを使用する状況ではありませんでした
- 人々は問題に突入する十分な時間を持っていませんでした。
ただし、廊下のテストは、大規模なシナリオをテストするためのものではなく、完全なユーザビリティテストの実施をキャンセルするものでもありません。
すべての不利な点はありますが、この手法を使用することをお勧めします。 製品を完璧にするのには役立ちませんが、エラーを修正するコストがまだ非常に低い場合、考えられる設計上の問題について考えるようになります。