Modals provide a way of presenting content with reduced cognitive load and better loading and rendering performance compared to traditionally navigating to a new page. In fact, a modal can be likened to a page within a page.
Cognitive load is reduced by presenting only the necessary content (so no template elements such as headers and footers), and performance is increased because there’s less content to render and also because there’s no rerendering of assets that have already been rendered.
However, with such limited screen space on smaller handheld devices, modals can be difficult to use. This is why a different UI pattern, the bottom sheet, has become far more popular on smaller handheld devices.
In this article you’ll learn what a bottom sheet is, when and why they’re useful, and how to make them as usable and as accessible as possible, resulting in a great user experience.
Bottom sheets are a type of modal that, when open, sits at the bottom of the screen, filling the entire horizontal space. While traditional modals are designed to appear in the center of the screen (not touching any of its sides), bottom sheet modals touch the bottom, left, and right sides of the screen:
Aside from the benefits already mentioned that all types of modals have, bottom sheet modals get two extra benefits.
Firstly, traditional modals aren’t resizable or scrollable due to how tricky it is to design visual cues and usable mechanisms for these interactions. However, with bottom sheet modals, this is far easier, making them particularly useful for modals with a lot of content.
Secondly, because bottom sheets appear at the bottom of the screen, they’re already near the user’s thumbs, which makes them easier to interact with:
That is, unless the user’s thumb is already near the top of the screen, in which case you’ll want to consider using a top sheet instead — same thing, but at the top:
Like with all interactions, it’s important that users are able to engage with bottom sheets easily and quickly. Keep reading to learn more about bottom sheet UX.
It’s important to think of bottom sheets (and all modals in fact) as pages within pages. This means that they should have a self-contained heading hierarchy, just as they would have if they were loaded as traditional pages. This helps screen readers to understand the bottom sheet’s content structure correctly while not disrupting the structure of the “background” content.
To ensure that the bottom sheet has as much breathing room as possible, use all of the horizontal space. This practice is so common, you might assume that it’s a requirement, and even though it’s not, it’s definitely something that you’ll want to do. More space is never a bad thing:
Sometimes, the bottom sheet modal itself can be dynamic/interactive — Google Maps is an example of this, where the bottom sheet provides information about specific locations and the background shows the map, which remains interactive and functional.
In addition to being scrollable (because there’s a lot of information), the bottom sheet is also resizable, and this is best indicated with a horizontal line near the draggable edge. Without this, users might assume that it’s not resizable:
Scrolling is somewhat implied by the information being cut off by the viewport, so we don’t really need to worry about adding a visual cue for that:
However, both of these interactions can be quite finicky and therefore frustrating (as are most touch interactions), so avoid them if they’re not necessary. For example, in the image below, are we scrolling, clicking, or dragging? Sometimes, devices just get them all mixed up:
This isn’t possible with Google Maps though, as their tool obviously requires a functional background — an interactive map of all things — in addition to a functional bottom sheet, and their content obviously warrants scrolling.
One thing that they should’ve avoided though is the bottom sheet’s awkward resize snapping, especially since the component is extremely dynamic and interactive already. Snapping is inherently bad because there aren’t any visual cues to communicate what’s going to happen and to what degree, not to mention that if the bottom sheet is scrollable then the two interactions conflict and result in unpredictable behavior.
Thankfully, most bottom sheets are fairly simple and have a fixed height, but there are a couple of things to keep in mind.
Firstly, some bottom sheets will need a close button. Modals with binary actions (e.g., buy/cancel) won’t because the cancel action acts as the close button, but informational bottom sheets and other bottom sheets without cancel actions will need a close button.
Since bottom sheets are at the bottom, it only makes sense for the close button to be there too. The place where it’s most comfortable for right-handed users (which is the majority of users) is near the top-left corner — place the close button just above the bottom sheet or within it:
A popular practice is to give the background the ability to dismiss the modal too, because it’s so large and easy to click. Too easy in fact, as users can end up dismissing the modal accidentally, which is particularly annoying after having just completed a form within it and lost the data as a result of the accident. Definitely avoid this practice!
The only thing we want to be doing with modal backgrounds is obscuring them in some way. Unless, of course, they’re to remain functional, like with the aforementioned Google Map example:
You’ll likely want to include some interaction transitions not only because they look awesome, but also because it makes it clearer to users what’s happened as a result of their interaction.
Being a bottom sheet, the most obvious transition is sliding up from below. For bottom sheets that are resizable, there’s also the added benefit of this suggesting which direction to push and pull:
If there are snap points, then you should use the same transition, although as mentioned before, I would avoid using snap points.
In any case, keep the transitions short and simple. A slowly transitioning modal will feel even more frustrating to use, and one that uses complex transitions might feel janky depending on the user’s device.
Modals aren’t naturally included in the navigation history, especially on the web. They aren’t designed for users to navigate back to them and they certainly won’t automatically save any data that’s been inputted. This is by design, to prevent product teams from building overly dynamic digital products at high risk of bugs and crashing.
But is it technically possible? Sure, and perhaps it can be executed well in some scenarios, but I’d recommend saving it for simple bottom sheets and perhaps not even then. All of the examples that I thought were good (Pinterest, Twitter, etc.) have since switched to a more traditional new-page navigation flow, which is telling.
Perhaps the most neglected aspect of modals is the accessibility aspect. There are two things that we must consider.
Firstly, the keyboard focus must shift from the button that triggers the modal to the modal itself. Although this is the developer’s job in practice, we can still communicate how the design should function — Stark is a great tool that enables designers to address all kinds of accessibility concerns, including keyboard tab order.
Dismissal of the modal should return users back to the button that triggers it, and the esc key should be one of the ways that users are able to do that.
That being said, support for native modal components on the web is increasing, which handles the accessibility aspects right out of the box. This is centered around the <dialog> element, which I would suggest reminding developers about, as it makes development easier for them and provides a better experience for users.
The native modal components provided by operating systems (e.g., iOS) are quite mature — they “just work.” But still, it doesn’t hurt to document the intended result for developers in terms of accessibility (and anything else for that matter, including transitions). That being said, when it comes to apps, the best way to design them is to not — just embrace their default behavior and styling.
Between the limited screen space on smaller devices and how finicky modals are, it’s best to keep things simple, especially in regards to interactive elements — how many there are, how big they are, and how close they are together.
The Web Content Accessibility Guidelines clarifies that touch targets should be at least 44x44px (although web.dev recommends 48x48px) plus a minimum of 8px distance between touch targets:
The worst-case scenario is the aforementioned Google Maps example. Although it’s generally well-designed considering the impossible scenario it’s in, it’s still pretty convoluted, and as a result almost every interaction is a frustrating misclick.
Add this to the fact that everything animates and what you end up with is constant fear of messing everything up. It’s a very unpleasant experience, especially on low-powered devices that have trouble rendering the animations and interactivity.
All-in-all, bottom sheets are a great and sometimes better alternative to centered modals, and also drawers (as seen in the Wayfair bottom sheet case study). By being positioned in the lower half of the screen and using more of the horizontal space, bottom sheets get to feel more like a page-in-page experience, with reduced cognitive load. This enables users to complete their task quicker and without having to “give up” their state/position on the main screen.
To ensure that the bottom sheets have the intended effect, just make sure to establish a self-contained heading hierarchy, optimize space and content, enable users to adjust their UI when necessary (while still ensuring great accessibility), and make them less error-prone.
If you enjoyed this read and/or have something else to add, please feel free to do so in the comment section below, and thanks for reading!
Header image source: IconScout
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Subscription pages are meant for users and businesses, and they should work well for both parties. This blog is a thorough discussion of what’s best and what’s not when it comes to designing subscription pages.
Call it what it is. Product designers and UX designers have unique roles, even if their titles often get swapped. In this blog, know the difference and own your expertise.
Search bars are more than icons and inputs — they can be a retention magnet or a churn trigger. Sharing my tried-and-tested search bar design principles in this blog!
Are your colors clashing or cohesive? In this blog, I talk about clashing colors, their impact, and how you strike the perfect balance with colors in your designs.
Learn more →
