Carousel UX, and Why the Next Card Should Peek In

Good carousel UX mostly comes down to one thing, which is that people can see there is more before they touch anything, so I design every card carousel with the next card cropped by the edge of the screen, arrows which are visibly needed, no automatic rotation and a link to the full list. On a wine shop redesign in my portfolio this month the row of wines under Explore all our wines had arrows but four cards which fitted the content column exactly, and the row read as a finished grid of four, so the arrows looked like decoration and I think most people would have scrolled straight past them. Narrowing the cards a little so that a fifth one peeked in at the edge was the whole fix, and it has been a rule in my design files since.

This post goes through why a row which fits looks finished, how much of the next card to show, and how to let people move the row without making them chase it.

Why four cards that fit look finished

A row of cards which starts and ends inside the page margins has the same shape as a grid, and a grid tells people that they are looking at everything. The arrows beside the heading are the only sign that the row continues, and small arrows at the top corner of a section are easy to miss, so the cards behind them mostly go unseen, which matches what Nielsen Norman Group found in its study of carousels on websites, where site owners could not count on people seeing the content inside them.

A card which is cut off by the edge of the screen works differently, because the eye reads the cut as a row which carries on past the edge. Apple’s guidance on scroll views uses the same cue, and Nielsen Norman Group’s later study of mobile carousels calls half-visible images at the edge a strong signal that a carousel has more to show.

How much of the next card to show

The amount of the peek matters, since a sliver of a few pixels reads as a layout mistake rather than as another card. These are the sizes which I use.

• Desktop. Four full cards and a fifth which shows a third of its width or more. On the wine shop row that meant cards of 290 pixels in place of 310, which opened a peek of 120 pixels beside a 64 pixel margin.
• Phone. One full card and the start of the next, so the second card is plainly a card and not a stray edge.
• The edge. The row runs past the page margin on the side it scrolls towards, all the way to the edge of the screen, so the screen crops the peeking card, while the heading, the arrows and any link above the row keep the page margin.
• The count. A carousel needs at least one card more than fits, so a row with exactly four cards on desktop either becomes a grid or receives a fifth card.

Material Design describes the same layout as its uncontained carousel, where cards of one size run past the edge of the screen, in its carousel guidelines, and it adds that a page which scrolls down should still offer a way to see every item without scrolling sideways, such as a Show all link, which I would add to any carousel of products or projects.

Let people move it, and only when they ask

A carousel which rotates on its own mostly works against the owner of the site. Nielsen Norman Group’s article on auto-forwarding found that rotation cuts how long each item is visible and that people tend to ignore moving panels as advertising, and web.dev’s best practices for carousels concludes that autoplay is rarely a good choice. If a client still wants a rotating banner, WCAG’s Pause, Stop, Hide criterion requires a way to pause any moving content which starts on its own and runs longer than five seconds beside other content, and the W3C’s carousel tutorial asks for a button that stops and resumes it, while the ARIA carousel pattern stops rotation when keyboard focus moves into it.

Arrows, swipes and the size of the controls

On a phone people swipe a row with a finger, and on a desktop most people use a mouse or a trackpad, so I would give the desktop row previous and next arrows beside the heading and let the phone row move by swiping. WCAG’s Dragging Movements criterion asks that anything which a page lets you do by dragging also works with a single tap or click, which the arrows cover, and its minimum target size is 24 by 24 CSS pixels, while the W3C’s carousel styling page recommends buttons of 44 by 44, which is also the smallest tap target that this website uses on a phone.

Nielsen Norman Group’s mobile study also points out that a swipe which starts at the very edge of the screen can trigger the phone’s own back gesture, so I start the row on the page margin on the left, which keeps that edge clear, and let it run to the edge only on the right, where the peeking card sits.

How this website builds its swipe row

The selected work on the home page of this website becomes one swipe row on a phone, with nine covers in columns of 300 pixels which start on the 16 pixel margin and run to the right edge of the window, so the next cover always peeks past it. It uses CSS scroll snap, which stops each swipe on a cover and which every current browser supports without any script, and a small script only lets a mouse drag the row on a desktop. The covers are in the page’s HTML from the start, as web.dev recommends, and the pictures further along the row load as you swipe towards them, so the row adds little to the first load of the page.

Where to start

I would open your own site on a phone and on a laptop and look at each carousel without touching it, and if the last card ends neatly inside the margin, that row looks complete to your visitors. Narrow the cards or let the row run to the screen edge until a third of the next card shows, add a fifth card if there are only four, switch off any autoplay, and put a link to the full list beside the arrows, which pairs well with the clear button hierarchy and the menu rules in my post on dropdown menu UX.

Frequently asked questions

What is carousel UX?

It is how easy a carousel is to notice, understand and move through, mostly whether people can tell that there are more cards, whether they can move the row at their own pace, and whether every card can also be reached some other way, such as a Show all page.

Should a carousel auto-rotate?

I would avoid it, since rotating panels mostly reduce how long each one is seen, and if one has to rotate, WCAG requires a way to pause it when it runs longer than five seconds beside other content.

How many cards should a carousel show?

On desktop I show four full cards and a third or more of a fifth, and on a phone one full card and the start of the next, with at least one more card in the row than fits on the screen.

Are carousels bad for UX?

Rotating hero carousels mostly are, but a row of cards which people move themselves works well for products, projects and articles, as long as the peek, the arrows and a link to the full list are there.

Do carousels need arrows on mobile?

A phone row can rely on swiping, but any row which the page itself moves by dragging should also offer a tap alternative, so I would keep small arrows or a Show all link wherever the row is the only way to reach its cards.