美劇《奔騰年代》（Halt and Catch Fire）里有一段臺詞：

 

“當你使用計算機執行一系列操作，每當你按下回車鍵，它都能在400毫秒內給予你反饋，反饋時間還不到半秒，那么就可以讓你一直保持專注，效率也會飆升，你會完全沉迷進去。但反饋時間哪怕只是偏差到半秒鐘，你的注意力都容易被分散，你甚至會想起身洗個碗、拿個遙控板、看場比賽...所以說400毫秒以下的反饋速度，是最佳節點。”

 

 

當然翻譯中帶了點我個人的語言色彩，但意思還是這么個意思，也就是說當交互反饋時間小于400毫秒，那么將大大提升用戶的專注程度與效率，用戶也不易急躁。而大于400毫秒，即使僅僅是偏差到半秒鐘（500毫秒），也容易被用戶感知到，從而影響用戶心流。

 

而劇中引用到的這個臨界值“400毫秒”，就是我們今天要聊到的——多爾蒂閾值（Doherty Threshold）。

 

 

 

一、為什么是400毫秒

 

1982年，IBM公司的WJ·多爾蒂（WJ·Doherty）及其團隊就“系統響應時間對經濟價值影響”的課題展開了研究。研究過程主要以用戶操作系統后，系統的響應時間作為變量，觀察其對多個維度的結果產生的影響。

 

最終從其中的一組研究實驗結果中觀測到了一個現象：一旦當系統響應時間超過400毫秒左右時，各項指標數據就會開始產生較大數值的波動。

 

 

于是IBM公司就此提出了研究結果：系統響應時間應該低于400毫秒，這將顯著提升用戶的關注度，從而影響到用戶的操作、工作效率。并將“400毫秒響應時間”這個節點值以WJ·多爾蒂的名字命名為「多爾蒂閾值」。

 

雖然如今我們早已認為系統擁有快速響應時間是一件理所應當的事情，但「多爾蒂閾值」的提出，在當時那個年代卻是開辟先河性的。因為70年代左右，計算機研究界還普遍以“系統的響應時間可以為2000毫秒（2秒）”作為業界標準。

 

雖然我現在已經查詢不到這個“2秒”舊知識的科研文獻了，但是在 IBM 2018年的一場歐洲線上演講會的PPT中我們還可以看到：

 

 

所以「多爾蒂閾值」可以說是重新定義了現代人機交互領域響應體驗的指標，影響著一個標準規范產品的視覺側、交互側、體驗側、開發側等多個方面。

 

 

二、多爾蒂閾值的運用

 

我們要清楚的是，「多爾蒂閾值」是IBM公司給到的一個系統響應時間的最大參考值，并不是說所有的機器響應時間都必須卡在400毫秒這個節點上，而是說響應時間應保持在400毫秒以內，盡量不要大于400毫秒。

 

那么知道了“400毫秒以內”這個范圍值，我們作為設計師，要怎么將其運用到設計工作中，或者說「多爾蒂閾值」會影響到我們哪些設計標準呢？——來看看 Google 旗下 Material Design 的系統動作規范，應該能讓你找到一些方向。

 

  · 要點一：并不是越快越好  

 

作為設計者、開發者，我們都希望系統能夠盡量快地響應用戶的操作。但也并不是一味地追求極速就一定是好的。

 

Material Design 在系統響應動作規范中強調了“過渡時間”的概念，雖然大家都希望系統的響應速度越快越好，但同時用戶也需要一些時間去理解系統響應的結果。

 

如果響應即結果，而不給用戶一個視覺過渡的反應時間，則會讓用戶無法跟隨UI變化，同樣也是會給用戶造成困擾的。

 

Material Design 規范建議到：不要給用戶過慢的響應速度，干擾用戶操作進程，讓用戶急躁；但也不要給用戶過快的響應速度，用戶無法跟隨UI變化，對用戶理解會造成困擾。

 

 

我們將響應速度結合「多爾蒂閾值」范圍內的視覺過渡效果，可以幫助用戶理解操作反饋的結果，有時間思考類似于“我剛才點擊了什么”、“結果和我的操作之間是什么關系”、“結果是否滿足我的預期”等問題，并做出下一步的反應。

 

 

  ·  要點二：響應時間不是一成不變  

 

為了讓響應視覺過渡更加符合現實規律，Material Design 根據響應結果區域的大小設置了3種響應過渡時間規范，其中又以用戶的操作場景進行了更進一步的規范細分。

 

先來說說根據響應結果區域的大小設置的響應過渡規范：Material Design 將操作響應結果區域分為小、中、大3種場景，當操作影響的結果區域越小，那么響應過渡時間就應該越短。反之，操作影響的結果區域越大，響應過渡時間就會越長。這一點是符合人類意識對運動的理解的。

 

其次 Material Design 還認為，用戶做“關閉”、“退出”類操作時，預示著他們那要進入下一個任務流，而此時上一個任務流的內容，用戶就不再關注了。操作與結果的關系、層級的關系、內容的位置關系，在“打開”、“進入”類的過渡中就已經闡明給用戶了，所以他們離開的時候，可以更快。這就是在響應結果區域大小的基礎上，又以用戶的操作場景進行的更進一步的規范。

 

• 小型區域：響應過渡統一為100毫秒；

 

• 中型區域：打開的響應過渡為250毫秒，關閉的響應過渡為200毫秒；

 

• 大型區域：打開響應過渡為300毫秒；關閉響應過渡為250毫秒。

 

結合兩個要點總結一下：系統響應應該結合視覺過渡給用戶操作與結果的關系進行指引，所以也并不是越極速越好。響應過渡應該在「多爾蒂閾值」以內，并且可以結合響應區域大小、用戶操作場景，使響應更符合現實規律，更加人性化。

 

 

三、面對不可避免的延時響應

 

雖然把系統響應控制在「多爾蒂閾值」內是我們追求的目標，但是響應速度往往和請求的數據量、網絡環境等諸多因素有關。對于結果返回數據量小的場景，我們利用視覺或代碼層面的解決方案，可以讓響應時間是可控的。

 

但當用戶遇到結果請求數據量大、網絡環境較差等場景，響應時間以“秒”起步那也是司空見慣的事情。此時面對無法保證響應時間在“400毫秒”以內的情況，我們應該怎么辦呢？

 

其實這已經超過「多爾蒂閾值」的討論范圍，對于不可避免的延時響應場景，已經是屬于“如何解決用戶等待焦慮”的話題了。

 

 

但恰好我之前在《聊聊加載等待的那些事 之 進度指示器》中聊到過這個話題。想系統了解的朋友，可以移步查看。（知識就這么串聯起來了！神不神奇~）

 

對于想走捷徑的同學，我在這里把當時的調研結果貼出來，希望能夠幫助到你們。

 

 

我結合了 “用戶等待4秒原則”和UX研究咨詢公司 Nielsen Norman Group（NN/g 尼爾森諾曼集團）的一篇文獻中提出的 用戶等待心理模型，得出了以下參考結論：

 

用戶是一個復雜的群體，他們其實并不關心所謂的量化時間，他們只希望：加載盡量快，快到不要中斷我的操作流，如果實在快不起來，那就告訴我還要等多久。所以由上表得出的結論是：

 

 

• 加載時長在0到1秒之間時：用戶不易感知，不需要給予用戶 loading 提示，在任何加載情境下頻繁給出 loading 提示其實反而會干擾用戶心流；

   

• 加載時長在1秒到4秒之間時：此時不需要明確給予用戶量化時間提示，用戶也不易產生焦慮情緒；

   

• 加載時長大于4秒時：超過這個時間你就需要明確地告訴用戶當前的進度狀況了，加載百分比或剩余時間都可以讓用戶心里有個底；

   

• 加載時長大于x秒時：設計者應該根據具體加載場景設置加載時間臨界點機制，在加載超過這個時間之后默認為加載失敗，讓用戶進行再次操作，而不是無意義地苦苦等待。

 

四、總結

 

 

「多爾蒂閾值」不僅僅是設計師完成交互動效、反饋體驗時的一個知識點，它是IBM對整個計算機反饋機制進行研究之后得到的結論，影響體驗、效率

、經濟等多個方面。所以我認為這是互聯網人都應該熟知的一條交互理論。

 

只是我在這里僅結合了 Material Design 的系統動作規范，分析了設計層面對「多爾蒂閾值」的應用，還是稍顯片面。但感興趣的朋友，還可以去搜索了解更多關于「多爾蒂閾值」的實驗、故事與實踐方案。