The Bottom Sheet Problem: Why Your App's Slide-Up Panel Traps Users Instead of Helping Them

You finally ship the feature your users asked for. It opens in a slick panel that slides up from the bottom of the screen, a bottom sheet, and in your simulator it looks great. Then the bug reports arrive: "I can't close the filter panel," "the sheet covers the button I need," "I swiped down and lost everything I typed." Dolfy.ai exists to catch exactly this kind of problem before a single line of production code ships, because the bottom sheet is one of the most misused components in mobile design.

A bottom sheet is a panel that slides up from the bottom edge of the screen to show extra options or content without leaving the current screen. Done well, it feels fast and natural, especially on large phones where the thumb can reach the bottom edge but not the top. Done badly, it traps people. Most teams build the open animation in an afternoon and never design the rest: how it closes, how tall it gets, what happens to the keyboard, and what happens when a user does something unexpected.

Key Takeaways

• A bottom sheet needs at least three dismiss paths: swipe down, tap outside, and a visible close button. Relying on only one locks out some users.
• Define sheet heights as named stops (for example peek, half, and full) in your design tokens instead of hard-coding pixel values screen by screen.
• Sheets that hold forms must handle the keyboard, unsaved input, and accidental dismissal deliberately.
• Designing the sheet's states on paper first, before coding, prevents most of the rework teams do after launch.
• Dolfy's Design OS gives you a structured place to define the component once and reuse it everywhere.

What exactly is a bottom sheet, and when should you use one?

A bottom sheet is a temporary surface anchored to the bottom of the screen that carries a focused task, such as picking a filter, choosing a share target, or confirming an action. You should use one when the task is short, related to what is already on screen, and safe to abandon. Think of picking a sort order or selecting a delivery time slot.

You should not use one for long, multi-step flows, anything that needs the full width of a real screen, or content the user must read before continuing. A rule of thumb many teams follow: if the task takes more than about 30 seconds or needs more than five or six inputs, it deserves its own screen. Apple's SwiftUI and Google's Material guidelines both describe sheets and modals, and both distinguish between a sheet that can be dismissed freely and one that is deliberately blocking. Your job is to decide which one you are building, on purpose.

Why do users get trapped by bottom sheets?

Users get trapped because the only way out is a gesture they do not know, or a gesture that does not work in their context. A swipe-down-to-dismiss gesture is invisible. Nothing on screen tells you it exists, and it fails entirely for people using screen readers, switch controls, or a mouse in a web preview.

There are three classic traps. First, the sheet has no visible close button, so users who do not discover the swipe feel stuck. Second, tapping the dimmed area outside does nothing, which breaks a habit people picked up from every other app. Third, the sheet scrolls internally, so a downward swipe meant to scroll the list is read as a dismiss gesture and the whole panel disappears. In usability testing sessions of five to eight people, you will typically see at least one person hit each of these within the first few minutes.

How tall should a bottom sheet be?

A bottom sheet should be exactly as tall as its content needs, up to a sensible maximum, and it should snap to a small number of predefined heights rather than stopping anywhere. Three snap points, usually called a peek, a half height, and a full height, cover almost every use case and keep the interface predictable.

The peek shows just enough to hint that more exists, typically around 15 to 25 percent of the screen. The half height, around 50 percent, leaves the underlying screen visible so users keep their context. The full height, close to 90 percent with a sliver of the screen behind it, signals "this is now the main task." Never let a sheet cover 100 percent without a clear close control, because at that point it is a screen pretending to be a sheet. Reserve space at the top for the status bar and the safe area, the region of the screen not covered by notches, rounded corners, or the home indicator.

What should a bottom sheet do with the keyboard?

When a sheet contains a text field, it should lift above the keyboard automatically and expand to a height where the focused field and its primary button are both visible. This sounds obvious, yet it is one of the most common defects in shipped React Native apps, because the keyboard overlays the screen instead of resizing it unless you handle it.

In React Native you typically combine a keyboard-avoiding container with a sheet library, and you test on both iOS and Android because the two platforms resize differently. Check three things: the primary button stays reachable while the keyboard is open, the sheet does not jump when the keyboard animates in, and dismissing the keyboard does not accidentally dismiss the sheet. If you have ever typed a long message and lost it because the panel closed, you know why this matters.

What happens to unsaved input when someone dismisses the sheet?

If the sheet holds anything the user typed, dismissal should never silently destroy it. The safest pattern is to preserve the draft for the length of the session and, for anything longer than a couple of fields, ask for confirmation before discarding. A single "Discard changes?" prompt is a small interruption that prevents a large loss.

Treat accidental dismissal as a design requirement, not an edge case. A thumb brushing the dimmed area or an overly sensitive downward swipe happens constantly on a moving train or in a one-handed grip. For forms, many teams disable swipe-to-dismiss while the form is dirty, meaning changed but unsaved, and keep the close button active so the exit is still deliberate.

How do you make bottom sheets accessible?

You make a bottom sheet accessible by giving it a clear label, moving focus into it when it opens, trapping focus while it is open, returning focus to the trigger when it closes, and supplying a non-gesture way to dismiss it. Screen readers such as VoiceOver on iOS and TalkBack on Android need to announce that a new layer has appeared, and they should not be able to wander into the content hidden behind it.

Contrast and size matter too. The drag handle, the little bar at the top of a sheet, is decoration for sighted users and should not be the only dismiss control. A close button needs a touch target of at least 44 by 44 points on iOS or 48 by 48 density-independent pixels on Android. These are the same minimums you would apply to any button, and sheets are where teams most often forget them.

How do you design one bottom sheet that works across every screen?

You design the sheet as a single reusable component with named variants and tokens, then reference it everywhere, instead of rebuilding a slightly different panel for every feature. Most apps end up with five or six sheets that each have a different corner radius, handle style, and animation speed, because each was built by a different person in a different week.

A design token is a named design decision, such as a color, spacing value, or corner radius, stored once and reused. Sheet tokens might include the top corner radius, the backdrop opacity, the handle color, the snap heights, and the animation duration. Change the token and every sheet in the app updates together. This is the same idea as a design system, the shared set of components and rules that keeps an interface consistent, applied to one tricky component.

How does Dolfy help you design bottom sheets before you code them?

Dolfy is an AI-powered design platform for mobile apps that walks you through a five-step Design OS methodology: Product Definition, Data Model, Design Foundation, Screen Design, and Export. Bottom sheets touch almost every step, which is why they are a good test of whether your design process is sound.

In Product Definition you decide whether a task belongs in a sheet or on its own screen. In Data Model you list what the sheet reads and writes, which tells you whether it holds a form. In Design Foundation you set the design tokens that style every sheet the same way. In Screen Design you lay out the sheet's states, and in Export you get React Native and Tailwind CSS components with TypeScript types, which is the code form of a component with typed props. You can preview the result through Expo Go or the web preview before committing to anything.

The practical benefit is that the decisions people usually postpone, such as dismiss behavior and snap heights, get written down at the start. A workflow that takes you from an idea to reviewable screens in an afternoon, rather than a design-then-handoff cycle that stretches over two or three weeks, leaves far more time to test the awkward cases.

A short checklist before you ship any bottom sheet

Run through these questions with your team, ideally while holding a real phone rather than looking at a laptop:

1. Can I close it three different ways, including one that needs no gesture?
2. Does it snap to named heights that come from tokens?
3. Does the keyboard push the primary button into view without breaking the layout?
4. Is unsaved input protected from accidental dismissal?
5. Can a screen reader user open it, use it, and leave it without getting lost?
6. Does it still work with the system font size turned up to 200 percent?

If you can answer yes to all six, you are ahead of most apps in the store. If you answer no to even two, you have found your next sprint.

Frequently Asked Questions

Should I build my own bottom sheet or use a library?

For most teams, a well-maintained library is the faster and safer choice, because gesture handling and keyboard behavior are hard to get right on both iOS and Android. Build your own only if you need behavior no library offers. Either way, wrap it in your own component so your tokens and rules live in one place.

Is a bottom sheet better than a full-screen modal?

Neither is better in general. A sheet keeps the user's context and suits short, optional tasks, while a full-screen modal suits focused, longer, or required tasks. Choose based on how long the task takes and whether the user can safely walk away from it.

How do bottom sheets work on web previews and tablets?

On wide screens, a panel anchored to the bottom can look stretched and hard to reach. Many designs switch to a centered dialog or a side panel above a certain width. Previewing your screens in a web preview early shows you where the layout breaks before real users find out.

How many bottom sheets are too many?

If a single flow stacks one sheet on top of another, the structure is probably wrong. Stacked sheets confuse the back gesture and the user's sense of place. Aim for one sheet at a time and move longer sequences onto proper screens.

Design the exit before you design the entrance

Every bottom sheet is a promise: "you can leave whenever you want." Users judge the whole app on whether that promise holds. The animation that slides the panel up earns a moment of delight, but the dismiss behavior earns long-term trust. Define your heights, your tokens, your keyboard behavior, and your exits first, and the code becomes straightforward.

If you want a structured way to make those decisions before they turn into bug reports, take a look at Dolfy and walk your next component through the Design OS from definition to export.