UI&UE實用方法論
編輯導讀：如今使用者的注意力資源有多稀缺？當按下回車鍵之後，反饋時間稍微長一點，使用者的注意力就會被別的東西吸引。所以說400毫秒以下的反饋速度，是最佳節點，這就是多爾蒂閾值。作為互動設計師，多爾蒂閾值是必須瞭解的知識點。
美劇《奔騰年代》（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 的系統動作規範，分析了設計層面對「多爾蒂閾值」的應用，還是稍顯片面。但感興趣的朋友，還可以去搜索瞭解更多關於「多爾蒂閾值」的實驗、故事與實踐方案。
#專欄作家#
UCD耍家，公眾號：UCD耍家（ID：ucdplayer），人人都是產品經理專欄作家。
本文由 @UCD耍家 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
