進行状況をパーセンテージまたは絶対数で表示しますか？
ユーザーが費やした時間（分）と、特定のタスクに費やすのに必要な時間（分）に基づいて、単純な進行状況バーを作成しています。例については、以下を参照してください。
ラベルの3つのオプションを検討しています：
- パーセンテージ（75％）。
- 完了した分と必要な分数（45/60分）。
- 上記の両方。
分を指定すると、実際にどれだけの時間を費やす必要があるかがわかりやすくなります。一方、割合を指定すると、相対的な進捗状況がより明確になります。必要な分数（60分）は、このラベルだけでなく、他の場所でも通知されることに注意してください。
上記のオプションのうち、不要な情報を表示せずに、ユーザーにとって最も有益なオプションはどれですか？
さらに、カーンアカデミーは％完了とx/xxスキル完了の両方を％に重点を置いて使用していることに気付きました。 （下記参照）
私の正直な意見は費やされた時間/合計時間ラベルで十分であり、パーセントを追加することも冗長な情報であるということです。
だから、特にカーンアカデミーを考えると、なぜ完了/合計ラベル+ パーセンテージラベルの両方があると思いますか？答えは、2つのシナリオを区別するものです。設計には、ベンチマーク（カーン）に存在しない進行状況バーがあり、進行状況バーは、どれだけの作業が行われ、どれだけ残っているかを即座に視覚的にフィードバックします。
ユーザーは、彼女が半分以下の時間、半分の時間、または半分以上の時間で完了したかどうかを知りたいと思うでしょう。一目ですぐにわかるでしょう。より高解像度のフィードバックについては、ユーザーは時間ラベルを表示して、残り時間の実際のフィードバックを取得できます。この上にパーセンテージラベルを追加しても、追加の値は得られません。代わりに、視覚的なバルクと認知負荷が増加します。
つまり、要約すると、時間ラベルのみを表示するのに十分なフィードバックをすでに提供しています。
私がクラスにいて、出発できるまで時計をじっと見つめている場合、そこに費やした時間を知りたくありません。気になるのは、X時までの時間です。
上記の心理学で、私が提供できる最も有益な情報はTime remaining: 17 minutesそして、時間が経過するにつれてこれを更新します。
ある種のバーを作成する準備ができていない場合は、ページの読み込み時にバー（フルオレンジ）を作成し、残り時間を減らすと、それに応じてバーを減らす（白くする）必要があります。
両方のインジケーターには長所と短所がありますが、おそらく比率のみを使用すると、数学処理が含まれる可能性があるため、ユーザーの認知負荷が最も高くなります。では、なぜ安全に遊んで両方を使用しないのですか？特に、デザインにペナルティを課すことなくそれを回避できる場合。
それはあなたの意図に依存します。
あなたが提供したカーンアカデミーの例では、具体的にはより抽象的なものにするためのパーセンテージに重点が置かれていると思います。何かを完成させようとしている人にとって、方法の50％であることが100/200であるよりも前向きに見えるため、実行する必要のある作業が少なくなるように感じるかもしれません。
ダウンロードプログレスUIについて考えると、ユーザーとしてパーセンテージを確認することはめったにありません。私が気にしているのは、ダウンロードしているものをすべて使用できるようになるまでにかかる時間だけです。
システムの速度に依存します。
ノーマングループのこの良い記事をご覧ください。
http://www.nngroup.com/articles/progress-indicators/
プログレスバーには3つの目標があります：-1-ユーザーがシステムが生きていると言うのに役立ちます。心のリズムとして-2-は、ユーザーが待機する必要のある「およその時間」を知るのに役立ちます-3-最後に、システムの速度が低下しているように見えるように注意をそらすために気を散らします。ユーザーの満足にとって重要です。
「step x of y」という情報のみを提供する場合がありますが、割合の情報を提供する場合もあります。ユーザーが15分、40分、または1時間を完全に把握しているため、めったにリアルタイムではなく、アプリについてのユーザーの気持ちに悪影響を与える可能性があります。リスクはあなたがシステムの遅さを強調することです。
また、何らかの理由で、ユーザーがアプリを信頼しなくなるypuの指示よりも遅くなります。
Windowsで大量のコピーファイルを使用して時間情報を覚えていますかXP .... 5分、2番目の後で190分と表示されることがあります...この情報を信頼していますか？
そのため、ユーザーを助けるために情報を提供しますが、誤っている可能性がある正確な情報をユーザーに嘘をつかないように注意してください。
また、一部の設計パターンでは、システムが既に実行したステップ数ではなく、usr rが待機する必要があるステップ数を表示することにより、肯定的なメッセージを表示することをお勧めします。例：「システムは120/123ステップを実行しました」よりも「最後の3ステップだけで問題ありません」
間違い、申し訳ありません。あなたの本当の問題に答えるためにいくつかの要素。時間を表示する場合は、実際の平均時間であることを確認してください。複数のユーザーでテストするか、可能であれば、各ユーザーステージを記録して動的に平均時間を計算してください。実際の個人の平均時間を計算するために、彼が高速または低速である割合を考慮することもできます。必須の正確なユーザーの平均時間です。言い換えれば、彼らを恐れたり、到達できない時間をかけてストレスを与えたりしないでください。私の最初の返信と同じ制約：コンテキストに依存します。質問が15個しかない場合（このカーソルは一例です）またはステップの場合、ユーザーは問題なく、次に進む準備ができています。彼を表示する100の質問がある場合、2/100は彼を恐れることができ、2 himも彼を恐れることができ、ステップまでに5分かかると、500分で確実に彼を恐れることになります。解決策の1つは、「12分で10番目の質問に到達しました。ここでも約45分で終了です！」のような「自然言語」にもあります。または、ユーザーがカーレースのゲームのステージのようなステップのグループで勝てる仮想価格を想像してみてください。したがって、ステップ数/合計が多くない場合は、理解しやすく、ワークロードが完了するまでの時間もわかりやすくなります。より多くのステップがあると、パーセントは理解しやすくなり、恐れることなく、ワークロード時間をプラスします...そして最後に、質問が多すぎる場合は、グループに分けて、数またはパーセントとワークロード時間と価格を使用します。