Webサイトのボタンを押しても画面が変わらないと、ユーザーは「クリックできていないのではないか」「もう一度押したほうがよいのか」と迷います。実際には通信や処理が進んでいても、その状態が画面から分からなければ、操作が受け付けられたとは感じられません。
このような待ち時間と操作感を考える際に参考になるのが「ドハティのしきい値」です。一般に、ユーザーの操作に対して約400ミリ秒以内にシステムが反応すると、作業の流れや集中を維持しやすいという考え方を指します。
ただし、400ミリ秒以内にすべての処理を完了させればよい、という単純な基準ではありません。Webサイトでは通信環境、端末性能、サーバー処理などを完全には制御できないため、処理時間の短縮とあわせて「操作を受け付けたことが分かる設計」が重要です。
目次
ドハティのしきい値とは
ドハティのしきい値は、コンピューターがユーザーの入力へ素早く応答することで、操作の連続性や集中を保ちやすくなるというUI/UXの考え方です。Webサイトに置き換えると、クリック、タップ、入力、送信などに対して、画面上で速やかに何らかの反応を返すことが該当します。
ここで注意したいのは、「反応」と「処理完了」は同じではないという点です。問い合わせフォームの送信処理に数秒かかる場合でも、ボタンの表示がすぐに処理中へ変われば、ユーザーは操作が受け付けられたと理解できます。
反対に、処理自体が比較的短くても、その間に画面がまったく変化しなければ、体感としては長く感じられることがあります。応答時間のUXでは、実際の速さだけでなく、待機中に何が伝わっているかも重要です。
400ミリ秒を絶対的な合格基準にしない
約400ミリ秒という数値は、設計を考えるための目安であり、すべてのWebサイトに適用できる絶対的な合格基準ではありません。利用端末、通信環境、操作内容、ユーザーの期待によって、許容される待ち時間は変わります。
たとえば、メニューの開閉やタブ切り替えは即時に反応することが期待されます。一方、在庫確認、決済、複雑な検索などは一定の処理時間がかかることをユーザーも想定しやすい操作です。ただし、時間がかかる操作でも無反応のまま待たせてよいわけではありません。
実務では、次の三つを分けて確認すると問題を整理しやすくなります。
- 操作してから、最初の視覚的な反応が出るまでの時間
- 処理が完了し、結果が表示されるまでの時間
- 次の操作ができる状態になるまでの時間
表示速度が速いだけでは、操作感は改善しない
Webサイトの表示速度を改善することは重要ですが、ページの初期表示と、表示後の操作への反応は分けて考える必要があります。
ファーストビューが速く表示されても、CTAを押した後に反応がなければ不安が生まれます。反対に、ページ全体の読み込みに多少時間がかかっても、主要なコンテンツが先に表示され、操作に対する状態変化が明確であれば、体感上のストレスを抑えられる場合があります。
Webサイトの表示速度とUXを検討するときは、次のような場面を一連の体験として確認することが大切です。
- ページを開いてから主要な情報が見えるまで
- CTAやリンクを押してから画面が反応するまで
- 検索や絞り込みを実行してから結果が更新されるまで
- フォームを送信してから完了またはエラーが分かるまで
- 画面遷移後、次に操作できる状態になるまで
なお、既存のフィッツの法則の記事が主に操作対象の大きさや距離を扱うのに対し、ドハティのしきい値では、操作した後にどれだけ早く反応が返るかを中心に考えます。押しやすいボタンであっても、押した後の反応が不明確なら、操作体験は十分とはいえません。
操作後のフィードバックは三段階で設計する
クリック後の反応を設計するときは、「操作受付」「処理中」「処理結果」の三段階に分けると、デザインと実装の認識を合わせやすくなります。
1．操作を受け付けたことをすぐに伝える
ボタンをクリックまたはタップした直後には、押下状態、色の変化、処理中表示などを使い、入力が受け付けられたことを示します。長いアニメーションを見せる必要はなく、ユーザーが変化を認識できることが重要です。
ホバー表示だけでは、タッチ操作を中心とするスマートフォンで状態を伝えられません。PCのマウス操作だけでなく、タップ、キーボード操作、フォーカス移動でも適切に反応するかを確認します。
2．処理中であることを示す
完了まで時間がかかる場合は、ローディングUIを表示します。代表的な方法には、スピナー、プログレス表示、スケルトンUI、処理中メッセージなどがあります。
どの方法を使うかは、処理内容によって判断します。コンテンツの配置が事前に決まっている一覧画面では、スケルトンUIによって読み込み後の構造を予測しやすくできます。一方、フォーム送信や決済のように結果を待つ操作では、ボタンの処理中状態や進行状況の表示が適しています。
完了時刻を正確に予測できない処理で、根拠のない進捗率を表示することは避けるべきです。実際には処理が止まっているのに進んでいるように見せると、かえって信頼を損ないます。
3．成功・失敗と次の行動を伝える
処理が終わった後は、ローディング表示を消すだけでなく、結果を明確に伝えます。成功時には完了した内容と次にできることを示し、失敗時には原因と再試行方法を案内します。
特に問い合わせ、予約、購入では、送信完了画面まで設計対象に含める必要があります。「処理中」のまま止まる、完了したのに元の画面へ戻るといった状態は、二重送信や重複購入につながる可能性があります。
Web制作で確認したい具体的な操作場面
LPのCTAと画面遷移
LPのCTAはコンバージョンに直結するため、ボタンの視認性だけでなく、クリック後の反応まで確認します。外部予約サイトや別ドメインのフォームへ遷移する場合、通信状況によっては次のページが表示されるまで時間がかかることがあります。
クリック直後にボタンの状態を変えれば、操作受付を伝えられます。ただし、通常のリンクで処理中表示を長く残すと、戻る操作や別の選択を妨げる場合があります。遷移方式や想定される待ち時間に応じて、必要なフィードバックの強さを調整します。
検索・絞り込み
検索や絞り込みでは、入力のたびに通信すると、古いリクエストと新しいリクエストの結果が前後して表示されることがあります。実装時には入力後の通信タイミングを調整し、不要になったリクエストを中止するなど、結果の整合性も考慮します。
結果を待つ間に一覧を完全に消すと、画面が大きく変わり、現在の状態を見失いやすくなります。既存の結果を残したまま処理中であることを重ねて示す方法や、更新部分だけにスケルトンUIを表示する方法も検討できます。
結果が0件だった場合も、単に空白を表示するのではなく、条件の見直しや解除方法を提示します。速さだけでなく、結果の意味が理解できることまで含めてUXを設計します。
問い合わせフォーム
フォーム送信ボタンを押した直後は、ボタンを処理中状態へ変更し、連続操作を防ぎます。ただし、見た目上ボタンを無効にするだけでは、通信の再送やサーバー側の重複処理を完全には防げません。重要なフォームでは、実装側でも二重送信を防ぐ仕組みを検討します。
送信に失敗した場合は、ボタンを再操作できる状態へ戻し、入力内容を可能な限り保持します。エラーによって入力内容がすべて消えると、ユーザーは再入力を求められ、離脱しやすくなります。
また、画面上部にだけエラーを表示すると、スマートフォンでは見落とされることがあります。該当項目の近くに内容を示し、必要に応じてエラー箇所へフォーカスを移すなど、アクセシビリティにも配慮します。
予約・購入・決済
予約や購入では、操作感を軽く見せるために、確定前の状態を完了したように表示してはいけません。在庫、予約枠、決済結果など、サーバー側の確認が必要な処理は、正式な応答を受け取ってから完了として扱います。
待機中には「在庫を確認している」「決済処理が進行している」といった処理の意味を伝えると、ただ回転するアイコンを表示するよりも状況を理解しやすくなります。処理に時間がかかる可能性がある場合は、画面を閉じないことや再操作しないことも、必要な範囲で案内します。
ローディングUIだけで問題を隠さない
操作フィードバックは重要ですが、遅い処理をローディング表示だけで覆い隠すべきではありません。待ち時間そのものを短くするため、デザイナーと実装担当者が原因と優先順位を共有する必要があります。
画像は表示位置と役割から優先順位を決める
ファーストビューのメイン画像は、適切なサイズや形式を選び、必要以上に大きなデータを配信しないようにします。一方、画面下部の画像は遅延読み込みを検討できます。
すべての画像を一律に遅延読み込みすると、最初に見せたい画像まで遅れる場合があります。「容量が大きい順」だけではなく、ユーザーが最初に必要とする情報かどうかで優先順位を決めることが重要です。
JavaScriptは量だけでなく実行タイミングを見る
JavaScriptが多いサイトでは、画面が表示されていても、メインスレッドが処理で塞がり、クリックへの反応が遅れることがあります。使用していないライブラリ、初期表示に不要な機能、外部タグなどを確認し、読み込みや実行のタイミングを調整します。
広告計測やマーケティングタグは運用上必要な場合もあるため、単純に削除するのではなく、目的、発火条件、ページごとの必要性を整理します。表示速度と計測要件の両方を理解したうえで判断することが大切です。
サーバー処理とフロントエンドを分けて調べる
フォーム送信や検索が遅い場合、原因が画面側にあるとは限りません。API、データベース、外部サービス、メール送信など、サーバー側の処理時間も確認します。
フロントエンドでは即座に処理中表示を出しつつ、バックエンドでは応答時間を計測することで、「体感を改善する対応」と「根本的に処理を速くする対応」を分けて進められます。
デザインと実装の連携で決めておくこと
ローディングやエラー表示は、デザインカンプで省略されやすい要素です。しかし、実装段階で判断を任せると、ページごとに挙動や表現がばらつく原因になります。
ワイヤーフレームやUI仕様を作る際は、通常状態だけでなく、次の状態も定義しておくと手戻りを減らせます。
- 操作前、押下中、処理中、完了、失敗の各状態
- 処理中に再操作できる範囲
- 通信が切れた場合の表示と再試行方法
- 結果が0件の場合やデータが存在しない場合の表示
- 入力内容や検索条件を保持する範囲
- 読み上げ機能へ状態変化を伝える方法
- アニメーションを抑える設定への対応
デザイナーは状態の見え方と情報の優先順位を整理し、実装担当者は実現方法、通信処理、例外条件を確認します。ディレクターは、どの操作を優先して改善するか、計測対象と受け入れ条件を整理します。
公開後に計測したい応答時間とユーザー行動
ドハティのしきい値を実務に活かすには、見た目の印象だけで判断せず、実際の応答時間とユーザー行動を確認します。
主要操作ごとに時間を分けて計測する
まず、問い合わせ送信、予約開始、商品絞り込みなど、事業上重要な操作を選びます。そのうえで、操作から最初の反応まで、結果表示まで、次の操作が可能になるまでの時間を分けて確認します。
ページ全体の平均表示時間だけを見ても、特定のボタンやフォームで起きている問題は把握できません。ブラウザの計測機能、実ユーザーのパフォーマンスデータ、サーバーログなどを組み合わせて原因を調べます。
操作への応答性を確認する指標としてINPを参照する方法もあります。ただし、INPだけで問い合わせ完了や検索結果表示までの時間を把握できるわけではありません。重要な処理については、開始、成功、失敗を個別に計測する設計が必要です。
再クリックや離脱も確認する
同じボタンが短時間に複数回押されている場合、フィードバックが見えていない可能性があります。送信開始後の離脱、エラー発生率、再試行回数、完了率なども確認すると、単なる速度問題か、案内不足かを判断しやすくなります。
ただし、クリック数だけで原因を断定することはできません。実機確認や簡易的なユーザーテストを行い、どの時点で迷ったのかを観察することが重要です。
改善時のチェックリスト
Webサイトの待ち時間と操作フィードバックを確認するときは、次の項目をチェックします。
- クリックやタップの直後に視覚的な変化があるか
- 処理中と操作不能の理由が分かるか
- 完了、失敗、未完了の違いが明確か
- 連続クリックや二重送信を防げているか
- エラー後に再試行でき、入力内容が保持されるか
- スケルトンUIが実際の表示構造と大きく異なっていないか
- 古い検索結果が新しい条件の結果を上書きしないか
- 低速な通信環境や性能の低い端末でも状態が伝わるか
- キーボード操作や読み上げ機能でも状態を把握できるか
- 色やアニメーションだけに情報を依存していないか
- 画像やJavaScriptの最適化が主要導線を優先しているか
- 重要な操作の開始、成功、失敗、所要時間を計測できるか
速く見せることより、状況を正しく伝える
ドハティのしきい値は、400ミリ秒という数値だけを守るためのルールではありません。ユーザーの操作に対して適切なタイミングで反応を返し、作業の流れを途切れさせないための考え方です。
Web制作では、表示速度の改善、操作直後のフィードバック、待機中の案内、完了・エラー表示を一体として設計する必要があります。特にLPのCTA、問い合わせフォーム、予約・購入導線では、処理が速いかどうかだけでなく、「何が起きているか」「操作が受け付けられたか」「次に何をすればよいか」が分かることが重要です。
また、待ち時間を短く感じさせるために、確定していない処理を完了したように見せたり、戻る操作を不必要に妨げたりする設計は避けるべきです。ユーザーを急かすのではなく、正確な状態を分かりやすく伝えることが、信頼につながるUI/UX改善になります。
WebサイトやLPの表示速度、フォームの応答、操作中のフィードバックを含めたUI改善を検討している場合は、制作実績をご覧ください。具体的な課題については、CONTACTページからご相談いただけます。