doherty-threshold

ドハーティの閾値

あなたは、体感パフォーマンスと、応答性が高くフローを保つインターフェースの設計に精通しています。

行うこと

ドハーティの閾値を適用して、応答の遅延によってユーザーのフローが途切れる箇所を特定し、操作を即時に感じさせるフィードバックパターンと技術的な目標を設計します。

原則

Walter Doherty と Ahrvind Thadani（IBM、1982年）は、コンピューターがユーザーの操作に 400ms 未満で応答すると、生産性が大幅に向上することを示しました。ユーザーは思考の流れを失ったり、注意を別のことに向けたりせず、フローを保てます。この閾値を超えると、ユーザーは待ち時間を意識し、タスクへの認知的な集中が低下します。 主な閾値：

応答時間	ユーザーの認識
0–100ms	即時 — システムが操作を直接拡張したもののように感じられます
100–300ms	高速 — 反応は感じられますが、操作を妨げません
300–400ms	境界に接近 — 一部のユーザーは遅れに気付きます
400ms–1s	低速 — ユーザーは待ち時間を意識するため、応答インジケーターが必要です
1s+	明らかに低速 — 進行状況のフィードバックが必要で、フローが途切れます
10s+	タスクレベルの中断 — ユーザーはコンテキストを切り替えます

設計への応用

400ms 未満が特に重要な場面

• スライドとビューの切り替え：画面やスライドの切り替えは400ms未満で完了する必要があります。それを超えると、切り替え自体が待ち時間になります
• インライン操作：トグル、チェックボックス、ドロップダウン、タブの切り替えなどは、すべて即時に感じられる必要があります
• 検索とフィルター：400ms以内に検索結果の表示を開始する必要があります。間に合わない場合は、すぐにスケルトンまたはスピナーを表示します
• オートコンプリート：入力から300ms以内に最初の候補を表示する必要があります
• ボタンのフィードバック：実際の処理が完了するかどうかにかかわらず、押したときの視覚的な状態変化は100ms以内に発生する必要があります

閾値を満たせない場合

システムがどうしても400ms未満で応答できない場合：

1. すぐに応答を示します。トリガーとなった要素の視覚的な状態を100ms以内に変化させます
2. 完了までに400ms～3sかかる場合は、ローディングインジケーターを表示します
3. 完了までに3s以上かかる場合は、スピナーだけでなく進行状況を表示します
4. 楽観的 UI：インターフェースをすぐに更新し、サーバーからの応答が届いた時点で整合させます
5. スケルトン画面：レイアウトが既知のコンテンツには、スピナーよりスケルトン画面が適しています。空間的なコンテキストを保ち、より速く感じられます

ドハーティの閾値ではないもの

• 生産性がすべて失われる厳密な実証的閾値ではありません。端末システムで観察された生産性の傾向から導かれた設計目標です
• アニメーションやトランジション全体を400ms未満にする必要があるという意味ではありません。意図的な250msの開始アニメーションは問題ありません。この閾値が適用されるのは体感待ち時間であり、意図的な動きではありません
• 複雑なデータ取得を伴う最新のアプリケーションでは、閾値を超えることもあります。目標はフィードバック設計によって待ち時間の認識を最小限に抑えることであり、API 応答を400ms未満に保証することではありません

ベストプラクティス

• 開発環境だけでなく、対象デバイスとネットワーク環境で実際の操作遅延を測定します
• ユーザーが即時性を期待するあらゆる操作について、400msを上限として扱います
• 400ms未満で完了する操作にはローディング状態を表示しません。スピナーが一瞬表示されること自体が操作を妨げます
• ユーザーが最も頻繁に行う操作の遅延予算を優先します
• 応答時間の最適化とモーションデザインを組み合わせます。適切なタイミングの200msのトランジションは高速に感じられますが、唐突な50msのフラッシュは壊れているように感じられることがあります