testing - 廊下でのユーザビリティ テスト: UI のどの程度を実際に機能させていますか?

Question

廊下でのユーザビリティ テストを行うとき、ほとんどの人はアプリを完全に、またはほぼ完全に機能させますか? それとも、リンクまたはフローチェーンが正しいことを確認していますか? それとも、ただ紙に描いてそれを使いますか？

プロトタイプの早い段階でテストしたいと考えており、適切なバランスを見つけようとしています。しかし同時に、一部の非機能部品が実際には代表的な結果をもたらさないのではないかと心配しています.

ありがとう。

Answer 1

覚えておくべきいくつかのこと：

1. 早期に頻繁にテストします。
2. ユーザビリティ テストの目的は、コードの Q/A ではなく、 UIの問題を見つけることです。

したがって、テストしたい UI の部分をユーザーが見て、現実的な方法 (ボタンやリンクをクリックするなど) で操作できる場合、有用なデータを収集できるはずです。一部のリンクが行き止まりになっていても、ユーザーが回復して続行できる方法があれば問題ありません。基本的に、プロトタイプでは、「正しい」パスは機能するはずですが、間違ったパスが機能しなくても問題ありません (正しいパスに戻るかなり迅速な方法がある限り)。静的なストーリーボード (機能していない UI の描画) でさえ、適切な質問をすれば、いくつかの情報を提供できます。たとえば、「ショッピング カートを表示したい場合、この画面で何をしますか?」)。

Answer 2

ユーザビリティ テストは、廊下であろうとなかろうと、テストする必要がある機能のみを必要とします。ほとんどのユーザビリティ テストでは、特定の設計上の質問に答えて、それらの質問に答えられるようになるまでプロトタイプを開発する必要があります。たとえば、テーブルの並べ替え順序の指示をユーザーが理解しているかどうかをテストする必要がある場合、必要なのは、並べ替え指示を示すテーブルの紙の写真 (テーブルの内容がぼやけている) であり、テーブルがどのように並べ替えられているかを尋ねるだけです。 . IAをテストする必要がある場合、ナビゲーション メニューからリンクされた、タイトルを除いて空の一連の Web ページだけが必要です。

ユーザーに与えるタスクに関連するページのみが必要です。IA をテストするだけの場合は、標準パスのページのみが必要です。エラー回復もテストしている場合は、完全なナビゲーション コントロールとともに、標準的なパスから離れたページが必要です。エラー検出もテストしている場合は、ページにもコンテンツが必要です。

簡単に実行できる場合は、機能をシミュレートすることもできます。たとえば、ユーザーが目的の並べ替え順序を取得する方法を理解できるかどうかをテストする際に、ユーザーがテーブルを並べ替えるために機能していないコントロールをクリックしたときに、「わかりました。そうすれば、これが得られます」と言うことができます。マウスを使って、テーブルを新しいソート順で表示するブックマークを選択します。

廊下でのテストで、ユーザーが忠実度の限界を超えた場合、単純に「その部分はまだ作っていません。Aに戻って、そこから続けましょう。」もちろん、意図したタスクでユーザーが間違った方向に進んだことに注意する必要があります。未完成のプロトタイプであり、現時点では機能 x、y、および z の UI のみをテストしていると伝えたときに、ユーザーが機能しない機能について不満を言うことに問題はありませんでした。

忠実度の低いプロトタイプの場合、機能性が低いことを示すために、「プロトタイプ」ではなく、ユーザーに対して「モックアップ」または「図面」と呼ぶことがよくあります。不足しているコンテンツには、明らかなプレースホルダーを配置できます (例: 「何とか何とか何とか…」、「TODO: 製品の写真はこちら」)。ユーザーが忠実度の範囲外の何かについてコメントした場合 (例: 「このシンボルをもっと目立たせるために赤くする必要があります」)、単にそれをメモし、トピックが開発中であることを伝えます (例: 「ありがとうございます。私たちはまだ作業を開始していません。色はまだです。現在、サイトをどのように構成するかを考えているところです。」)

ほとんどのプロジェクトで反復設計を実行可能にするには、再現性の低いプロトタイプを使用したユーザビリティ テストが本当に必要です。そうしないと、やり直さなければならないものを開発するために、あまりにも多くの作業を無駄にしてしまいます。

Answer 3

ユーザビリティテストを数回行うことをお勧めします。最初は紙の上で、おそらく後で画面上で、通常はアプリケーションのライフサイクル全体を通して (アジャイルなアプローチを採用します)。

紙のプロトタイプについては、十分な議論があります。ユーザーが画面を見ると、機能が制限されていても、「完了」しているように見えるため、変更を提案するのをためらう場合があります。

間違いなく、すべてを紙に書き出すのは簡単ではありませんが、それが私が始めるところです。おそらく、アプリケーションの 1 つまたは 2 つのセクションから始めてください。そして、優れた対人スキルや説明スキルを持つ人がそこにいて、ユーザーに説明してもらうようにしてください。2 人目の人にメモを取ってもらいます。自由回答式の質問などをしてみてください。

Answer 4

廊下でのテストでは、機能を実装せずにテストします。

ホワイトボードまたは紙で作成された設計に対してテストします。これらの最小限のモックアップでどれだけ多くのことがわかるかに驚かれることでしょう。そして、それらは非常に安価に作成できます！

機能プロトタイプは後で使用します。ユーザビリティのサブジェクトに機能的なインターフェイスを提供すれば、最初から適切な機能セットを実装しているかどうかを疑問視する可能性ははるかに低くなります。

Answer 5

UIを機能させて、ユーザーが実際にUIを操作できるようにすると、静止画像よりもはるかに優れたものになります。人々は、UIを快適に感じるかどうかを教えてくれます。

Answer 6

UI のすべてが機能することを確認するか、少なくとも、機能がまだ実装されていないことを指摘する明確で明確なメッセージが表示されるようにします。

機能 X がまだ機能していないことについての免責事項を前もってクライアントに提示しても、通常は無視されます。彼らはプロトタイプを試し、機能 X をクリックし、「機能 X は機能しません!これは最終バージョンで機能する必要があります!なぜ機能しないのですか?」と憤慨して返信します。クライアントは製品について混乱し、不満を抱いており、肯定的なフィードバックを覆い隠してしまうため、自分自身を苛立たせています. それに、あなたは彼らにそれがうまくいかなかったと言ったのに、なぜ彼らは想像力を働かせて最終バージョンでどのように機能するかを想像できないのですか?

大まかなバージョン、ダミーデータ、または「現在アルファベット順にソートされた結果を表示する」という単純なメッセージでさえ、それを機能させます。