無限スクロール vs ページネーション vs もっと見るボタン — ECサイトにおける考察

Source

コンテキストによって変わる、ベストなリスト表示パターンをBaymard Instituteによる大規模なユーザビリティ調査から学ぶ。

ECサイトで商品を陳列するためのベストなUXパターンは何だろう? ページネーションもっと見るボタン、それとも無限スクロール? Baymard Instituteでは50を超える主要なECサイトにおいて、数年に及ぶ大規模なユーザビリティ調査を行ってきた。そして、デスクトップとモバイルの両方で、上記3つのデザインパターンを使って商品の読み込みなどの検証を実施した。

Webサイトに新しい項目を読み込む方法としては、古来からあるページネーション(1, 2, 3, 4 といった数字のリンク)がいまだに最も一般的な方法で、eコマースプラットフォームのほとんどが、それを基本形として構築されている。しかし私たちの行った検証結果では、もっと見るボタンと遅延読み込み(多数のアイテムがあっても、スクロールの段階に応じて順次読み込む手法)を組み合わせる方がより優れた実装であり、シームレスなUXを実現できることが判明した。一方で無限スクロールはユーザビリティに悪影響を及ぼしかねないことも分かった(特に検索結果や、モバイルにおいて)。ただし、それぞれの手法の良し悪しは当該ページのコンテキストによって変わってくるため、完全に白か黒かに分けられるものではない。

本記事では、Baymard Instituteで実施したモバイルとデスクトップ双方における、もっと見るボタン、無限スクロール、そしてページネーションのユーザビリティに関する調査結果を提示する。さらに、検索結果ページとカテゴリページでは異なる方法で実装される必要があるということを、実装の際の落とし穴や主要なECサイトの例などと共に見ていきたい。

調査結果からの気付き

ページネーション
ECサイトの商品リストとフィルターに関するユーザビリティ調査では、多くの被験者がページネーションについて不満を述べた。ページネーションには遅さを感じ、ページネーションのリンクを見るだけで、それ以降の商品リストは見る気が起きないと語る被験者も多かった。更に重要なのは、もっと見るボタンや無限スクロールを使ったWebサイトに比べると、被験者が閲覧する商品リストの総数がはるかに少なかったことだ。いい点と言えば、検索結果の1ページ目に、比較的多くの時間が費やされたことだろうか。

ページネーション
多くの被験者は、検索結果の件数を把握するために、ページネーションのリンクを見た。ただページネーションの1, 2, 3などのリンクは特定の一覧へのジャンプを容易にしているはずだが、被験者のほとんどは使うことはなかった。彼らは、もっぱら”次に進む”や”前に戻る”ボタンを使っていた。(Macy’sのユーザビリティスコアはこちら

無限スクロール
もし全ての商品を1つのページで一度に表示させると、読み込みに時間がかかり、パフォーマンスの低下をユーザーに意識させてしまう。無限スクロールを用いればユーザーにその点を意識させずに、あたかも全商品が一度にページに表示されているかのような印象を与えることができる(ただし、全商品見るユーザーはほとんどいない)。無限スクロールをうまく実装すれば、驚くほどスムーズでシームレスなUXを提供することが可能だ。ユーザーは特定のボタンなどを押す必要なく、ただスクロールさせるだけで、しかもスクロールを中断させられる事なく商品を探し続けることができる。以上から、無限スクロールを実装したサイトでは、ページネーションやもっと見るボタンを実装したサイトに比べて、当たり前だが、はるかに多くの商品が閲覧される結果となった。その反面、最初に表示された商品の閲覧時間は比較的短い。またユーザーがスクロールする際、個々の商品を見て行くというよりは、流れを止めずに全体を俯瞰する傾向があるため、無限スクロールはカテゴリ全体の広がりを素早く認識するのに理想的だと思われる。

無限スクロール
スクロールバーの長さに注目。無限スクロールのWebサイトでは、被験者は大体100以上の商品を閲覧した。これはページネーションや、もっと見るボタンを用いたサイトではめったに無かったことだ。これにより、無限スクロールは50から150の商品の表示について、非常に効率的ということが証明された。一方で、一部の被験者は個別の商品に注意を払うことなく、リストの最後までただスクロールし続けるだけだった。これはスクロールが一種の義務に転化したといえる。

また、無限スクロールは、ユーザーがWebサイトのフッターにアクセスしようとするのを妨げる。これは無限スクロールの設計課題の1つと言えるだろう。ユーザーがリスト最下部に移動しようとすると検索結果が継続的に読み込まれてしまうため、一瞬フッターを確認できたと思っても、すぐに次の結果セットが表示されてフッターを画面から追い出してしまうのだ。リストの項目が多い場合(検索や上位レベルのカテゴリなど)、フッターを見ようとするユーザーの動きは実質的に邪魔され続ける。フッターには、重要なヘルプページやクロスナビゲーション、インスピレーションを提供するコンテンツやカスタマーサポート、出荷や返品などの情報が含まれていることが多いため、これは大きな課題となり得るだろう。

もっと見るボタン
テストされたWebサイトのうち、もっと見るボタンを使用したサイトはわずかだったが、それらは被験者に好意的に受け入れられた。実際のところ、米国のトップ50のECサイトをベンチマークすると、「もっと見る」アプローチを使っているのは、たったの8%しかない。「もっと見る」は、次に開くページをどれにするかユーザーに選択を強いることがない。非常にシンプルで単にもっと結果を見たいかと尋ねているだけだ。これによりインターフェイスも非常にシンプルなものとなる。また、追加項目をオンデマンドで読み込む時の認知負荷は、恐らく最少クラスだろう。大体の被験者は、ページネーションのリンクを使ったサイトよりも多くの商品を閲覧した。一方で、商品一覧を追加表示するには依然として能動的な動作が要求されるため、無限スクロールを使ったサイトよりも、表示された項目を注意深く読むユーザーが多く見られた。

Urban Outfitters
Urban Outfitters
American Eagle Outfittersのようなもっと見るボタンがあるWebサイトでは、ユーザーはページネーションのあるWebサイトよりも多くの商品を調べ、一方で無限スクロールのサイトの時ほど素早くスクロールはしなかった。更に、今見ているリストに追加の商品が入ってくる形になるので、商品の探索がはるかに容易であることが観察された。(American Eagle Outfittersのユーザビリティスコアはこちら

「もっと見る」や無限スクロールを実装する利点の1つは、商品のリストが入れ替わってしまうのではなく、リストに商品が追加されるという点だ。「もっと見る」を用いると、商品の比較がより容易になる。統合された唯一の商品リストにより、ユーザーにとっては、どの商品を見るのがベストかという判断が容易になり、それが結果的に全体の商品の閲覧率の向上につながる。

ここまで読んで、読者の皆さんはどの読み込み手法を使うべきだと思うだろうか。結論としては、全ての場合に当てはまる完璧な手法はないことが分かったが、「もっと見る」をコンテキストに応じて使い分けるのが良さそうだ。この記事の残りの部分では、その3つのコンテキストについて説明していこうと思う。

  • カテゴリページの場合は「もっと見る」と遅延読み込みを組み合わせる。
  • 検索結果ページの場合は理想的には、関連スコア順の結果リストと、検索結果件数を表示。
  • モバイルの場合はもっと見るボタンを使う。ただし読み込む量はやや少なめ。

※これら結果はECサイトをテストして得られたものであり、他のタイプのサイトでは結果が異なる可能性がある点はご了承いただきたい。

コンテキスト毎のベストプラクティス

カテゴリページの場合

ECサイトのトップページとカテゴリページに関するユーザビリティ調査から、カテゴリページで新しい商品を読み込む際の最適なソリューションは、もっと見るボタンと、遅延読み込み形式による無限スクロールのちょうど中間辺りに位置していることが分かった。どういうことかと言うと、最初のページ読み込みで10から30商品を表示し、遅延読み込みでさらに10から30商品を追加。その後遅延読み込みを続け、50から100商品が表示される頃に、もっと見るボタンを表示させるというやり方だ。そしてボタンをクリックするとまた10から30商品が追加される。もっと見るボタンを表示させる、50から100商品の間の「決め」は、どのタイミングでユーザーの割り込みを挟むかという事で、遅延読み込みの10から30商品の間の「決め」は、単純に読み込み時間とサーバ負荷のパフォーマンスを鑑み最適な値を決定する。

なお、読み込む商品数の最適解は、Webサイトのコンテキストや業種によって異なることが明らかとなったため、サイト毎に最適化が必要だ。性能重視なコンテキストの場合(電子機器、ハードウェア、部品や消耗品など)、低めの範囲を使った方がいい。反対に、ビジュアル重視なコンテキストの場合(アパレル、家具、装飾品など)、高めの範囲にしても十分にユーザーは対応できるという結果が得られた。

ちなみに遅延読み込みに関しては、数多くのコードやプラグインが公開されている。代表的なものはMika TuupolaのjQueryプラグインLazy LoadLazyLoad XTだ。

Crutchfield
Crutchfieldでは、遅延読み込みともっと見るボタンが実装されている。まず20商品がデフォルトで読み込まれ、10個目の商品までスクロールすると、追加の20商品が遅延読み込みされ、その下にもっと見るボタンが表示される。(Crutchfieldのユーザビリティスコアはこちら

この方法だと、最初に読み込まれる商品が非常に少ないため、ページを素早く表示させることが可能だ。更に重要なのは、中小規模のカテゴリでは、遅延読み込みによって中断されることなく、あらかたの商品を確認できてしまうことだ。つまり、ある程度数が絞られている状態では、”View all(全て表示)”になっているのと似た状態になる。一方、リストがより長い場合はもっと見るボタンが表示されるので、ユーザが望めばそれを使って簡単に閲覧を続けられる。加えてユーザーはスクロールから健全な形で解放されるので、フッターへのアクセスも可能であるし、あるいはその時点でスクロールを続けるべきか、フィルターを適用するべきかといった選択の余地も与えられる。

遅延読み込み、特に無限スクロールの弱点の1つは、ページの高さが断続的に長くなることだろう。ユーザーがスクロールではなく、スクロールバーなどで一気に下へ移動すると、フッターが表示されるものの、1~2秒経つと追加で読み込まれた次の新しい項目がリストに追加され、フッターは下に追いやられ、スクロールバーは延長する。テスト中、これでページがガクガクと動くような問題が発生したが、「もっと見る」を組み合わせれば、合間に小休止を入れられるため、そのほとんどは解決された。ただし、もし実装を完璧にしたいのであれば、仮に商品が全て読み込まれていない場合でも、次のもっと見るボタンまでのページの高さを計算するなどして、空白の行をあらかじめ用意しておけば、追加読み込みによるガクつきを回避できる。さらに、遅延読み込みによる、フッターが一瞬見えるけど追加読み込みで見えなくなってしまうというアクシデントも回避できるようになる。

検索結果ページの場合

検索は自由度が高いため、カテゴリページに表示されるリストよりもはるかに多くのアイテムが並ぶ傾向にある。ECサイトにおける検索に関するユーザビリティ調査でも、検索結果が何百に及ぶことはさほど珍しいことではなかったし、大量の商品を扱うWebサイトでは、検索クエリはごく当たり前に何千もの結果を返す。

また、検索では、結果は関連性によってソートされるため、5個目のアイテムは100個目のアイテムよりも一般的に関連性が高い。これはつまり、ユーザーは検索時に100個以上の商品を見る必要がないことを意味している。むしろ、先頭の方のアイテムを慎重に吟味した方が有意義だろう。従って検索結果では、デフォルトで25から75程度のアイテムのみを表示すればいいということになる。一方で無限スクロールは使用するべきではない。Etsyの有名な無限スクロールのA/Bテストにおいても、検索のUXに重大な影響があるとして実証されている。それよりも検索結果の場合には、ページネーションやもっと見るボタンを使った方がいい。なぜなら、両者ともに、大量の商品を素早く見るような構造ではなく、最初の結果セットにユーザーを集中させるような仕組みを持っているからだ。遅延読み込みについては、表示すべき結果数はそれほど多くないので必須ではない。ただしカテゴリページ用に既に開発・実装済みであれば、ここで再利用してもよいだろう。

L.L. Bean
L.L. Beanの検索結果では、関連性に従ってソートされているので、もっと見るボタンが現れる頃には関連性が低くなっており、ユーザーにとって自然な形で中断が入る。さらにページネーションでは成し得ない、最初の結果セットと2番目のセットを同一画面で比較が可能だ。(L.L. Beanのユーザビリティスコアはこちら

では、いくつのアイテムを初期表示として表示するのが良いか。理想的には、検索結果の関連性スコアに基づいて、しきい値を動的に調整するのが良いだろう。ほとんどの検索エンジンは、それぞれの結果を関連性スコアでランク付けし、最も関連性の高いものを最初に返している。このスコアを使ってしきい値を動的に決定すれば、ユーザーが最初の数件の検索結果のみを見れば良いのか、あるいはより幅広い項目を閲覧した方が良いかに準じて、読み込む商品数をコンテキストに合わせて増減することができるようになる。

より細かい話をすると、そのしきい値は関連性スコアの連続を見ていくと検出できる。ある箇所で急激に低下する箇所がそうだ。この低下に基づいて、特定の検索クエリに対して返される結果の最適な数を決定すればよい。例えば、関連性スコアが最初から数えて28個目以降で急激に低下し始めた場合、読み込む商品数を減らせば、それ以前の商品にユーザーの焦点を集めることができるだろう。反対に最初の100項目の結果がどれも非常に高い関連性スコアを示す場合、読み込む商品数を増やせば、より広範に比較検討してもらう事が可能となる。

モバイルの場合

mobile toysrus
ページネーションでは、リンクが密接して配置されるため、正確に操作することが難しい場合が多い。更にモバイルユーザーはページの読み込み時間を嫌うため、ページネーションを避ける傾向にある。(トイザらスのユーザビリティスコアはこちら

mobile endless scrolling
長い商品リストを無限スクロールさせると、常に新たなアイテムリストが追加で読み込まれるため、フッターにアクセスできない。

我々の1年に及ぶモバイルECサイトにおけるユーザビリティ調査では、ページネーションのリンクは正確にタップするのが難しいし、一般的に新規のページ読み込みが発生する。一方で無限スクロールは、被験者にとって多くのアイテムを検討するのに非常に効果的であることが判明した。実際、無限スクロールのサイトでは、被験者はページネーションのWebサイトと比べて2倍以上の量の商品をスクロールして表示していた。しかし前述したように、無限スクロールのサイトではフッターへのアクセスが難しい場合がある。モバイルテストの間、フッターに表示される”PC版を表示”や”FAQ”、”配送”や一般的なクロスナビゲーションなどの重要なリンクに関して、被験者はそれらがフッターに位置していることを明確に分かっていながら、なかなかアクセスできないでいた。

Lowe's mobile
Lowe’sで使用されているもっと見るボタンは、
フッターへのアクセスを確保しながら、無限スクロールの利点の多くを提供している。(Lowe’sのユーザビリティスコアはこちら

以上から、モバイルにおける最善のソリューションは、商品リストの最後に大型のもっと見るボタンを配置することだろう。しかしモバイルには、いくつかの固有の制約がある。

  • 小さい画面の制約
    モバイル画面は非常に小さく、アイテムリストが画面の大半を占めるにも関わらず、一般的なリストビューのレイアウトでは3~4項目だけが表示される。従ってモバイルデバイスでは、50個の項目があるとすると、それらはデスクトップコンピューターに比べて、よりスクロール量が多いという事であり、つまりユーザーは、デスクトップ上で同等の商品リストを見る場合に比べて、モバイルデバイス上ではより多くの操作を強いられるということだ。

  • 操作方法の制約
    タッチデバイスでスクロールする場合、ユーザーは通常、指をなぞってスワイプする。一方デスクトップでは、マウスのスクロールホイールやトラックパッド、ドラッグ可能なUIスクロールバー、あるいはキーボードの上下キーやPageUp/Downキー、スペースバーなど、様々な入力方法を選ぶことができる。

  • スクロールの制約
    商品リストを連続的にスクロールするのに課題があることも判明した。一部の被験者は画面上で連続的に指をドラッグできずに、非常にゆっくりなスクロールとなっていた。この場合、たとえ商品が50品目程度だとしても、閲覧するのに長い時間がかかるだろう。一方、素早くスワイプできる人もいるが、急激にスワイプすることで意図に反して慣性スクロールが機能することがあり、そうなると多くの商品を見逃してしまうことに繋がる。

  • JavaScriptイベントの制約
    タッチデバイスにおけるスクロールイベントの発生条件的に、動的な遅延読み込みが難しい事が分かる。JavaScriptイベントは、ユーザーのスクロールが終わってからのみ発生するため、ユーザーがスクロールしている間は結果リストを取得できない。スクロールが完全停止するのを待った後、追加読み込みがされる形のなる。

これらの理由から、モバイルデバイスでは、まず15から30商品のみを読み込み、その下にもっと見るボタンを配置し、遅延読み込みは利用せずに一気に読み込むことが望ましい。

戻るボタン問題

ECサイトにおけるページの追加読み込みや新規ページへの遷移について、技術的な実装面と、ユーザーの期待とがしばしば一致しない事を、計7年にも及ぶユーザビリティテストの中で観察してきた。オーバーレイ表示やアコーディオン、フィルター、AJAXが組み込まれた商品などのコンテンツを動的に読み込むことで、ユーザーが想定する戻るボタンの動作が妨げられることがよくあるのだ(ユーザーが抱く戻るボタンへの期待に関する完全な調査結果はこちらを参照)。

「もっと見る」を実装する際は、戻るボタンの挙動について慎重に検討する必要がある。ユーザーが商品リストから特定の商品ページに進んだ場合、ブラウザの戻るボタンをクリックすると、リストの同じ場所・スクロール位置に戻ることが重要だ。私たちはECサイトの中でもっと見るボタンを持つサイトをベンチマークしたが、そのうちの90%以上はそれをうまく実現できていなかった。これは、ユーザーがブラウザの同一タブ内で、商品リストと商品ページの間を行ったり来たりするのを必然的に妨げるもので、ナビゲーションの大きな課題となる。

Skechers
Skechers
Skechers
Skechersでは、もっと見るボタンをクリックする度にURLを書き換えることで、戻るボタン問題に積極的に取り組んでいる。その結果、商品ページで戻るボタンをクリックすると、ユーザーは商品リストの正しい位置に戻ることができる。

これに対処するには、HTML5のHistory APIを利用することでユーザーの期待に応えることが可能だ。具体的にはhistory.pushState()関数を利用する。これによってページを再読み込みすることなくURLの変更を呼び出せるため、ブラウザの戻るボタンの挙動をユーザーの期待に合わせることができるようになる。ただしブラウザはユーザーのスクロール位置を覚えてはいるが、完璧に元に戻すには、「もっと見る」によって追加されたアイテム全てがデフォルトで読み込まれるように対処しなければならない。

なお、戻るボタン問題をちゃんと解決せずに「もっと見る」ボタンを実装するくらいなら、ページネーションモデルを使った方がマシだろう。

もっと見るボタンの実装が最優先か?

無限スクロール vs ページネーション vs もっと見るボタンについては、数年前から議論されてきた。しかしアイテムの読み込み手法は、EC業者が開発リソースを費やす最優先項目であってはならない。

過去7年間にわたって、私たちは、ほとんどのECサイトにおける重大なUXの問題を文書化してきた。これらの問題を扱った記事については、Smashing Magazineの過去のリストから参照可能で、その中にはECサイトの検索カテゴリナビゲーションフィルタリングお会計モバイルエクスペリエンスに関するものなどが含まれる。これらの問題はどれも非常にインパクトの大きいものだが、実は、ちゃんとした「もっと見るボタン」を実装するよりもはるかに少ないリソースで対応できる場合が多い。

もちろん、読み込みの手法の改善が重要ではないというわけではない。それは重要なものだし、検証の結果、商品のナビゲーション体験を大きく変えられるものであることも分かった。安易に最優先事項にするべきではないというだけだ。多くのWebサイトにとっては、少ない投資でよりよい結果をもたらしてくれる他の問題が数多く存在する。「もっと見る」への投資は、UXの完成度を追求する段階に取っておくべきだろう。

まとめ

ユーザビリティテストの内容をまとめると、もっと見るボタンはページネーションが抱える問題(商品リストの閲覧される割合が少ない、ページをまたぐ検索結果の比較が困難)を解決し、無限スクロールで見られたいくつかの問題(ユーザーが表面的に商品をスクロールしてしまう。フッターにたどり着けない)も解決した。

ただし、もっと見るボタンを利用する際にはブラウザの戻るボタン問題が発生する。history.pushState()などを用いて対処する必要がある。

また、ユーザーのコンテキストに合わせて適宜実装されることが理想形だ。特に次に挙げる3つのコンテキスト調整が、良好なパフォーマンスを発揮する鍵であることが確認された。

  • カテゴリページの場合:
    もっと見るボタンと遅延読み込みを組み合わせて実装する。もっと見るボタンを表示するまでのアイテム数は50から100項目で、業種に合わせて設定する。

  • 検索結果の場合:
    もっと見るボタンを使用するが、しきい値は25から75項目に抑える。その数値は、それぞれの検索結果毎に、結果の関連性スコアの低下に基づいて、動的に調整することが望ましい。

  • モバイルの場合:
    もっと見るボタンを使用する。ただしスクロールや画面サイズに問題があるため、しきい値は15から30項目とする。更に、JavaScriptの技術的条件やしきい値の低さを考慮し、遅延読み込みではなく一度に全ての商品を読み込む形とする。

より詳細なレポートと93のガイドラインはProduct Lists & Filtering Usabilityからお買い求め頂ける。