応答時間を最小時間として平均時間に強制すると、UXが向上しますか？
私のAjax呼び出しの応答時間は14msから600msに変動する可能性があります。クエリが複雑になるためです。
私の経験から、ユーザーは20〜80ミリ秒の往復を当然のことと考えており、いつでもどこでも同じ速度を期待していますが、実際のところ、私の特定のプロジェクトでは不可能です。
そのため、結果を取得する前に、ユーザーに常に少なくともxの時間待機させることができるという考えを思いつきました。
質問は：すでに収集された応答の往復の長さに関する自分自身のデータの平均を使用する必要がありますか、それとも単にユーザーのアクションに対して公的に合意された最大許容応答時間を使用する必要がありますか？
私が覚えていることから、それは100〜200ミリ秒の間のどこかだったので、今は覚えられません。
ユーザーが待たなければならない時間を人為的に遅らせるべきではありません。それらを「平均」まで遅くして、迅速な対応を罰しないでください。すべてのクエリが自然に完了するようにします。クエリ時間を長くするには、次のことを検討してください。
ジェイコブニールソンは、1993年の待ち時間についていくつかの調査を行いました。「 応答時間：3つの重要な制限 から-
（1）0.1秒は、システムが瞬時に反応していることをユーザーに感じさせるための限界に近いため、結果を表示する以外に特別なフィードバックは必要ありません。
（2）1.0秒は、ユーザーが遅延に気づいたとしても、ユーザーの思考の流れが中断されないようにするための制限とほぼ同じです。通常、0.1秒を超え1.0秒未満の遅延の間は特別なフィードバックは必要ありませんが、ユーザーはデータを直接操作する感覚を失います。
（3）10秒は、ユーザーの注意を対話に集中させるための制限とほぼ同じです。より長い遅延の場合、ユーザーはコンピューターが完了するのを待っている間に他のタスクを実行する必要があるため、コンピューターがいつ完了するかを示すフィードバックをユーザーに提供する必要があります。
これらの数値は、予想される平均待機時間（100〜200ミリ秒）では、ユーザーが「瞬間的」と認識するためにユーザーに追加のフィードバックを要求する必要がないことを示しています。最大1.0秒の待ち時間があっても、ユーザーが「データを直接操作する感覚を失う」場合でも、通常は特別なフィードバックは必要ありません。
調査および上記の時間は、Webでのインタラクションとは関連付けられていないことに注意してください！これらの数値は、ユーザーエンゲージメントの生の待機時間を表しています。 「このデータはとても古く、ウェブはとても若かった」という罠に陥らないでください！上記は「ウェブ上」ではなく、タスクで「ユーザーが離脱するまでユーザーが待機する時間」が基本です。
どういう意味ですか？最悪の場合、数字をそのまま使用することを意味します（最近のWebユーザーは、より速く応答を期待しています）。せいぜい、ユーザーがウェブ上で少し余分なスペースを提供するため、少し余裕があります。
実際、Nielsonは「ウェブ上で何が起こっているのか」について質問を受け続け、2014年に回答をわずかに更新しました。
0.1秒：UIで直接操作オブジェクトであるとユーザーが感じる制限。たとえば、これは、ユーザーがテーブルの列を選択してから、その列が強調表示されるか、選択されていることをフィードバックするまでの制限です。理想的には、これは列をソートするための応答時間でもあります—その場合、ユーザーはテーブルをソートしていると感じます。 （彼らがコンピュータにソートを行うように命令していると感じているのとは対照的に。）
1秒：ユーザーがコンピュータを過度に待たなくても、自由にナビゲートコマンドスペースにいると感じるユーザーの制限。 0.2〜1.0秒の遅延は、ユーザーが遅延に気づき、コマンドがユーザーのアクションの直接の影響であるのではなく、コンピューターがコマンドで「機能している」と感じることを意味します。例：選択した列に従ってテーブルを並べ替えることが0.1秒でできない場合、それは確かに1秒で行う必要があります。そうしないと、ユーザーはUIが遅く感じられ、実行中の「フロー」の感覚を失います。彼らの仕事。遅延が1秒を超える場合は、カーソルの形状を変更するなどして、コンピューターが問題に取り組んでいることをユーザーに示します。
10秒：ユーザーがタスクに注意を向け続けるの制限。 10秒より遅いものには、ユーザーが操作を中断するための明確な標識付きの方法と同様に、パーセント完了インジケータが必要です。ユーザーが10秒以上の遅延後にUIに戻ったときに、ユーザーの方向を変える必要があると想定します。 10秒を超える遅延は、タスクの切り替え時など、ユーザーの作業の自然な中断中にのみ許容されます。
それでも、予想される平均値では、ユーザーはデータを「直接操作」していると感じたり、遅延に気づいたりしますが、「コンピューターがコマンドで「動作している」と感じるため」、必ずしも通知する必要はありません。クエリが1.0秒を引き継ぐ（または定期的にそれに近い）場合のみ、通知が必要になります。
しかし、それだけですべてではないかもしれません。 NYTimesの記事「 せっかちなWebユーザーの場合、まばたきは待つには長すぎる 」は、「サービスのような場合にユーザーがページを待機する時間について、GoogleとMicrosoftが行っている作業について説明しました。 " 利用可能です。
記事から：
近い競合他社よりも250ミリ秒（ミリ秒は1000分の1秒）遅い場合、人々はWebサイトにアクセスする頻度が低くなります。
これは通知を含めるかどうかを指示するものではありませんが、ユーザーにとっての応答時間の重要性を示しています。待ち時間を作為的に膨らませると、ユーザーを競合他社に引きずり込む可能性があります。
30年以上前、私はsystems programmer、と呼んでいたときに、数十人のユーザーがいるミニコンピュータネットワークの世話をしていました。当時、ディスプレイは本質的に80x25の「テキストのみ」でした。
ミニコンピューターとディスプレイの間の通信リンクをアップグレードすると、サーバー側で何も変更されておらず、リンク自体が実際に何度もあったにもかかわらず、システムがslowerであると不平を言うユーザーが何人か速い。また、システムの負荷が低いときには、元の通信リンクが主なボトルネックになることがよくありました。
より高速なリンクが原因で、表示データの各「パケット」（512バイト、2K未満）が到着し、次のパケットが到着するかなり前に表示されていました。総スループットは実際には高速でしたが、これらの目に見える一時停止は、ユーザーにそれが遅い印象を与えました。短期的には、サーバーエンドにメモリを追加できるまで（当時は非常に高価）、リンクパケットサイズを大きくできるようになるまで、不平を言ったすべてのユーザーに対して元の低速の通信リンク速度を再構成しました。
これが正確に OPの状況を反映していないことはわかっていますが、ユーザーの「応答性」の認識は常に「相対的」であるというのは、一般原則の一部だと思います。ユーザーは、一定の速度で一杯になると6秒かかる画面を表示することを気にしませんでしたが、1秒間隔で4つの「チャンク」が瞬時に表示されるのを見たくありませんでした。
同様に、someクエリが「インスタント」応答を生成する場合、ユーザーはall他のクエリを「遅い」と分類する可能性が高くなります、それはaverageではなく、-fastestと比較するためです。ほとんどのユーザーは、どのクエリを実行するかについてあまり考えていないことを想定していることに注意してくださいexpect高速または低速（そうした場合、状況が変わる可能性があります）。
私は受け入れられた答えが好きで、人為的に何かを遅らせるべきではないことに同意します。
ただし、予想される待機時間を考慮して、知覚されるパフォーマンスを改善するためにできることは行います。たとえば、結果の読み込み中にスピナーを表示すると役立ちます。しかし この調査 によると、スピナーを表示する前に0.4秒待つことが最適です。
時々使用したい別のテクニックがあります。リンクまたはボタンをクリックすると、最終的に新しいページまたはインターフェースが表示される場合は、データをバックグラウンドでロードしている間に、すぐにユーザーをそのページに移動します。そうすれば、ユーザーは何かがすぐに発生するのを目にし、データは0.5秒後に新しいインターフェイスに表示されます。
一般に、即座に視覚的なフィードバックを作成できるときはいつでも、速度と応答性の認識を改善するのに役立ちます。
少なくとも特定の種類のアプリケーション（正確にはリアルタイム戦略ゲーム）の場合、ユーザーは予測不能に変化する応答よりも遅いが一貫性のある応答時間が望ましいと感じる可能性があることを示唆するいくつかの研究が存在します。
具体的には、記事から引用させていただきます "2500の1500 Archers：Age of Empires and Beyond"のネットワークプログラミング " Mark TerranoおよびPaul Bettner（emphasis私のもの）：
「RTSゲームの場合、250ミリ秒のコマンドレイテンシは気付かれませんでした。250から500ミリ秒は非常にプレイ可能で、500を超えると顕著になり始めました。プレイヤーが「ゲームペース」とクリックしたときとユニットが応答したときの間のラグの精神的な期待一貫した遅い応答は、高速と低速のコマンドレイテンシを交互に切り替えるよりも優れています（たとえば80および500ミリ秒）-その場合、一貫した500ミリ秒のコマンドレイテンシは再生可能でしたが、変化するものは「ぎくしゃく」と見なされ、使用するのが困難でした。
実際のところ、これはプログラミングの労力の多くをスムーズに導きました。時折スローダウンしてできるだけ速く実行するよりも、ターンの長さを長くしてすべてがスムーズで一貫性を保つようにした方がいいでしょう。速度の変更は、徐々に、可能な限り小さな増分で行わなければなりませんでした。」
この効果は特にゲームで顕著になる可能性がありますが、他のアプリケーションでも同様の効果が発生しないと想定する理由はありません。確かに、それは FumbleFingersのミニコンピュータの逸話 とよく一致しているようであり、ここでプレイすることでより一般的な効果があることを示唆しています。
遅延を追加することが有益である1つのケースは、ユーザーが何かが変更されたことに気付かない場合です。以前にサイトで実装しました-クエリ結果はすでに準備できていますが、遅延なく変更すると、ユーザーはおそらく変更が発生したことに気付かないでしょう。そのため、短い「読み込み」アニメーションで偽の遅延を追加します。
この場合の遅延は非常に小さいはずですが、ユーザーの脳が「何かが変わっている！」と考えるだけで十分であり、その実現の終わりまでにコンテンツが変更されました。
受け入れられた回答に完全に同意し、すでに遅れていますが、「実際の待機時間」（つまり、エンジニアリングの問題）ではなく、「認識された待機時間」（つまり、動作の問題）に焦点を当てて、別の視点を提供したいと思います）。
このシグナルとノイズの記事 は、待機時間の認識を管理する古典的な例を引用しました。エレベーターにミラーを追加するだけで、エレベーターの速度に関する人々からの膨大な苦情が完全に取り除かれました。鏡があることで、待っている人たちがお互いまたは自分自身を見ることができ、そのため、待っていることに関連する退屈さが軽減されました。
Steven Seowの本 設計とエンジニアリングの時間：ソフトウェアにおける時間知覚の心理学 は、待機の心理学と、ユーザーの待機の知覚を管理する方法について、非常に興味深い洞察を数多く提供しました。
この新しく公開された記事 は、これらの洞察のいくつかを引用しています。特に、あなたの質問に最も関連するのは：
ルール1：スープが沸騰するのをユーザーに見させないでください：ユーザーが待つ場所を探し、その時間を意味のあるもので満たそうとします。
ルール3：プロセス全体の透明性を提供します：ナンバリングシステムまたはシステムを使用して、彼らがどこにいるのかを知らせることにより、待機時間がどのくらいかを確実に知らせますプロセス。
- ルール4：達成または達成できる目標を設定します：期待を下回って過剰に配信し、期待値を下げてからそれらを超えます。レストランは待ち時間を少し過大評価することで有名です。彼らはこれを行うので、彼らは彼らが彼らの見積もりを満たしているか、おそらくそれを打つことさえできると確信しています。
- ルール5：プロセスの開始と終了を慎重に設計します：ユーザーが製品、サービス、またはインターフェースに遭遇したときにユーザーが目にするものや体験するものを評価します初めて、どのように経験が彼らのために終わるのか。イベントの記憶は、イベントの開始と終了によって大きく形成されます。
それで、あなたの質問に直接答えることで：UXを改善するために応答時間を平均時間に強制しますか？、私はノーだと思います。強制してもUXは改善されません。
ただし、ルール4を適用すると、ユーザーに過剰に見積もられた数を与えて、その前に結果を配信することができます。それを他のルールと組み合わせると、ユーザーは待つことについても気分が良くなります。:)