免責事項：翻訳に不適切な箇所がございましたらご指摘ください。原文リンク：Response Times: The 3 Important Limits。ありがとうございます。
『Usability Engineering』第5章（1993年）より抜粋
応答時間に関する最も基本的な推奨事項は、この30年間（1968年～1991年）変わっていません：
0.1秒：ユーザーがシステムが瞬時に応答していると感じる限界。これは、結果の表示以外に特別なフィードバックを必要としないことを意味します。
1.0秒：ユーザーが思考の連続性を保てる限界。ユーザーは遅延を感じますが、通常、0.1秒から1.0秒の遅延に対して特別なフィードバックは必要ありません。ただし、ユーザーはデータを直接操作しているというスムーズな感覚を失います。
10秒：ユーザーの注意が対話に向けられる限界。これ以上遅延が長くなると、ユーザーは待っている間に別の作業をしたくなるため、タスクが完了した際にフィードバックで知らせる必要があります。応答時間が大幅に変動する可能性がある場合、ユーザーは何をすべきか分からなくなるため、遅延中のフィードバックは非常に重要です。
通常、応答時間はできるだけ速い方が良いですが、コンピュータの応答速度が速すぎてユーザーの反応が追いつかない状況が発生する可能性もあります。例えば、スクロールリストのスクロールが速すぎると、目的の要素が可視領域に現れたときにユーザーがそれを止めることができません。実際、コンピュータはUIの変化を非常に高速に表現できます。例えば、アニメーションはコンピュータの実行速度ではなく、実際の時間（クロックタイム）に基づいてタイミングが計られます。より高速なコンピュータが普及したとしても、UIはそのユーザビリティを維持すべきです。
コンピュータが瞬時に応答できない場合は、パーセンテージによる進捗インジケーター（Myers 1985）の形式でユーザーに継続的なフィードバックを提供すべきです。完了までに10秒以上かかる操作には、パーセンテージによる進捗インジケーターを使用すべきであるというのが黄金律です。進捗インジケーターには3つの大きな利点があります。1つ目は、システムがクラッシュしたのか、タスクを進行中なのかというユーザーの疑念を払拭すること。2つ目は、ユーザーが待つべき時間を適時に示し、長時間の待ち時間に別の作業を行えるようにすること。3つ目は、視覚的なフィードバック（ユーザーは少なくとも待機中のサインを見ることができる）を提供し、退屈な待ち時間を少しだけ快適にすることです。最後の利点は軽視できず、これが残り時間を数字で示す代わりにグラフィカルなプログレスバーの使用が推奨される理由です。
事前に所要時間が予測できない操作の場合、パーセンテージによる進捗インジケーターを使用することは不可能ですが、タスク完了までの絶対時間に基づいた実行進捗のフィードバックを提供することは可能な場合があります。例えば、システムが未知の数のリモートデータベースを検索し、各データベースの名前を出力する操作プロセスなどです。それも不可能な場合の最後の手段として、回転するボール、画面を飛び回る忙しいミツバチ、ステータスバーのドットなど、システムが動作していることを反映する、あまり具体的でない進捗インジケーターを使用します。何を処理しているか正確に表現できなくても構いません。この記事のWeb版への注記：多くのWebブラウザは、ページ全体のダウンロード完了のパーセンテージを表示しないため、有用なプログレスバーを提供できていません。
2秒から10秒程度のかなり高速な操作に対しては、パーセンテージによるインジケーターの使用は大げさに見えます。実際、プログレスバーの表示は表示の慣性（画面上で変化が速すぎるとユーザーが落ち着かなかったりストレスを感じたりする）の原則に違反します。あまり目立たない進捗フィードバックを提供することも可能です。一般的な解決策としては、「処理中」を示すカーソル形状と、画面下部の小さな領域で高速に変化する数字を組み合わせて、どれくらい完了したかを示す方法があります。
関連項目：
website response timesと応答時間を向上させる方法に関する記事
Webベースのアプリケーションの応答時間
2014年更新：またこのような質問を受けたので、ここで回答することにします。
Q: 「あなたは何度も応答時間が重要であると言及しており、応答時間を測定できるツールもたくさんあります。しかし、Webベースのアプリケーションにおいて、許容できる応答時間はどのくらいなのでしょうか？ショッピング体験は別として、インタラクティブなアプリケーションに限った場合、ユーザーの許容（上限）はどのくらいでしょうか？」
A: 「Webベースのアプリケーション」という言葉が完全に消え去ることを願っています。なぜなら、この言葉はアプリケーションUI設計（私たちはこのトピックに関する数日間のコースを提供しています）における実際の問題を混乱させるからです。C++やJavaScriptで実装されたアプリケーションに特化したガイドラインはありません。基本的なユーザビリティの推奨事項は実装に関係なく同じです。なぜなら、私たちが議論しているのはコーディングではなく、ユーザー体験だからです。
したがって、Webベースのアプリケーションの応答時間に関するガイドラインは、他のすべてのアプリケーションと同じです。これらのガイドラインは現在で46年の歴史があり、新しい技術の出現によって変化する可能性は低いです。
0.1秒：ユーザーがUI内のオブジェクトを直接操作していると感じる限界。例えば、ユーザーが表の列を選択してから、その列がハイライトされる、または選択されたというフィードバックがユーザーに返されるまでの時間間隔です。理想的には、これは列の並べ替えに対する応答時間でもあります。この場合、ユーザーは表を自分が並べ替えていると感じます。
1秒：ユーザーが過度に待たされることなく、コンピュータのコマンド空間で自由に操作していると感じる限界。0.2秒から1.0秒の遅延はユーザーに気づかれることを意味し、ユーザーの操作に直接応答するコマンドとは異なり、コンピュータがコマンドを「処理中」であると感じさせます。例えば、選択された列に基づいて表を並べ替える際、0.1秒以内に完了できない場合は1秒以内に完了しなければなりません。さもなければ、ユーザーはUIが遅いと感じ、タスク実行中の「フロー（スムーズさ）」の体験を失います。1秒を超える遅延の場合は、例えばカーソルの形状を変更するなどして、コンピュータが問題を処理していることをユーザーに知らせる必要があります。
10秒：ユーザーがタスクに集中できる限界。10秒を超える操作には、パーセンテージによる完了インジケーターと、ユーザーが操作を中断しやすく明確に識別できる方法が必要です。ユーザーが10秒以上の遅延に遭遇した後で元のUIに戻る状況を想定すると、彼らは再適応する必要があります。ユーザーの作業において、10秒を超える遅延は、タスクの切り替え時など、自然な中断の際にのみ許容されます。
コメントはまだありません