響應時間指從用戶執行操作到反饋出現的間隔時間。
Robert B. Miller在他的研究《人機對話的響應時間》中，定義了用戶可以從計算機中得到多達17種的反饋，其中一種稱爲“控件操作響應”時間，即按下按鈕到得到視覺反饋的時間。規定了它不應該超過0.1-0.2秒。對於熟練的用戶來說，100毫秒（1 秒=1000 毫秒）的延遲都可能太慢了，這就意味着，理想情況下，用戶應當在100毫秒內獲得操作的反饋。
100毫秒是什麼概念呢？就人體最快的潛意識動作眨眼來說，根據倫敦城市學院神經學創立者Davina Bristow的說法，“多數人每分鐘眨眼大約15次，一次眨眼平均持續100到150毫秒”。
那麼系統在不同時長的響應時，我們需要給用戶怎樣不同的反饋呢？在NNG上有一篇文章《Response Times: The 3 Important Limits》是關於操作響應時間的基準，總結如下：
1）0.1秒是用戶瞬間感受的界限，這意味着不需要任何提示（feedback）可直接顯示結果。
2）1秒：即使用戶感覺到了延遲，但仍然感覺流暢並保持連續的操作，一般來講，延遲在0.1秒~1秒之間，是不需要特殊提示的， 但用戶仍然會失去直響應的感覺。
3）對於2~10秒的操作，如果使用百分比進度條顯得有些大材小用，並且過快的顯示也會讓用戶有種閃爍的不好效果。這時可以僅使用一個“忙碌”的動畫，並且在合適的位置配上一個變化的數字提示進度，效果更好。
4）10秒是用戶專注於單一任務的極限。對於超過10s延遲，在計算機執行的過程中應當給用戶提示，用戶將會進行其它的操作，而不會等待計算機執行完畢。
補充知識
1、關於“樂觀派”UI設計
通常的服務器響應時間爲1s左右，對於由用戶直接觸發的操作反饋而言不能達到理想的響應速度。因此樂觀派UI的設計讓用戶產生一種幻覺，讓他認爲成功反饋的獲得是瞬間的。
樂觀派UI僅僅是處理人機交互的一種方式。它指無論成功與否，都給用戶一個正向的反饋，比如一些應用中的點贊行爲。無論當前有沒網絡，點擊“贊”，都會給予用戶點贊成功的反饋。如微博斷網時，點贊會成功，並且計數器+1。而知乎在斷網時，點贊失敗並提示未連接網絡。
樂觀派UI的設計主要基於以下3個條件：
1）用戶的操作在97%-99%的情況下服務器返回結果都是成功；
2）在1%~3%的出錯場景下服務器能夠在2s內給予錯誤反饋；
3）操作的結果只是簡單的“成功”和“失敗”兩種情況，不存在其他中間狀態。
2、關於“進度指示器”的設計
通常進度指示器適用於等待超過10s的場景，但在某些場景下等待時間小於10s時也試用，比如涉及到處理一系列的表單和文檔，進度指示器顯示已處理3/50的文件。在等待時間較長時，給予用戶停止進程的選擇。關於進度志氣的動效設計有如下建議：
1）開始時進展移動速度慢，越接近結束時越快（超出用戶預期）；
2）提供大致的時間預期，不需要太精準，否則會讓用戶失去信任。“至少需要1分鐘”；
3）如果時間不容易預估，使用已經完成的步數來替代時間百分比，“已下載4/30”。
2、計算機的響應時間並不是越快越好，在有些場景下過快的響應會給用戶的操作帶來困擾。例如，滾動列表的滾動速度太快到讓用戶無法及時停止目標內容。
在之前的一些書籍中提到過一個案例：iPhone自帶計算器在計算“2500÷50=”，很容易結果顯示“1”，因爲顯示器在輸出結果“50”時變化太快，以至於用戶沒有察覺，會多點擊一下“=”，這樣就成了“2500÷50÷50=1”了。不過現在的iPhone計算器在輸出結果時，可以看到會有延遲，結果“50”會閃一下，這麼做不是因爲系統性能跟不上，而是故意爲了讓用戶有察覺。
3、對於無法計算進度的操作，也應當給予用戶適當的反饋。例如：掃描未知大小的數據庫時，可以打印出已掃描的表。另外替代方案是提供一個簡單的等待動畫，提示用戶程序在運行中。
結合實例
1、增加觸發延遲案例
在網頁中有許多的選項卡或相冊輪翻，這些大都是使用mouseover事件觸發。這就會出現一個問題，鼠標無意之中劃過觸發區域進行切換，瞬間響應會給人以閃爍的感覺。具體的解決方法：既然100毫秒內的延遲，用戶都不會有所察覺，那就增加觸發延遲。
2、減少提交服務器次數案例
如果每點擊一次按鈕都會觸發一次請求，那麼在第一次點擊到得到反饋的這段時間裏用戶可能會多次點擊提交，這將會有許多無效請求，對服務器造成一定壓力。因此多數應用會在一段時間內減少提交次數，時間一般控制在200~250毫秒內，也就是，多次點擊只提交一次請求。
3、時間界限的研究
在NNP上有一篇文章關於用戶體驗的時間界限，《Powers of 10: Time Scales in User Experience》，從0.1秒到1個月，1年（網站1年的老用戶纔會對產品熟識），10年（一個複雜的系統需要10年才能發展沉澱出一份專業的理論知識），100年……