ユーザーは待機ダイアログでどのくらい辛抱していますか？
平均的なユーザーが、何かがおかしいと思う前に、待機インジケーター（つまり、回転する円、死の浜辺のボール、卵のタイマー）で待機する時間の長さはどれくらいですか？
誰かが調査をポイントして回答をバックアップできるとしたら、それはボーナスになります。
私は、ユーザーがアプリケーションがインストールするのを待つか、Windowsがデスクトップから起動するのを待つのではなく、ユーザーが長い間かかる可能性があるアクションを待つのではなく、主にWebサイトのコンテキストまたはデスクトップアプリケーション内で考えています。
UX-guruのJakob Nielsenに聞くと、10秒です。待機時間が長くなると、ユーザーはプログラム/ページを離れ、その間に他のことを行う可能性があります。何かがうまくいかなかったと仮定することは、特定のタスクが実行する可能性のある時間とタスク自体の種類に対するユーザーの期待にも依存します。
オリジナル（1993）： http://www.nngroup.com/articles/response-times-3-important-limits/
http://www.nngroup.com/articles/website-response-times/ からの改訂版（2010）
3つの応答時間制限は、1993年に私が書いたときと同じです（ヒューマンファクターのパイオニアによる40年の研究に基づく）。
- 0.1秒は、瞬時の応答の感覚を与えます—つまり、結果は、コンピュータではなく、ユーザーによって引き起こされたように感じます。このレベルの応答性は、直接操作の感覚をサポートするために不可欠です（直接操作は、ユーザーエンゲージメントとコントロールを向上させるための主要なGUIテクニックの1つです。詳細については、実世界問題のヒューマンコンピューターインタラクション（HCI）セミナーを参照してください）。
- 1秒は、ユーザーの思考の流れをシームレスに保ちます。ユーザーは遅延を感じることができるため、コンピューターが
結果、彼らはまだ全体的な体験をコントロールしていると感じ、コンピュータを待つのではなく自由に動いていると感じています。この
適切なナビゲーションには応答性の程度が必要です。 10秒
ユーザーの注意を維持します。 1〜10秒の間に、ユーザーは間違いなくコンピューターのなすがままに感じ、それがより高速であることを望みますが、
扱う。- 10秒後、彼らは他のことについて考え始め、コンピュータがいったん脳を軌道に戻すのを難しくします
最終的に応答します。多くの場合、10秒の遅延により、ユーザーはすぐにサイトを離れます。そして、たとえ彼らが留まっても、彼らが何が起こっているのかを理解することは難しく、困難なタスクで成功する可能性が低くなります。数秒の遅延でさえ、不愉快なユーザー体験を生み出すのに十分です。ユーザーはもはや制御できず、コンピューターを待つ必要があることで意識的に苛立っています。このように、短い遅延が繰り返されると、ユーザーはタスクの完了に非常に傾倒しない限りあきらめます。
時間がかかることが予想される場合は、回転する円だけでなく、進行状況インジケーターを追加できます。進行状況インジケーターはユーザーの観点からはほぼ完璧であり、弱点が1つだけあります-データ処理ではなく、待機に費やされた時間を反映する必要がありますが、プログラミングの観点から見ると、プロセスが取ると言うにはあまりにも多くの依存関係があります。たとえば、一般的には10秒です。結果として、ユーザーは最初の3秒間で進行状況が0〜40％になるのを見ることができ、40〜70％になると30秒かかります。またはさらに悪いことに、ユーザーには0から100％までの進行状況インジケーターが表示され、その後、回転する円を見ることができます。 100％になると、彼または彼女は本当に何かがおかしいと感じるでしょう。
プロセスにかかる時間（時間で測定）が0〜100％からいくつかの相対データに切り替わる必要があるかどうかを判断できない状況では、良い進捗インジケーターであると考えています。何かがバックグラウンドで機能していることをユーザーに通知するだけです（この場合のみ）。ユーザーはそれがどれだけの時間かかるかはわかりませんが、少なくとも彼または彼女はバックグラウンドプロセスが機能していることを知っています。
したがって、2つのことを行う必要があります。適切な待機インジケーターと適切な進行状況インジケーターです。
ここに簡単な視覚化があります：
私は人が待っているものに大きく依存します。
どこで読んだか思い出せませんが、航空会社のフライト予約では、短い待ち時間の方が長い待ち時間よりも応答が悪いことがわかりました。それが長かった場合（そして、偽のアクティビティが見られた場合）、アルゴリズムと結果に対する顧客の信頼が高まりました。同じことが、保険の見積もりや、より複雑であると認識されている同様のアクションにも当てはまります。
全体的なルールは顧客が直面するアクションを可能な限り速くするです。より遅くする必要がある場合は、重要な何かが発生していることを伝えるために、いくつかの進行状況バー（作成するトリックの方が速いように見える）または情報（ダミー情報であっても）を表示する必要があります。
待機時間は、知覚されるパフォーマンスと密接に関連しています。 Steve Seowは Designing and Engineering Time：The Psychology of Time Perception in Software というタイトルの優れた本を持っています。
その主な結果の1つは、応答時間の認識です。
- 「瞬時」（0.1〜0.2秒）
- 「即時」（0.5 – 1秒）
- 「長い」（2〜5秒以上）
彼らが待つ用意がある時間は、彼らがタスクの複雑さであると彼らが考えることを含むいくつかの要因に依存します。ユーザーがタスクを複雑に感じる程度と、何かがうまくいっていないと心配する前にタスクを待つ時間との間には関係があります。
タスクの完了にかかる時間に対するユーザーの懸念に対処するための最良の方法の1つは、可能な限り、確定的な進行状況インジケーターを使用することです。このようにして、ユーザーはどれだけの量が完了し、どれだけ残っているかを示すことができます。不確定な進行状況インジケーター（これまでに経験したことのあるすべての人が確信しているように、タスクが決して完了しないことを示すことができます）ではなく、進行状況を確認できるため、ユーザーはシステムと信頼の構築に役立ちます。
Javaアプレットがロードされるのを24時間以上待ちました。最初の数秒後にマルチタスクを開始しました。約10秒後にページをリロードしました。10秒後にブラウザをスローしましたJavaアプレット全般にかなりがっかりしました。しかし、アプレットまたはそのサーバーが多くの作業を行っていたのではないかと思いました。翌日、6つのデスクトップに散在していた一連のウィンドウをクリーンアップしていたところ、Javaロゴがまだ回転していることに気付きました。
私の要点は、意味のあるフィードバックがない場合にユーザーに待機する時間を上限に設定する必要があるということです。これは、非常に悪い印象を与えるのに十分な時間待機するためです。ブラウザーにJavaをインストールする手間を省きました。
それは期待される待ち時間についてではなく、合理的な期待を設定し、常にそれらを満たすか超えることについてです。まず最初に正しいターゲットを設定し、その後は常に予定どおりに作業を進めるか、計画どおりに作業が進まない場合は適切に元に戻すことが非常に困難です。ユーザーは、合理的な範囲内で、希望どおりの忍耐力を発揮します。一般的なブラウザがデータを取得するために待機するのをブロックするための3分間は良いユーザーエクスペリエンスではなく、その前にウィンドウを閉じます。ノンブロッキングajaxから始めて、リソースを取得したり、データをコミットしたり、SQLなどの適切なロジックを使用して、効率的かつ最も重要な多くの防御的プログラミングを行います。ほとんどの中途半端なこっけいなプログラマーはコードに自信を持っています。それは、それがあまりに多くのエラー処理をほとんど必要としないほど良いと仮定しているからです。時間/パフォーマンスの期待値を設定する前に、無意識のうちにユーザーを失うことがないようにしてください。
Webサイトから何かを取得しようとするユーザーは、サイトに忍耐力ユニット、クォータの数を割り当てます。
ユニット数は、サイトの予想される結果、またはその結果に対するユーザーの関心に依存します。
ユーザーが強制的にWebインターフェースを介して税金を課している場合など、場合によっては割り当てが無限になることがあります。
サイトが価値を提供すると、ユーザーはより多くのユニットを割り当てる可能性があります。一方、サイトがユーザーの期待に遅れている場合、サイト（サイト）は忍耐力ユニットを消費し始めます。
ユニットの残りの数がゼロに達すると、ユーザーは去ります。
すべての進行状況インジケーターと催眠回転アニメーションは、ユーザーが現在のセッションから忍耐力ユニットを引き出すことを控えようとする試みです。
したがって、ユーザーが離れるまでの一定の時間はありません。
ユーザーを維持するために、ユーザーに大きな価値を提供します。または、より速い応答時間。
正直に自信を築くような、もう1つの側面があります。 @Dominikの視覚化は、一部のコールセンターからの偽のstay in lineメッセージとは対照的に、ユーザーが待機する必要がある時間についてユーザーに誠実に伝達するという点で、良い例です。
ユーザーが待っているものの価値と、多かれ少なかれ待機にかかる時間を知っている場合、ユーザーはニールセンが何と言っても情報に基づいた決定を下すことができます。
Webサイトはそれらに影響を与えようとするべきではありません。多分物乞いは正しいでしょう：行かないでください！。