2019-4-25 濤濤
1. 原理表述
系統需要在 400ms 內對使用者的操作做出響應，這樣才能夠讓使用者保持專注，并提高生產效率。
2. 實驗背景
上世紀 70 年代后期，計算機研究人員依然認為計算機可以花費兩秒的時間對使用者的操作做出反饋，因為他們認為人們大概正好需要兩秒時間來決定下一步的操作，所以 2s（2000ms）一度成為了當年計算機響應時間的標準值。直到 1979 年計算機的算力開始大幅提升，也有了足夠的能力在 2000ms 內做出響應，這時 IBM 的研究員 Walter Doherty 進行了一系列研究來評估算力的增長對生產力的影響。
研究結果表明，計算機的響應速度直接影響了使用者做出下一個決定所要花費的時間（這個時間被稱為用戶響應時間），換句話說，計算機相應的時間越長，用戶就要花費越多的時間來思考和決定下一步的操作。
上面這張表格充分說明了這一觀點，橫縱坐標分別為用戶響應時間和系統響應時間，我們可以看到系統響應時間如果從之前的 2000ms 降低到 300ms ，使用者作出下一步指令所需要的時間就能夠縮短 5s 以上。Doherty 認為人們會將工作需要的一系列操作步驟存儲在短時記憶之內，如果系統響應時間太長，就會打斷人們的短時記憶，換句話說，思路都不連貫了。
不僅如此，Doherty 還認為響應速度低于 400ms 的系統或者程序，會讓人上癮。放在當下的環境來看，這當然只是一句比較夸張的話，但是結論是需要我們重視的，程序的響應時間，務必在 400ms 之內。
要說「多爾蒂門檻」帶給我們的啟示，上一節最后一句已經表達得足夠清楚：系統或程序的響應時間小于 400ms 。為了讓讀者有更加直觀得感受，我們先來一組小動畫感受一下高響應延遲有多讓人抓狂，快速響應又多么讓人舒服：
應用案例 1：模擬延遲效果
注：請務必挨個觀察，不要看整體，看單個的效果。
從動畫中可以感受到，50ms、200ms 還算可以讓人接受，當響應時間達到 600ms 時已經讓人有些不耐煩，而達到 1000ms 時會讓人不自覺多點幾下，2000ms 時我手機已經被我砸了。
在如今的計算機算力之下，響應時間輕輕松松便能夠達到多爾蒂門檻的閾值，甚至能夠遠比 400ms 更小，但是這就夠了嗎？「多爾蒂門檻」說到底只是給出了響應時間的上限，400ms 的響應時間或許在多爾蒂那個時代確實能夠大幅提升操作員的操作效率從而產出更大的經濟效益（比如銀行系統），但是現在互聯網已經越發成熟，不少公司的用戶體驗研究者都已經意識到，系統響應時間已然不是影響用戶響應時間的唯一因素了，另一個因素是過渡動畫的持續時間。
就像谷歌在 Material Design 中明確規定了過渡動畫的 Speed 這一項，這是為什么呢？用戶體驗是一門關于情感和邏輯的學問，而不僅僅是一個統計數字就能解釋的，讓程序對某一操作的反饋時間（包括響應+動畫）符合用戶對該操作的預期才是讓用戶「上癮」的關鍵。
應用案例 2：iOS 中的動畫
所以，哪怕我們的手機、電腦已經可以做到在 100ms 之內做出響應，快到完全有能力在用戶反應不過來的情況下給出反饋和結果，但是這樣是不夠的，我們依然需要「合適時長的」動畫作為計算機反饋和大腦反應之間的潤滑劑，而不至于讓程序使用起來太「干澀」，也不至于讓大腦一直處于應激反應的階段而感到疲勞。
在真實世界中我們使用應用時會發現，有時候響應速度沒辦法做到如此迅捷快速，比如 APP 啟動時；還有時候即便系統可以響應，網絡卻不行。網絡并不能在用戶操作的一瞬間就把所有需要的資源都下載好，用戶必須等待幾秒的時間，那么這時候就需要考慮如何減少用戶等待的焦灼感，優化等待的體驗。
比如有趣的加載動畫、閃屏頁等，都算是解決辦法。
應用案例 3：Netflix 的啟動動畫以及新草的加載動畫
動畫的持續時間應當在適當的區間中取到最短，而不能太突然或太緩慢。
反面案例 1：過快或過慢的動畫
在現實的上線 APP 中，也會有故意把動畫做得很慢的例子，這比較影響操作的流暢性。
反面案例 2：Eggzy
左右滑動的時候動畫效果在實際體驗中非常慢，對于想要進行連續滑動操作的用戶（即便這樣的使用場景不多），已經慢得無法忍受，有一種「不跟手」的感覺，這么慢的動畫已經很輕易就能讓用戶感受到自己在等它了。
仔細瀏覽 Material Design 中給出的案例便可以發現，動畫的持續時間大致可以參照以下幾條規律去嘗試：