待ち時間表示に関する行動研究
私はクライアントに訴訟を起こすつもりであり、私の主張の証拠を探しています。彼らのシステムがロードまたは「ウォーミングアップ」しているときは、カウントダウンタイマーを表示するよりも、完了までのカウントアップとして待機時間をパーセンテージと進行状況バーを使用して表示する方がよいと提案しました。システムは非常に基本的なGUIであり、起動時間は1分です。
私の直感は、パーセンテージと進行状況バーを表示することはユーザーにとってより肯定的であり、システムが完全に実行されると報酬として機能することを教えてくれます。私の理論的根拠を裏付けるためにこれを説明する特定の行動研究用語または概念はありますか？
Nielsen Norman Groupの待ち時間に関する興味深い研究。
0.1秒は、システムが瞬時に反応しているとユーザーに感じさせるための限界に近いため、結果を表示する以外に特別なフィードバックは必要ありません。
1.0秒は、ユーザーが遅延に気づいたとしても、ユーザーの思考の流れが中断されないようにするための制限とほぼ同じです。通常、0.1秒を超え1.0秒未満の遅延の間は特別なフィードバックは必要ありませんが、ユーザーはデータを直接操作する感覚を失います。
10秒は、ユーザーの注意をダイアログに集中させるための制限とほぼ同じです。より長い遅延の場合、ユーザーはコンピューターが完了するのを待っている間に他のタスクを実行する必要があるため、コンピューターがいつ完了するかを示すフィードバックをユーザーに提供する必要があります。遅延中のフィードバックは、応答時間が非常に変動する可能性が高い場合に特に重要です。ユーザーは何を期待するかわからなくなるためです。
あなたのケースでは特にロード時間が長いようです。
待機時間が長い場合：
ウェブサイトに関する調査によると、DMVの電話回線での保留中の音楽や付随するメッセージと同様に、グラフィックの進行状況インジケーターが待機の悪影響を軽減し、ユーザーのウェブサイトへの注意を引き付けます。
コンピューターがすぐに対応できない場合は、継続的なフィードバックをパーセント完了インジケーターの形式でユーザーに提供する必要があります[Myers 1985]。経験則として、パーセント完了進捗インジケータは、約10秒以上かかる操作に使用する必要があります。
カウントダウンタイマーのみの問題の1つは次のとおりです。
- アプリの読み込みのパフォーマンスをテストした場合でも、ユーザー接続を制御することはできません。
- 接続またはパフォーマンスの問題が原因でタイマーが間違っている場合、これで、ユーザーにシステムの整合性を疑わせることができます。彼らはそのシステムを信じないでしょう。
アプリのインストールについては調査していませんが（誰かが投稿した場合は投稿してください）、タイマーのみが表示されるアプリのインストールは確認していません。通常、アプリのインストール（およびダウンロード）
アプリのインストールをモデリングして、ベストプラクティスをダウンロードしてください
Macのダウンロードのように、パーセンテージバーと推定値の組み合わせ、またはchromeが視覚的なインジケーター、転送量、および推定値（およびパーセンテージ）をどのように表示するかを試すことができます。
注：ダウンロードとの違いは、ユーザーが引き続き閲覧/作業できることですが、アプリのインストールはアプリが完全に利用できないことを意味します。このモデルは、表示されるさまざまな属性に使用します。 :)
私の最初の感じは、カウントダウンタイマーは、ユーザーが待機時間を経過するまでの経過時間ではなく、待機時間にすぐに集中できるようにすることです。カウントダウンは常に、カウントダウンしている時間のように感じられます。プログレスバーは少し時間を減らしたような気分にさせることができます。
私の質問は、その分の読み込み中にユーザーに何らかの価値をもたらすことができるかどうかに焦点を当てます。プログレスバーが前進するにつれて、一種のスライドショーに変えることができる製品の使用に関するヒントはありますか？ユーザーが製品で行っている作業に関連する興味深い引用はありますか？最終的にユーザーが製品に入るまで常に1分間待機するように求められている場合、ユーザーはその時間を他のことに使用し始めます。しかし、その分をやや豊かにし、待ち時間に煩わされることを少なくする方法があるかもしれません。
これは私がこれのいくつかについて出くわした興味深い記事です。 https://medium.com/swlh/the-illusion-of-time-8f321fa2f191
あなたのアプローチはあなたの特定のケースに適しています。読み込みに比較的長い時間がかかるアプリの場合、割合を表示する必要があります。残り時間を表示することは非常に不確かです。彼らが言うそれらの恐ろしいダイアログボックスを見てください：time left: 1 min。その後45秒後：Time left: 15 minutes。その後しばらくして：Time left: 5 seconds.それから数分後：time left: 2 days.。これは誇張ではありません。これは、ダウンロードで、または何かをインストールしていて問題が発生しているときによくあることです。
したがって、あなたが扱っているのはユーザーの期待という名前です：
ユーザーの期待は、製品、サービス、またはデジタル資産に関する期待として定義できます。ユーザーがアプリ、Webサイト、またはソフトウェアを使用するとき、製品自体とそれに関連する使用法について異なる期待があり、ダイアログのデザイン、ユーザーガイダンス、および目標の達成に反映されます。ユーザーの期待は大きく異なります。これには、ボタンのクリック、情報の必要性、またはモバイルデバイスでもアクセスできる美的に一貫したデザインが含まれます。
そして、あなたの特定のケースは、Nick Babichによるこの素晴らしい記事で説明されています：モバイルUXデザインの進行状況インジケーター（それはしませんモバイルのみに適用！）
ユーザーの期待=デフォルトの読み込みアイコン（中央の点から放射状に伸びる灰色の線のiOSスピナーなど）は、否定的な意味合いを持つ傾向があります。これらは、デバイスの起動からネットワークへの接続またはデータのロードの問題まで、すべてのステータスを示す、さまざまなオペレーティングシステム機能を提供します。そのため、進行状況や時間を示さないローディングスピナーだけを見るのは嫌です。
その後...
パーセント完了アニメーション
不確実な待機は、既知の有限待機よりも長くなります。パーセント完了進捗インジケーターは、最も有益なタイプの待機アニメーションフィードバックです。それらは、現在の進捗状況、すでに達成されている量、および残っている量を示します。パーセント完了インジケーターにより、ユーザーはアクションの処理速度を理解できます。
原則として10秒以上かかるアクションにはパーセント完了アニメーションを使用する必要があります。
さあ、行きます！
しかしながら...
今日の標準では、1分は長い時間です。だから私はユーザーに何が起こっているのかを説明することをお勧めします、そうすれば彼らはこれが理由で起こっていることを理解します。例えば：
- Fooのロード（完了）
- FooのFizzbuzzing（完了）
- Fooをfoobarに適用する（43％完了）
これは同じ記事でも説明されています。画像を参照してください：
その記事の最後の点もあなたにとって興味深いかもしれません：
何かが起こるのを待っている間に人々が退屈しないようにするには、注意散漫を提供します。これは、何か楽しいこと、予期しないこと、またはアプリが読み込まれるまでユーザーの注意を引く何かである可能性があります。細かいアニメーションは訪問者の注意をそらし、長い読み込み時間を無視する可能性があります。
結論
読み込み時間は不確かで、通常は不正確ですが、読み込みの割合は常に正確です。すべてのベースをカバーするアプローチと負荷パーセンテージと推定時間とステップを混合することもできます（-===-）。