時間に敏感なアクションにおけるユーザーの許容可能な待ち時間
ユーザーがアクションを実行した後、ユーザーが銀行または金融関連のWebサイトにいるときに許容できる待ち時間はありますか？重要なタスクについては、ユーザーがより辛抱強く準備できることを期待していますが、それが入札またはオークション関連のWebサイトである場合、トランザクションが即時であることを知りたいと思います。
ユーザーの行動に関連する一般的なWebサイトのパフォーマンスに関しては、おそらく「ゴールド」標準です http://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/
- 0.1秒は、システムが瞬時に反応していることをユーザーに感じさせるための制限です。つまり、結果を表示する以外に特別なフィードバックは必要ありません。
- 1.0秒は、ユーザーが遅延に気づいたとしても、ユーザーの思考の流れが中断されないようにするための制限についてです。通常、0.1秒を超え1.0秒未満の遅延の間は特別なフィードバックは必要ありませんが、ユーザーはデータを直接操作する感覚を失います。
- 10秒は、ユーザーの注意をダイアログに集中させるための制限とほぼ同じです。より長い遅延の場合、ユーザーはコンピューターが完了するのを待っている間に他のタスクを実行する必要があるため、コンピューターがいつ完了するかを示すフィードバックをユーザーに提供する必要があります。遅延中のフィードバックは、応答時間が非常に変動する可能性が高い場合に特に重要です。ユーザーは何を期待するかわからなくなるためです。
私が業界標準のベンチマークで見つけることができるクローゼットは、Compuware APMベンチマークです http://www.compuware.com/en_us/application-performance-management/Benchmarks/view-benchmarks.html
私が実際の数字に最も近いものは、ウェブサイトのパフォーマンスベンチマークを専門とするCompuwareから提供されたBest of the Web 2013アワードからのものです。注文トランザクションの生成を使用するブローカーカテゴリの勝者の平均応答時間（ホームページへのアクセス、ログイン、取引ページへの移動、株の選択、注文のプレビュー、注文のキャンセル、取引ページへの移動を含む）およびログアウト）は次のとおりです。
- 応答時間：3〜4秒
- 平均稼働率：99.9％
- 標準偏差：1.5〜2.2秒
これらはサーバー側からの数値であり、通常、実際のユーザーデバイスに到達するまでの応答時間（いわゆる「ラストマイル」）に約1〜2秒追加されます。したがって、基本的に、その業界で最もパフォーマンスが高いと見なされているWebサイト上のすべてのトランザクションは、10秒の障壁の範囲内ですが、理想的な1秒の応答時間よりも少し長くなっています。ただし、ユーザーの特定のアクションによっては、3秒の応答時間が許容範囲を超えます。
これらのタイプの応答時間の標準的な測定について、経験または知っている人はいますか？
[〜＃〜] update [〜＃〜]：Googleによって公開された Rails モデルは、ユーザーに別の標準セットを提供しますインタラクションの応答時間ですが、同様の原則とアイデアに基づいています。
Tbhはないと思います。それは常にコンテキストに依存し、ユーザーは一般的に一度にすべてを望みます。
このUXスタックの回答 は関連していますが、あなたの質問に完全には答えていません。これにはJ. Nielsenのガイドラインが含まれていますが、ユーザーコンテキストがないとどのように適用できるかわかりません。また、今では10秒近くも待っている忍耐力のある方。
かなりの量の回答は、何が起こっているかについてユーザーに良いフィードバックを与えることに関するものであり、それも私の答えでした。
単純なロードアニメーションは、短くて失敗する可能性が低いプロセスに適していますが、進行状況を実際に表すプログレスバーは、できればステータスをテキストで伝えて、長いプロセスに適しています（ユーザーはロードの経験が豊富です）ページがフリーズしているにもかかわらず回転し続けるスピナー）。
優れたシステム応答と巧妙なアニメーションは、知覚されるパフォーマンスを向上させる可能性がありますが、製品をできるだけ速くするよう常に努力する必要があります。数え切れないほどの記事がこの主題を扱っています。たとえば、 Googleからのこの黄金のオールディー です。
サイトが最高速度で実行されている場合、サイトのフローに適していれば、もちろん 再び遅くする のオプションがありますが、実際のパフォーマンスはそこにある必要があります。
Jeff Atwoodが Performance is a Feature と呼ばれる投稿でこれについてブログに投稿しました。
Stack OverflowとStack Exchangeでは、常にパフォーマンスに重点を置いています。私たちがパフォーマンスワンクである（有罪！）だけでなく、スピードが競争上の優位性であると考えているからです。 十分な実験データ があり、Webサイトの読み込みと表示が遅いほど、使用されるユーザーが少なくなることが証明されています。
[Googleが発見] 10件の結果を持つページの生成に0.4秒かかりました。結果が30のページには0.9秒かかりました。 0.5秒の遅延により、トラフィックが20％減少しました。 0.5秒の遅延により、ユーザーの満足度が低下しました。
A/Bテストでは、[Amazon]は100ミリ秒単位でページを遅延させてみましたが、非常にわずかな遅延でも、大幅なコストのかかる収益の減少につながることがわかりました。
そのリンクは別の投稿につながります：
たぶん私はせっかちです。ただし、それを高速にロードしない限り、提供する必要があるものを見つけるのに十分長い間誰も固執しないという理論を裏付ける具体的なデータはたくさんあります。たとえば、最近の調査によると、ほとんどの買い物客は、ページが読み込まれるまで4秒だけ待ってから、サイトを完全に放棄しています。
デアもこれを引用しました Greg Lindenによる投稿 これは、GoogleおよびAmazonからのページ読み込み時間に関するより定量的なデータを提供します。
GoogleのVPであるMarissa MayerがWeb 2.0カンファレンスで講演し、Googleがスピード、ユーザーエクスペリエンス、ユーザー満足度について学んだことを少しだけ提供しました。マリッサは、ユーザーが行ったユーザーテストについての話から始めました。彼らはGoogle検索グループに、何個の検索結果を見たかったのか尋ねました。ユーザーは、Googleが通常表示する10件以上の結果を求めました。彼らは言った。そこでマリッサは、Googleが検索結果の数を30に増やした実験を行いました。実験グループのGoogle検索ユーザーからのトラフィックと収益は20％減少しました。
痛い。どうして？なぜ、ユーザーがこれを要求したときに、ユーザーはそれを嫌っていたのでしょうか。
少し調べた後、マリッサは制御されていない変数を見つけたと説明しました。結果が10のページの生成には、0.4秒かかりました。結果が30のページは0.9秒かかりました。 1/2秒の遅延により、トラフィックが20％減少しました。 0.5秒の遅延により、ユーザーの満足度が低下しました。
この結論は意外かもしれません-人々は0.5秒の遅れに気づきましたか？ -しかし、Amazon.comでも同様の経験がありました。 A/Bテストでは、100ミリ秒単位でページを遅延させてみましたが、非常にわずかな遅延でも、大幅でコストのかかる収益の減少につながることがわかりました。
そのため、コンピュータユーザーは実際にせっかちであり、動作は時間に非常に敏感です。検索エンジンとバンキングサイトの主な違いは、バンキングサイトには視聴者が多いということです。ユーザーが余分な1秒の応答時間をかけて競合他社に逃げる可能性が低い場合でも、遅いWebサイトがより高速であることを望んで、ユーザーは密かに悪態をつきます。