ユーザビリティ許容基準の一部としての「即時」の定義
セットアップ
私はこの問題に何度も遭遇しました。インターフェースの実行速度が遅く、QAまたはエンジニアリング、あるいはその両方が戻ってきて、「実行に必要な速度の許容基準を定義できますか？」
多くの場合、答えは瞬時に（またはそうでなければならない）ですが、これは「まあ、数字が必要だ」とよく遭遇します。または同様のコメント。私は即座に解釈次第である、役に立たないかもしれない、などに同意します。しかし、50ミリ秒や250ミリ秒のような薄い空気から数を選ぶのは、QAがこれを検証する方法がないのと同じくらい役に立たないです。
それは通常、「私がそれを見ると、それが正しい（または間違っている）ことを知っている」という古い格言に帰着します。
だからあなたへの私の質問は：
質問
パフォーマンスについて話すとき、ユーザビリティ許容基準の一部として「即時応答」をどのように定義しますか。何が機能し、何が機能しなかったか。正確な数を設定した場合、それはどのようにテストまたは確認されましたか？即時反応時間とは何ですか？
例の状況
編集可能なグリッドがあり、クリックして編集するときの時間（セルが入力として表示されるまでの時間）と、フィールドを終了するときに変更をコミットするのにかかる時間（フィールドの時間）を定義する必要がありますに変わるか、プレーンテキストとして表示されます）。
使いやすさの一般的な経験則は、フィードバックなしで開始し、200msの後にビジーインジケーターを表示し、プロセスが通常5より大きなフィードバック要素を表示するために数秒以上（通常は経過時間タイマーを使用しますが、時間がかかることがはっきりしない限り、できれば進行状況バーを使用しないでください）。何かが完了するまでに30〜60秒以上かかる可能性がある場合は、キューイング/バックグラウンド処理をサポートするようにアーキテクチャーを調整して、ユーザーが監視するのを強制されないようにすることを検討する必要があります。
フィードバックがインタラクティブなプロセスの一部である場合（キーボードで入力してキーが表示されるなど）は、実際に レイテンシ/フィードバックを100ms
別のマーカーもあります- ユーザーは最初の50ms で製品の潜在意識のある評価を行うことがわかりました彼らは見る。
考慮すべき別の角度もあります。一部のアクセシビリティ支援テクノロジは、遅延後に発生した場合、ページへの変更を認識しません。構築方法は、ロードされたページのコンテンツをキャプチャしてキャッシュし、使用することです。キャッシュされたコピーをユーザーに提示します。 [具体的には、JAWS、現在リンクが見つかりません]
これは非常に興味深い質問です。 「瞬時」のようなユーザビリティ要件自体は、ほとんど価値がないと思います。応答性の検証可能な基準が必要です。ただし、設定した検証可能な基準がすべて測定および達成可能であることも事前に確認する必要があります。多くの応答時間測定をスクリプト化できると思います。応答時間の一貫性は優れたユーザーエクスペリエンスにとって重要であるため、標準偏差の測定も検討します。
一般的に、瞬時の応答時間については100ミリ秒未満を目標とする必要があると私はEricsに同意します。応答時間の適切な参照は、Jakob Nielsenの 応答時間：3つの重要な制限 です。
とにかく要点は、（使いやすさ）の要件を実現したい場合は、検証可能なターゲットを設定する必要があるということです。関連文献を確認することをお勧めします。主題に関連するいくつかの記事は次のとおりです。
Nielsen Norman Group 引用 70年代から使用されているユーザビリティガイドライン：
0.1秒は、システムが瞬時に反応しているとユーザーに感じさせるための制限とほぼ同じです、つまり、結果を表示する以外に特別なフィードバックは必要ありません。
1.0秒は、ユーザーの思考の流れがとどまる限界に近いユーザーは遅延に気づくでしょうが、中断されません。通常、0.1秒を超え1.0秒未満の遅延の間は特別なフィードバックは必要ありませんが、ユーザーはデータを直接操作する感覚を失います。
10秒は、ユーザーの注意を対話。より長い遅延の場合、ユーザーはコンピューターが完了するのを待っている間に他のタスクを実行する必要があるため、コンピューターがいつ完了するかを示すフィードバックをユーザーに提供する必要があります。遅延中のフィードバックは、応答時間が非常に変動する可能性が高い場合に特に重要です。ユーザーは何を期待するかわからなくなるためです。