UI&UE實用方法論 | 做交互體驗,你必須得知道的「多爾蒂閾值」

2021-8-12    seo達人



美劇《奔騰年代》(Halt and Catch Fire)里有一段臺詞:

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

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

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

 

一、為什么是400毫秒

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

最終從其中的一組研究實驗結果中觀測到了一個現(xiàn)象:一旦當系統(tǒng)響應時間超過400毫秒左右時,各項指標數(shù)據(jù)就會開始產生較大數(shù)值的波動。

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

雖然如今我們早已認為系統(tǒng)擁有快速響應時間是一件理所應當?shù)氖虑椋付酄柕匍撝怠沟奶岢?,在當時那個年代卻是開辟先河性的。因為70年代左右,計算機研究界還普遍以“系統(tǒng)的響應時間可以為2000毫秒(2秒)”作為業(yè)界標準。

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

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

 

二、多爾蒂閾值的運用

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

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

 

要點一:并不是越快越好  

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

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

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

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

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

 

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

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

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

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

 

  • 小型區(qū)域:響應過渡統(tǒng)一為100毫秒;

 

  • 中型區(qū)域:打開的響應過渡為250毫秒,關閉的響應過渡為200毫秒;

 

  • 大型區(qū)域:打開響應過渡為300毫秒;關閉響應過渡為250毫秒。

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

 

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

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

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

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

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

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

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

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

  • 加載時長在0到1秒之間時用戶不易感知,不需要給予用戶 loading 提示,在任何加載情境下頻繁給出 loading 提示其實反而會干擾用戶心流;
  • 加載時長在1秒到4秒之間時:此時不需要明確給予用戶量化時間提示,用戶也不易產生焦慮情緒;
  • 加載時長大于4秒時:超過這個時間你就需要明確地告訴用戶當前的進度狀況了,加載百分比或剩余時間都可以讓用戶心里有個底;
  • 加載時長大于x秒時:設計者應該根據(jù)具體加載場景設置加載時間臨界點機制,在加載超過這個時間之后默認為加載失敗,讓用戶進行再次操作,而不是無意義地苦苦等待。

 

四、總結

「多爾蒂閾值」不僅僅是設計師完成交互動效、反饋體驗時的一個知識點,它是IBM對整個計算機反饋機制進行研究之后得到的結論,影響體驗、效率、經濟等多個方面。所以我認為這是互聯(lián)網人都應該熟知的一條交互理論。

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

 

原文地址:UCD耍家(公眾號)

作者:Howiet


轉載請注明:學UI網》UI&UE實用方法論 | 做交互體驗,你必須得知道的「多爾蒂閾值」

藍藍設計建立了UI設計分享群,每天會分享國內外的一些優(yōu)秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯(lián)系。

截屏2021-05-13 上午11.41.03.png

分享此文一切功德,皆悉回向給文章原作者及眾讀者.
免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯(lián)系,我們立即更正或刪除。

藍藍設計bouu.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務


分享本文至:

日歷

鏈接

個人資料

藍藍設計的小編 http://bouu.cn

存檔