Carousels are declining in popularity on e-commerce sites, especially on the homepage. Our most recent UX benchmark reveals that only 28% of the top US and European e-commerce desktop sites have a carousel — down from 32% when we measured it in 2016 and 52% in 2013.
While our large-scale usability testing reveals that users generally like the large imagery of carousels, a homepage carousel can cause more harm than good if the inherent serious usability pitfalls aren’t addressed. In short; we do find that homepage carousels can work with users, but in practice almost all carousels don’t, and the list of detailed requirements is long.
Indeed, our UX benchmark reveals that only 41% of the sites that have a homepage carousel have an implementation that’s largely free from usability issues.
Furthermore, during our usability testing we also observed an alternative homepage design pattern that technically is vastly simpler to get right than a perfectly implemented homepage carousel and that performs well with users.
In this article, we’ll discuss the test findings from our e-commerce Homepage & Category and Mobile usability studies related to homepage carousels. In particular, we’ll discuss and show our test findings on:
If we set all the commonly observed and quite severe website usability issues aside for a second, we do find, that if implemented with great care, a homepage carousel can be a useful way to promote features, offers, and product-finding wizards. Mainly as many users are enticed by the typically large images and autorotation helps expose a variety of content without cluttering up the entire homepage.
Carousels therefore can perform decently — as long as the implementation itself and carousel content is crafted very carefully (most aren’t).
That said, we’ve observed in testing a well-performing alternative to homepage carousels that’s technically vastly simpler, and which can be employed on both desktop and mobile sites. This alternative is to simply use static content sections scattered throughout the homepage in combination with featured categories.
This static content sections design alternative relies on users simply vertically scrolling the webpage. It’s a vastly simpler UX design, offering a more ingrained web interaction than interacting with a site-specific carousel.
Therefore, before implementing a carousel on the homepage, consider whether it may be better to simply use static content sections — and avoid the headaches that can occur when trying to implement and maintain a homepage carousel perfectly. For most e-commerce sites choosing the static content sections and then spending the tech resources a carousel implementation would have required on other UX issues will be a better tradeoff.
Furthermore, a carousel is never better than its content — if the content isn’t relevant, well-curated, high-quality, and mobile optimized, the experience will never be good. Additionally, our usability testing revealed that carousel content can mislead users as well if it’s not carefully chosen — to the extent that some users misunderstand the type of site they’ve landed on.
Therefore, another requirement when deciding whether to implement a carousel on the homepage is to ensure there’s high-quality content for the carousel slides (although static content sections will suffer from poor content as well).
If you, or someone else in your organization, have a very strong preference for using a homepage carousel, and also have the needed resources, then read the rest of this article, as the rest will outline the 9 requirements for making homepage carousels perform ok that our large-scale mobile and desktop usability testing have revealed:
In general, on desktop sites autorotation of slides is a very good idea as it helps spread exposure across slides and clarifies that it is indeed a carousel and not a single static homepage banner.
On mobile sites, however, the story is different. The key difference between mobile and desktop sites, when it comes to autorotating carousels, is the lack of mouse hover on mobile.
On desktop a user’s intentions can be inferred when they’re hovering a carousel image with their mouse cursor — that is, it’s very likely that they’re reading the slide content and we can therefore pause the autorotation. On mobile sites, however, the lack of a hover state means this crucial insight into likely user intent can’t be gleaned.
Consequently, during mobile testing users viewing content in an autorotating carousel were often distressed to have the slide change before they’d finished reading. Or, worse, some users attempted to tap a slide to learn more about what was featured — only to have the slide change at the last second, resulting in an unintended detour to a random landing page.
When this detour is noticed by users it’s often “just” an unnecessary frustration, as nearly all users during testing quickly recovered.
However, for the smaller sub-group of users who do not notice it, it will result in these users misunderstanding the content they view after they’ve tapped the carousel slide, as the content is likely to not seem very relevant to the slide they tapped.
Since there’s currently no way to technically avoid such untimely slide changes, carousel autorotation should be avoided on mobile sites. The downside of a carousel that abrupt most mobile users reading a slide, and causing some users to also open a wrong slide, far outweighs the upside of spreading exposure across the carousel’s slides.
This in practice means that mobile carousels are deprived of their main benefit (providing exposure to a variety of content through autorotation), and designers and managers have to always assume that all mobile carousel slides, beyond the first, will in practice never be viewed by the vast, vast majority of mobile users.
As on desktop sites, static context sections can be considered as a design alternative to a carousel, especially since autorotation should be avoided. If the carousel design must be implemented, then the carousel should be manual, and it should adhere to the UX principles discussed below (ignoring the design requirements for autorotation, of course).
If it’s determined that a homepage carousel is still the preferred choice compared to using static content sections, whether on a desktop or mobile site, then it’s important to get the following 3 UX requirements right when implementing a homepage carousel.
Note: these requirements are completely platform agnostic and apply equally to desktop and mobile sites.
Most users won’t see all the slides in a homepage carousel, even if it autorotates. They simply don’t stick around the homepage for that long, and certainly not at the top of the homepage.
During testing, users would typically click onto another page or scroll past the carousel long before a full rotation of the slides had commenced. And that was in the case of autorotating carousels — obviously “fully manual” carousels only reveal the first slide until users decide they want to see another slide.
This means the sequence of the slides in the carousel is incredibly important, as the initial slide will get vastly more exposure than later ones.
(Tip: see our article “42% of Mobile Homepages Risk Setting Wrong Expectations for Their Users” for more on how users generally behave when landing on a homepage)
Beyond the initial slide getting the most exposure, it can be assumed that some users won’t see any slides.
During desktop (and especially during mobile) testing, many users immediately embarked on a product-finding strategy (e.g. using search, opening the main navigation, etc.) sometimes before the page had even finished loading. Consequently, these users likely never saw the carousel content.
Additionally, there’s a high risk of some carousel slides suffering from banner blindness: users skipping the carousel content, despite its prime placement, simply because it resembles an ad.
Therefore, vital site features should never be accessible only from a carousel slide, given that many users will never see it.
For example, a product finder should never be linked to only from a carousel slide. Instead, it should also have a permanent link in the navigation or a block on the homepage, as the product finder slide in the carousel won’t be seen by a large number of users, especially if it’s not the first slide in the carousel.
Having carousel controls (which for most sites are indicator dots) that are highly visible is crucial. Otherwise, it can be as bad as not having them in the first place, as some users will simply not know they’re there.
Others who spot the controls may have difficulty interacting with them if they have small hit areas.
Attention should be paid to both the size of the dots and whether they’re visible when overlaid on top of the slide content. As the carousel slides are dynamic and will change over time, testing for high-contrast should be part of the slide content creation quality assurance process, or automated. If the dots often tend to fade into the background imagery consider separating the dots from the slide content and placing them in their own section directly below the slides.
Lastly, in addition to indicator dots, consider also using arrows in the left-hand and right-hand side of the image. The next and previous arrows have the upside of being simpler to understand for more novice users.
Carousel slides should autorotate on desktop sites. However, there are three implementation details specific to autorotation that must be adhered to to ensure a well-performing autorotation.
When slides autorotate too quickly, users feel they have too little time to be enticed by the slide and properly evaluate the slide they might find interesting.
Conversely, if slides change too slowly, users grow impatient if the active slide doesn’t grab their attention and move on.
Depending on how much text the slides include, a good rotation time often seems to be around 5–7 seconds for slides with just a header and a few tags or labels, while more text-heavy slides may demand as much as 10 seconds.
When the user hovers the carousel with the mouse cursor, autorotation should pause so the user can focus on the slide for as long as they’d like, and, more importantly, so the slide doesn’t change just as the user decides to click.
During testing, carousel slides were often observed changing just milliseconds before a subject clicked — causing the wrong page to be loaded. Obviously this is a frustrating experience, and, in some cases, it can be downright harmful if the user doesn’t realize what happened and instead begins browsing a completely irrelevant page until they either start over or abandon the site.
It is therefore absolutely critical to pause the slides on mouse hover — an important feature currently missing from 18% of all benchmarked sites that have a homepage carousel (making it no wonder that most report poor performances on their carousels implementations).
The autorotation can begin again once the user’s cursor leaves the carousel if the user hasn’t otherwise interacted with the carousel — after all, the hover could just be temporary, with the user moving the mouse across the screen to get to another element on the homepage. In these cases, starting the autorotation again helps spread exposure across the slides, which is typically desirable.
However, we observe an exception to restarting the autorotation.
If the user has interacted with the carousel beyond hover (e.g. actively changed a slide), the autorotation should be permanently paused — even when the user isn’t hovering the carousel.
When the user has actively changed the slide by clicking the “next” or “previous” buttons or slide indicators, the selection is likely to be intentional and should not be changed just because the user decides to check out other parts of the homepage (before potentially returning to their selected slide).
For mobile sites, a manual carousel should be implemented instead of an autorotating carousel (if not just using static content sections). However, we observe that are an additional three mobile-specific design implementations that must be adhered to, to ensure a well-performing manual carousel on mobile.
In general mobile users have come to expect to be able to use mobile gestures — for example, the “swipe” gesture to change to the next slide — when interacting with websites on mobile devices.
This doesn’t mean traditional carousel controls such as “next” or “previous” buttons and slide indicators can’t be implemented, but testing showed that these should be provided in addition to supporting the swipe and pinch gestures.
We frequently observe, when auditing mobile sites that feature a carousel, that the carousel artwork is reused directly from desktop.
This isn’t a major problem so long as one is careful in ensuring that any text in the slides remains legible when scaled all the way down to a tiny mobile screen held in portrait mode. Ideally any text in the carousel slide is real HTML text and not embedded in the image (this is typically also better for accessibility and SEO).
In general, users tend to have less patience for slow-loading content on mobile devices.
This should be kept in mind when considering what content to include in carousels as users will quickly lose patience with content that takes more than a second to load (e.g. highly graphical or animated content).
As one user during testing put it while waiting for a page to load, “It’s just slow now. [Tapping fingers.] I don’t know whether that is my internet connection or my phone or whether it’s the website. So, who do I direct my impatience to? At this stage I would normally go okay. I’d go ‘no’ and go out of the website and go on to something else…the website should be faster…it’s bad for me personally because I just don’t have the patience…if it was going on too long, I would just go on and search for them somewhere else.”
In the end, despite some users responding well to the large imagery found in carousels, they often end up doing more more harm than good due to the many nuances and implementation required to achieve a decent carousel performance. Again, even among the largest e-commerce sites, our benchmark reveals that of the 28% of sites that still use a carousel, 41% of the implementations have major usability issues.
To sum up, desktop and mobile sites must both adhere to the following 3 carousel implementation details:
Desktop sites, with autorotating carousels, must adhere to the additional 3 implementation details:
Finally, mobile carousels should be manual (they shouldn’t autorotate), and must adhere to 3 additional implementation details:
If adhering to these 9 implementation details across desktop and mobile sites is too difficult or resource intensive, we recommend implementing the simpler, but well-performing, static content sections on both the desktop and, especially, the mobile site.
This article presents the research findings from just 1 of the 580+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” e-commerce navigation experience.
Join 25,000+ readers and get Baymard’s research articles by RSS feed or e-mail:
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
Again, another disappointing article. Not that your guidance isn’t good IxD guidance, but you don’t deal with the bigger issues these things bring. Performance, banner blindness, and the fact that research has shown again and again most people don’t interact with them. The poor conversion rate alone would (I think) get you guys to dissuade the use of them.
Hi Chris, as stated in the article if the content is no good (ad-looking) the carousel experience never can be either. Most carousels are in practice poorly implemented, and yes these doesn’t perform well. (e.g. the one in the NNG study you indirectly link to auto-rotates seemingly without pause – as we found in our studies as well, this will never ever work
That doesn’t mean they can’t be valid in select cases – with good content and proper attention to details. (a supplementary carousel of large bespoke imagery, article content, etc).
But again, as stated in the article, they’re not supposed to be the singular navigation path to any important features, etc. (which also align with the NNG findings you indirectly link to).
In can see how this article may at first look like a condolence of carousels. It’s not, is more a letter of warning of the many things that can go wrong – but also outlines, and confirm, that if enough attention is paid to details carousels can work for select purposes.
In the spirit of “It depends” in the UX profession, we should not be dismissing carousels outright at a conceptual level. Done right they can be highly engaging even if, as you point out, people don’t directly “interact” with them by clicking through.
However unfortunately Christian whilst all the points you’ve raised in your article are valid, I wouldn’t rate them as the highest priority when it comes to designing a good carousel. Content first. Get the content right and fail half the requirements you stated and it can still whoop a carousel that is implemented technically correctly as per your requirements but just doesn’t expose engaging content.
Hi Nathanael, we agree, as Jamie stated in the article intro:
“It should be stressed that the focus of this article is on the design and interactive features of homepage carousels and not their content. In other words, for the purposes of this text we will assume the content is good and instead investigate how to make the carousel features user-friendly. If the content of a carousel isn’t relevant, well-curated and of high quality the user experience will be bad, regardless of how easy it is for the user to interact with.”
Any slightly seasoned UX professional should already know what was covered in this article. How about some new data we could use when trying to improve the content with creative & marketing. I’m curious about things like number of CTAs, imagery vs graphics, etc.
Hi Ron, completely agree that much of UX findings (in general) should already be known. But when the majority of carousels found at multi-million dollar e-commerce sites suffer from basic usability issues there’s still a clear need for improvement.
For example something as basic as auto-pause of the carousel on mouse-hover are missing on 22% of the carousels found at top 50 US e-commerce sites (all above 100million in sales).
If we get the opportunity for a more in-depth study specifically of the type of carousel content which work the best we’d be sure to publish an updated article. Thanks for the suggestion.
Auto-rotate on mobile can be appropriate in cases where the content is short, e.g. a background image and a few words of text. This is what IGN’s mobile site does (ign.com) and I personally have no usability issues with that approach. When I open the site, I first look at the carousel and let it auto-rotate all its entries. Then, I move down the page normally.
auto rotate is too slow some times
Thanks for interesting insights!
I’m wondering if you can provide some reference/statistics for slider timing test: “5-7 seconds proved appropriate during test”
The article does not consider the users reading speed, cognitive abilities, or any disability. What if a mouse can’t be used? Consider an affordance that allows the user to control rotation.
It mentions reading speed a few times. People, without cognitive disabilities, had plenty of trouble reading carousels. However I agree there should have been some mention of :focus.
And while this isn’t an accessibility-oriented blog, I think some mention of WCAG (2.2 timed media: http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-pause) guidelines could have been mentioned: that users always get an obvious method to pause/stop the carousel (if auto-running). The suggestion in the article that the auto-carouselling stop once the user begins to interact by intentional clicks already covers user-controlled speeds, if we assume these carousel all have proper controls and not merely changing clickable slides.
You could add “focus” to the “hover” rules— any carousel built decently needs to have not only separate linear controls (like left/right or forward/back) and position (dots or similar showing how many slides total and where in the slide deck you are now) but these things need to be keyboard-focusable without trapping. A user who lands their focus on a next/prev button OR a position button (if it’s a button, and they should be selectable if users want to jump to a slide non-linearly) should stop a carousel similar to mouse hover.
Since many browsers leave “focus” behind on clicked elements, this also doesn’t conflict with “stop the animation once the user has interacted”.
Good tip. Any and all indications of user interaction with the carousel should be utilized :)
This is a wonderful article primarily because it provides strong opinions and a sufficient do-this, don’t-do-that checklist for everyone to follow that would definitely make websites better for the majority of users. The people who use sliders/carousels need to hear this, and the people trying to talk to the people using carousels need to have something categorical to show them to back up the argument. Go Baymard!
i read this article but i didn’t get when the carousel auto rotate is stop because an active user interaction when it should resume?
It would go to manual click and go to next and or perhaps some code to restart after some time. This is why it’s important not to put critical information in a slider type rotator. You run the risk of content not seen for a number of reasons.
This article is a joke, there are so many mistakes in that example images, i can’t take it seriously.
Pottery Barn’s black text on that image? REALLY? I know, UX isn’t about design, but damn that is a easy no no.
Hi, do note that almost every image in this article depicts what not to do. They depict issues observed in testing, hence all the image captions below these images start with a big red X.
I found the article really informative. Thanks!
I have seen sites like “microsoft.com” and “fca.org.uk” give users the option of pausing and playing the autorotating carousels manually.
I am curious to know how this option plays out in major e-commerce sites. How often do users interact with these buttons and what is their impression of these buttons? Do they even notice them?