本文へスキップ

ドハティの閾値

システムの応答が 0.4 秒以内に返ると、人は思考を途切れさせずに操作を続けられる。それを超えると待つ意識が生まれ、生産性が落ちる。

Doherty Threshold

なぜ効くか

1982 年に IBM の Walter Doherty らが、端末の応答時間と利用者の作業効率の関係を測り、応答が 400 ミリ秒を下回ると作業量が急に増えることを報告した。速い応答は「次に何をするか」を覚えたまま操作できるからで、遅いと考えが一度途切れ、再開に余分な時間がかかる。Web UI では、実際の処理を速くする以外に「速く感じさせる」手段がいくつもある。入力のたびに一覧を絞り込む、押した瞬間に押し込みや波紋で受け付けを示す、読み込み中はスケルトンで形を先に見せる、送信ボタンを即座に「送信中」に変える、生成中の文字を届いた順に流す、といった工夫は、応答そのものを待つ時間を「何かが進んでいる時間」に変える。

UIでの当て方

  1. 01入力に対する反応（絞り込み・件数・検証結果）は入力のたびに返す。通信が要るなら、デバウンスで回数を減らしつつ表示は即座に更新する。
  2. 02押した瞬間の受け付け（押し込み・波紋・ラベルの変化）を 100 ミリ秒以内に見せ、結果は後から差し替える。
  3. 031 秒を超える待ちにはスケルトンかスピナーを出し、完了後の形が分かっているならスケルトンを選ぶ。
  4. 04長い生成・処理は、できた部分から順に表示する。全部揃うまで白紙にしない。

誤用・反例

  • 速さを演出するために、実際には終わっていない処理を「完了」と表示する。
  • 0.4 秒以内でも、変化が見えなければ利用者は気づかない。速いだけで反応を省く。

この原則を体現するパーツ

  • 入力

    即時フィルタ

    Live Search Filter

    検索ボックスに入力するとリストが即座に絞り込まれる。ページ遷移なしでさくさく探せる。

    • JS
    コードを見る →
  • 入力

    即時検索＋一致ハイライト

    Search Term Highlighting

    入力のたびに記事一覧を絞り込み、一致した文字を <mark> で強調する。件数はライブで更新され、空白区切りの複数語は AND で効く。0件では言い換えを促す。

    • JS
    コードを見る →
  • クリック

    結果件数のライブ更新

    Live Result Count

    条件を変えると件数がスケルトンになり、少し置いて数字に戻る。連続した変更はデバウンスで1回のリクエストにまとめ、aria-live で件数の変化を読み上げる。右上に変更回数とリクエスト回数を出す。

    • JS
    コードを見る →
  • クリック

    送信ボタン演出解説あり

    Button Loading State

    送信ボタンを押すとスピナーが回り、完了後にチェックマークへ変化。処理中の状態を明示する。

    • JS
    コードを見る →
  • クリック

    スケルトンローディング解説あり

    Skeleton Screen

    読み込み中に輝く光が流れるプレースホルダを表示し、完了後に実コンテンツへ差し替わる。

    • JS
    コードを見る →
  • クリック

    スケルトン→本文クロスフェード

    Skeleton Crossfade

    スケルトンと本文を同じグリッドセルに重ねて置き、読み込み完了で不透明度だけを入れ替える。要素の差し替えをしないのでレイアウトシフトが起きない。

    • JS
    コードを見る →
  • クリック

    AIタイピングインジケータ

    AI Typing Indicator

    AIが考え中の「・・・」3点バブルから、回答が1文字ずつ流れ込むストリーミング風表示。チャットUI・AIアシスタントの定番フィードバック。

    • JS
    コードを見る →

関わるカテゴリ

出典