電商網站里展示商品的**交互形式是什么?是分頁、“加載更多”按鈕還是無限滾屏?我們在Baymard機構開展了幾項持續整年的大規模可用性測試,研究了50多家主流電商網站。我們測試了這3個設計形式在PC端和移動端的效果(以及一些其他問題)。
由于分頁功能在幾乎所有電商平臺上都可以默認設置,它仍然是加載新商品***普遍的方法。然而我們的可用性測試發現:“加載更多”按鈕與延遲加載機制(指當真正需要數據的時候,才執行數據加載操作,避免無謂的性能開銷)相結合是一個更**的實施方案,它能夠帶來更無縫的用戶體驗。
我們發現在可用性上,無限滾屏簡直糟透了——尤其是在搜索結果頁和在移動端上。然而這些結果不是非黑即白的,每一種商品展現形式的優劣取決于當前頁面的情境。
我們將在本文中詳細說明Baymard機構對“加載更多”按鈕、無限滾屏和分頁這三種形式的可用性研究結論,包括移動端和PC端。我們還會理解,為什么搜索結果頁與分類導航的解決方案要有所不同,順帶介紹一些主流電商網站的案例和可能誤區。
一、測試的發現
我們對電商網站的商品列表和篩選列表頁進行了大規模可用性測試,用戶們對翻頁樣式怨聲載道。測試用戶普遍認為翻頁功能速度慢,并且展示很多頁碼的鏈接經常令用戶不愿瀏覽整個商品列表。更重要的是,我們觀察到測試用戶在翻頁功能下,瀏覽的商品數量比“加載更多”按鈕或無限滾屏這兩種形式瀏覽的商品數量要少得多。另一方面,翻頁的好處是用戶在***頁商品上瀏覽的時間相對更長。
圖注:很多測試用戶會根據頁碼的數量(例如上圖Macy’s網站展示的)來估算搜索結果頁的商品總數。盡管頁碼可以讓用戶自由地跳轉到任何一頁,但測試中很少用戶會這樣做。相反,他們幾乎只使用“下一頁”和“上一頁”這兩個按鈕。
在無限滾屏(或叫無止境滾屏)的狀態下,大部分用戶會覺得頁面所有商品在瞬間加載完成(不管他們實際上有沒有看到所有商品),而不會產生數百商品同時加載的負面效應。
因此,如果好好應用無限滾屏機制,將會產生非常流暢的無縫體驗。用戶能在不被打斷的情況下滾動商品列表,而不需要額外的交互操作——用戶滾動屏幕即可看到商品。
這樣一來,測試結果就不意外了:用戶在無限滾屏的狀態下,瀏覽的商品數量比翻頁或“加載更多”按鈕都要多很多。不過,無限滾屏顯示的***屏結果比較少,因此更適合快速展示某個品類的范圍。由于正常情況下,用戶不會滑著滑著突然停止,他們想要瀏覽更多商品,因此不會對列表中的單個商品過于糾結。
圖注:請注意滾動條的長度。在提供無限滾屏的網站上,測試用戶經常瀏覽100個甚至更多商品,這個數量在提供翻頁的頁面上是**達不到的,在提供“加載更多”按鈕的頁面上達到這個數量的情形也極為個別。盡管對前50-150個商品來說,無限滾屏讓用戶的瀏覽更有效率,但如果列表沒有結束的話,一些用戶會繼續滾動列表而不去關注任何一件商品,這就使無限滾屏的好處變為壞處了。
有時候,無限滾屏也會讓用戶無法看到頁面底部。這是無限滾屏**的設計難題,即,一旦用戶到達列表底部,頁面會持續加載新的結果,用戶看到頁腳的時間只有一兩秒,然后下一批搜索結果加載完成,突然出現,頁腳隨之消失。在搜索結果頁和一級品類列表頁中,通常列表中有很多商品,無限滾屏實際上讓用戶永遠也到不了頁面底部。這可能是一個大問題,因為頁面底部能用戶跳轉到幫助頁,還提供了交叉導航、關聯品類,以及關于用戶服務、配送和退貨的信息。
我們測試的網站中只有很少一部分使用了“加載更多”按鈕,但它們的用戶接受度很好。實際上,當我們對標TOP50美國電商網站時,發現只有8%的網站使用“加載更多”的方法。“加載更多”是很簡單的設計,它不需要用戶去想該去哪頁,因此不給用戶造成負擔,它僅僅詢問“你是否要看更多結果”,這使得交互界面非常簡單,它按用戶需要加載更多商品,帶來的認知負荷可能是***小的。在“加載更多”狀態下,用戶總體上瀏覽的商品數量比翻頁頁面更多,但因為加載更多商品仍需要用戶做出主動選擇和點擊,用戶會比無限滾屏時更仔細地查看商品。
圖注: 在提供了“加載更多”按鈕的網站,例如American Eagle Outfitters上面,用戶比提供翻頁功能的網站瀏覽了更多商品,但他們不像在無限滾屏的情境下那么快地掃描商品。不僅如此,商品探索變得簡單了很多,因為用戶能夠直接在當前列表中插入更多商品。
“加載更多”和無限滾屏的好處之一是商品列表可以增加而不是被替換。“加載更多”允許用戶在整個列表中更方便地比較商品。擁有一個整合的商品列表令用戶更容易地評估哪些商品值得點擊,從而提升了商品的總體發現率。
那么,你應該使用哪種加載方法?按照理想情況,根據測試結果,你應該使用“加載更多”的多種變體。測試顯示沒有哪一種方法在所有情境下都是完美的,不同的情境要求使用“加載更多”的三種變體之一。我們將在本文剩余部分講到這三種變體:
對分類列表頁,結合使用“加載更多”和延遲加載。
對搜索結果頁,使用“加載更多”,**是讓展示商品的數量基于相關度靈活可變。
在移動端,使用“加載更多”,但默認展示的商品數量要比PC端少一些。
注意:這些發現是居于對電商網站的測試。三種交互形式的表現在其他類型網站上會有不同。
二、在分類列表頁使用“加載更多”
在對電商網站首頁和分類導航的大規模可用性研究當中,我們發現,加載新商品的**方式是結合使用“加載更多”按鈕和以延遲加載方式實現的無限滾屏:***頁商品列表上展示10-30個商品,延遲加載另外10-30個商品;一旦用戶點擊“加載更多”按鈕,再加載10-30個商品,并恢復延遲加載,直到接下來的50-100個商品加載完成,這時再次顯示“加載更多”按鈕。“加載更多”按鈕控制的50-100個商品決定了用戶的瀏覽何時被打斷,而延遲加載僅僅是為減少加載時間和負擔所實施的優化策略。
注意,這里所說的商品加載數量僅作為一個范圍參考。測試顯示***理想的數量取決于你的網站情境以及行業。對于更細節導向的商品列表(大部分電子消費品、硬件、部件和配件),加載數量應該少一些。相反,測試顯示當商品列表包含更多依靠視覺審美的商品(服飾、家具、裝飾品等等)時,用戶能一次處理更多商品(對延遲加載,有很多可用的基礎性代碼和插件,其中兩個是Mika Tuupola針對jQuery的Lazy Load,以及LazyLoad XT)。
圖注:Crutchfield運用了“加載更多”按鈕與延遲加載相結合的方式。首先,默認加載20個商品;一旦用戶滾動到第10個商品,Crutchfield延遲加載另外20個商品。到達第40個商品時,用戶面前出現“加載更多”按鈕。
用以上方法,頁面能夠快速加載,因為只有很少數量的商品是***初加載完成的。更重要的是,對小型和中型品類來說,延遲加載會允許用戶在不被打斷的情況下瀏覽完整個商品列表。實際上,當用戶使用篩選功能時,對于大部分準確定義的品類來說,“查看全部”就像是可實現的一樣。對于更長的列表,用戶會遇到“加載更多”按鈕,它使得有意愿的用戶能夠很輕松地繼續瀏覽,并為用戶在滾動間隙提供了良好的休息,讓用戶很容易到達頁面底部,并讓他們有時間考慮使用篩選功能是否比繼續滾動瀏覽上百個商品要更好。
延遲加載和無限滾屏(尤其是后者)的缺陷之一是頁面高度持續加長;如果用戶把滾動條拖拽到底部,他們會到達頁面底部,但只看見底部1或2秒鐘,然后下一個商品就又加載出來了。新商品被填加到列表中,頁底被推到下面,滾動欄被拉長。在測試中,這導致了參差不齊的頁面體驗。使用“加載更多”和延遲加載的混合形式,上面的問題大體上被解決了,因為用戶跳躍一兩次后頁面就間斷了。然而,如果你要尋求完美的交互方式,考慮用單個商品的高度乘以列表頁的總行數(在“加載按鈕”出現之前)來“偽造”頁面高度吧——即便列表中剩下的商品行還沒加載完成。這個人工偽造的頁面高度能讓滾動條從頁面頂部開始就占據恰當的空間,因此它更準確地體現了頁面實際高度。這種方式也能讓用戶不用跳躍就能來到頁底。延遲加載會和之前一樣繼續加載商品——只是現在這些商品占據的是為它們預留的空間,而不是延長頁面長度。
三、在搜索結果頁使用“加載更多”
由于搜索的開放性,搜索結果頁通常比分類列表頁的商品多很多。在我們對電商網站搜索體驗的可用性研究中,搜索結果包含數百個商品并不少見,在大型零售電商網站上,搜索請求通常返回數千個商品。
此外,搜索結果是根據相關性排序的。因此,第5個搜索結果對用戶的相關程度通常比第100個要高許多。這意味著用戶在搜索的情境中不應該需要掃描100個商品——網站應該鼓勵用戶仔細查看前幾個商品。因此,搜索結果頁應該默認加載25-75個商品,并且在這類頁面無限滾屏永遠也不該被使用。(有趣的是,Etsy**的A/B測試記錄了搜索體驗中許多使用無限滾屏的例子)翻頁或者“加載更多”按鈕更適合搜索結果頁,因為這兩種形式不鼓勵用戶快速掃描大量商品,而是提醒用戶將更多注意力放在查看頭一批商品當中。實際上,由于展示的搜索結果少,延遲加載也不是一個必須項(但如果已經用在分類頁了,在這里不妨也使用)。
圖注:L.L. Bean這里使用了“加載更多”,由于結果的相關性遞減,用戶得以有一個自然的停頓(不像無限滾屏),但他們仍然有將***批加載的商品和第二批進行比較的機會(不像翻頁)。
更進一步,默認加載的商品數量可能是根據搜索結果的相關性得分進行動態調整的。大部分搜索引擎根據相關度得分對每個結果(商品)排序,并優先返回那些得分***高的結果。這些分數可以用來決定加載商品數量的動態邊界。根據網站是鼓勵用戶僅僅快速掃描前幾個商品,還是瀏覽更多商品,動態邊界增加或減少。
動態調整商品數量可以通過監測搜索結果的相關度得分突然下降的節點來實現。基于這些下降的節點就可以確定某個搜索請求應該返回的**商品數量。舉例來說,如果在前28個商品之后,相關度得分開始大幅下降,那么加載的商品數量可以適當減少來增加用戶對前面商品的注意力。如果前100個商品的相關度得分都很高,那么加載的商品數量可以適當增加來鼓勵用戶發現更多商品。
四、在移動端使用“加載更多”按鈕
圖注:由于頁碼鏈接排放的很緊密,它們經常很難點擊中。此外,移動端用戶厭惡等待頁面重加載,更傾向于避免翻頁操作。
圖注:商品列表很長的情況下,無限滾屏的形式會使新的搜索結果不斷加載進來,持續把頁底推到下面,因此用戶觸達不到頁底。
在我們持續整年的移動電商研究中,我們發現頁碼鏈接很難被準確地點擊到,因此通常會導致多余的頁面加載。而無限滾屏則被證明在幫助用戶探索很多商品時非常有效(實際上,測試用戶在提供無限滾屏的網站上滾動瀏覽的商品數量是他們在提供翻頁功能的網站的2倍多)。然而,正如前面提到的,無限滾屏讓用戶到不了頁底。在移動端的測試中,這個弊端使得一些至關重要的頁底鏈接——例如“PC端”網站、“常用問題”以及“配送”、交叉導航和類似的要素不能被用戶觸達,而用戶對能夠觸達頁底的這些鏈接都有著明確的期望。
圖注:如Lowe’s網站這樣提供一個“加載更多結果”按鈕,為用戶提供了很多無限滾屏能提供的好處,而又讓頁底可觸達。
因此,**解決方案是在列表底部有一個大大的“加載更多”按鈕。然而移動端有一些獨特的限制:
o1)、更小的屏幕尺寸
移動端屏幕比PC小得多,列表中的商品占據的屏幕空間比例相對來說很大,通常在列表顯示模式下一屏只顯示2-3個商品。因此,50個商品在移動設備上占據的視圖高度比臺式機上要高很多。從另一個角度說,數量相近的商品列表,用戶在移動設備上比在PC端需要更多的交互操作(例如滾屏)。
02)、滾屏限制
在可觸摸設備上,用戶通常只能依靠用手指拖拽和滑動完成滾屏。PC端的操作模式比這豐富得多,比如鼠標滾輪滑動(或者在觸控板上滑動)、可拖動的滾動條以及許多種鍵盤快捷輸入(上下箭頭、Page Up和Page Down按鍵、空格鍵等等)。
03)、慢速滾屏
更嚴重的是,在測試中,用戶對持續不斷地滾動商品列表展現出了更低的控制度。一方面,一些用戶因為需要不斷用手指在屏幕上拖拽,滾動的速度很慢;在這種情況下,一個僅包含50個商品的列表都需要很長時間才能瀏覽完畢。另一方面,另一部分用戶會滾動得特別快,原因是他們在快速連續的滑動操作中不小心激活了自動滾屏;在這種情況下,商品嗖嗖地從用戶眼前掠過,用戶卻看不清任何一個。
04)、JavaScript事件
**,JavaScript事件在大部分觸摸屏設備上驅動的方式意味著動態的延遲加載技術經常無法實現。JavaScript事件只能在用戶滾屏結束時開始,因此當用戶在滾屏的時候商品無法被系統取到,只能等待滾屏結束。
出于上述原因,我們建議移動設備上僅加載15-30個商品,然后放置一個“加載更多”按鈕,用戶點擊后把剩下的商品同時加載完成(而不用延遲加載)。
五、關鍵細節:通過history.pushState支持后退操作
在長達7年的可用性測試中,我們持續觀察到電商網站上,加載新頁面的技術實現方式和用戶對新頁面加載的期望并不總是匹配的。諸如覆蓋層、抽屜導航、篩選項以及AJAX加載的商品等動態加載的內容常常顛覆了用戶對后退按鈕邏輯的期望。(請查看我們對用戶對后退按鈕期望的全部研究結論)
“加載更多”的方式需要仔細考慮用戶后退的操作行為。當用戶從商品列表進入一個特定的商品詳情頁后,當他們點擊瀏覽器的后退按鈕時需要回到列表原來的入口位置,這是至關重要的。我們檢查的所有有“加載更多”按鈕的電商網站中,超過90%沒有這樣做。這必然妨礙了用戶在同一個瀏覽器標簽下,在列表頁和詳情頁來回跳轉的行為——這是一個嚴重的導航限制。
圖注:Skechers網站處理后退按鈕的邏輯問題的方法是,給用戶每次點擊“加載更多”出現的頁面都寫一個URL。這樣做的結果就是,用戶從詳情頁點擊后退按鈕后,他們會回到列表頁的正確位置。
HTML5的歷史API使我們能夠重視用戶的期待。特別是history.pushState()功能允許我們不用重新加載頁面就發起一次URL變更,從而將瀏覽器的后退操作與用戶期待相匹配。瀏覽器會記住用戶滾動到的位置,不過我們仍然需要確保當用戶回到列表頁時,之前點擊過的“加載更多”都會被默認加載。
注意,如果你沒有能夠支持合理的后退邏輯的技術資源,我們建議壓根就不要嘗試使用“加載更多”,而是保留稍差一些的翻頁模式。
六、“加載更多”不應該成為你的**選擇
雖然“加載更多”、無限滾屏和分頁模式的優劣已經被爭論很多年了,商品的加載方法不應該是大部分電商網站分配開發資源的***高優先級事項。過去7年當中,我們在絕大部分電商網站上記錄了大量嚴重的UX問題。我們挑選了這些問題中的一部分,關于它們的文章可以在Smashing Magazine上找到,包括電商搜索、分類導航、篩選、結算以及移動端體驗。這些問題中有許多對用戶體驗有同樣程度的影響,但對設計和技術資源的要求沒有開發一個完善的“加載更多”模式那么高。
這不是說加載方法不重要。它很重要,而且我們在測試中發現加載方法能夠顯著改變用戶瀏覽商品的方式。只是它不應該是大部分網站改版優化中*****先的事項,因為這些網站還有好多具有更高投資回報率和更容易實現的優化項目。“加載更多”因此應該是那些追求完美用戶體驗的網站所考慮的問題。
七、“加載更多”按鈕Vs.無限滾屏Vs.分頁
總而言之,在我們的可用性測試中,“加載更多”按鈕解決了分頁功能的問題(分頁狀態下,用戶在商品列表頁瀏覽的數量較少,并且在不同頁面之間很難進行商品),也解決了無限滾屏帶來的一些嚴重問題(無限滾屏時,用戶草草地掃描商品,而且經常不能到達頁底)。然而,只有當瀏覽器的后退邏輯被處理好,例如通過history.pushState()語句,并且實現方法根據用戶的情境合理調整后,“加載更多”按鈕才會比另外兩種形式表現得更好。具體來說,以下三種基于情境的調整是成功的關鍵:
對于分類導航來說,結合使用“加載更多”按鈕和延遲加載。將“加載更多”按鈕出現的時機設定在50-100個商品之后。
對搜索結果頁,使用“加載更多”按鈕,但是出現的時機應該是25-75個商品結果之后。理想的情況是,你能夠根據每個獨特的搜索結果列表以及結果相關度得分突然下降的節點動態調整商品數量。
在移動端,使用“加載更多”按鈕,但考慮滾屏操作和屏幕大小的限制,把它出現的時機設定在15-30個商品之后。此外,由于JavaScript事件在移動端啟動方式的問題,以及初始加載的商品數量較少,建議一次加載全部商品而不使用延遲加載。