UIXHERO

ドハティの閾値 (Doherty Threshold)

「0.4秒」という応答速度の境界線。システムがこの速度以内で反応すると、ユーザーは生産性を維持し、対話的な体験を感じることができる。

2026年1月23日
更新: 2026年8月27日
8
by Dengen Yosho(DGYS)
ドハティの閾値 (Doherty Threshold)

この記事の要点(UIXHERO視点) XHEROでは、ドハティの閾値を「システムとユーザーが会話するように対話できる応答速度の限界点(0.4秒)」と定義する。 本記事では、物理的な速度の向上だけでなく、楽観的UIやスケルトン表示によって「待たされている」と感じさせない体感速度の向上策を整理する。

ドハティの閾値とは?

1982年、lter J. DohertyとArvind J. Thadaniは、コンピューターの応答時間が0.4秒(400ms)を下回ると、ユーザーの生産性が飛躍的に向上することを発見しました。 この閾値を超えると、ユーザーは注意散漫になり、システムに対する「対話感」が失われます。現代のにおいても、0.4秒ルールは「体感速度」の基準として重要です。

なぜ重要なのか

人間は、道具(システム)が自分の思考と同じ速度で反応するとき、その道具を身体の一部のように感じます()。 反応が遅いと、ユーザーは「待たされている」と意識してしまい、その瞬間に魔法が解け、フロー状態から脱落してしまいます。

現代のUXでの活用事例

実際には、すべての処理を0.4秒以内に完了させるのは技術的に不可能な場合もあります。そのための工夫が必要です。

1. 楽観的UI (Optimistic UI)

「いいね(Make)」ボタンを押した瞬間、サーバーからの完了レスポンスを待たずに、UI上では「いいね完了」を表示してしまう手法です。これにより、体感速度は0秒になります。

2. 即時の視覚フィードバック

重い処理を実行する場合でも、ボタンを押した瞬間(0.1秒以内)に「処理中」のローディング表示を出します。「処理開始を受け付けた」という反応だけでも0.4秒以内に返すことが重要です。

3. スケルトンスクリーン

コンテンツの読み込み中に、真っ白な画面を見せるのではなく、枠組み(スケルトン)を先に表示することで、体感的な待ち時間を減らします。

実装例: 応答速度の違いと体感

ボタンを押してからが返ってくるまでの時間が、ユーザー体験にどう影響するかを比較するデモです。 0.4秒の壁を超えると、一瞬の「間」を感じるはずです。

この原則を実装で見る

この原則が実装でどう形になるかを、GUNJO の部品で確かめられます。

倫理的配慮 (Ethical Considerations)

  • 人工的な遅延: 処理が速すぎる場合(0.1秒未満)に、あえて少しさせる(アニメーションを入れる)ことがあります。速すぎる変化はユーザーが見逃してしまう可能性があるためです。
  • 中毒性: 即時のフィードバックは快感を生み、SNSの「いいね」のような中毒性のあるインターフェース(スロットマシン効果)に直結します。

実装チェックリスト

更新のお知らせ

サイトに載せていない実例や、新しい記事のお知らせはこちらで出しています。

読んだ内容を、自分の画面に当てるとき

UIXHEROは、記事を書くほかに、画面の検品・判定、デザインシステムの構築、実装と改善の伴走を受けています。何を頼めばいいか決まっていない段階の相談も、同じ窓口で受けます。

UIXHEROに頼めることを見る

※ 記事の内容についての質問や、書いてほしいテーマの要望も同じ窓口で受けています

関連する原則

関連する用語 (Glossary)

参考文献

記事をシェア

メールでお知らせを受け取る

最終更新: 2026年8月27日

この記事を書いた人

Dengen Yosho(DGYS)

Dengen Yosho(DGYS)

UI/UXデザイナー兼デザインエンジニア デザイン歴25年以上 情報設計〜UIデザイン〜React/TypeScriptによる実装までを一気通貫で担当 大手企業のDXプロジェクトや決済アプリ領域で、デザインリードとして改善と構築を経験 現在はフリーランスとして、プロダクトのUI/UX改善とデザインシステム構築を支援 長年の実務の中で感じてきたのは、 「良いUI」はセンスではなく、再現可能な判断の積み重ねであるということ UIXHEROは、 心理学や行動科学の知見を、現場で使える設計言語に翻訳するための場所 関心領域は「ユーザーの行動が変わるUI」 人の認知・注意・意思決定の構造を理解し、 “なぜそのUIが機能するのか”を言語化することを目指している

あわせて読みたい

この記事に関連する記事をご紹介します

テスラーの法則と複雑性保存の法則

テスラーの法則(Tesler's Law)とは、すべてのシステムには誰かが負担しなければならない「減らせない複雑さ」が存在するという複雑性保存の法則です。UXでユーザー負担を減らす判断軸を解説します。

2026年1月23日
8

フィードバック (Feedback)

ユーザーの操作に対するシステムからの反応。ボタンを押した感触、送信完了の通知、エラー表示など、対話の成立を確認し安心感を与えるための必須要素。

2026年1月23日
6

ヒックの法則とは?UXで「選択肢が多いと決められない」心理を解説

ヒックの法則とは、選択肢が多いほど意思決定に時間がかかるという心理法則です。メニュー、フォーム、レコメンドで判断負荷を下げるUX設計の方法と、「ただ減らす」ではない整理の考え方を解説します。

2026年1月23日
10

もっと深く知りたいですか?

ここに掲載されていないトピックについても、リクエストがあれば解説記事を追加します。 わかりにくい点や、具体的な事例について知りたいことがあれば教えてください。

リクエストを送る