When Your Floating Action Button Blocks Core Features — What to Replace It With

Here's a scene you've probably seen: you open an Android app, and right there, a big round button floats over the bottom of the screen. It's the floating action button — the FAB. Google introduced it back in 2014 with Material Design as a shortcut for the primary action. Tap it, and boom — you compose an email, add a new item, start a search.

But what happens when that FAB sits on top of something important? Like the last row of a list, or a navigation tab, or a 'Save' button? Then it's not a shortcut — it's a roadblock. And yet, many apps keep it there because 'Material Design says so.' This article looks at when a FAB actually hurts more than helps, and what you can replace it with — without breaking your user's flow.

Who Has to Decide — and When

Product manager's dilemma

The feature freeze is three weeks out, and your product manager stares at a screen full of crash reports — all pointing at the same component: the floating action button. It blocks the bottom navigation bar on foldable devices, and on smaller screens, it sits directly over the checkout confirmation toggle. She has to decide: kill the FAB for this release or delay the foldable support that the C-suite promised investors. Neither option feels safe. The catch is — she doesn't own the technical debt, but she owns the outcome if engagement drops. Most product managers I have coached wait until a blocker reaches critical mass: 15% of your user base can’t tap a core button. By then, the fix costs double. The real dilemma isn't technical. It's timing — ship fast, break UX; delay, burn roadmap trust. That hurts.

“The FAB was our hero element until the hero started blocking the door.” — lead PM, mid-size e-commerce app

— observed during a quarterly retrospective, 2024

Developer's timeline pressure

Developers inherit the decision after the PM picks a direction — but here is the pitfall: they often discover the FAB-blocking problem during QA, not design review. A junior Android engineer once told me her team spent four sprints wrangling a custom FAB animation, only to find it covered the payment terminal's scan button on Samsung DeX. That seam blows out under pressure. The developer's timeline shrinks to a week — or less — because the release train is already moving. What usually breaks first is the hasty patch: shrink the FAB to 40dp, override the elevation, hope nobody rotates the screen. A band-aid that works on your Pixel 7 fails on a Huawei foldable. The real question is when to escalate — flag the blocking FAB during sprint planning, not during regression testing. I have seen teams waste two weeks on a workaround they could have replaced in three days with a bottom bar action.

UX researcher's red flags

The UX researcher catches the blocking FAB before it ships — if they have a seat at the table. On one project, the research log showed a clear pattern: users tapped the screen edge repeatedly, trying to dismiss the FAB. They weren't confused. They were annoyed. The researcher's red flags are subtle at first — task completion times spike by 40% on checkout flows, heatmaps show a frustrated cluster of taps around the bottom-right quadrant. Not yet a crash, but a usability hemorrhage. Wrong order: teams treat these signals as low priority until the support tickets pile up. Quick reality check — one study found that blocking even 12% of a primary action's tap area can increase task failures by nearly a third. The researcher's role is to name the risk before the PM makes the call. But here's the trade-off: early warnings get ignored if the data is presented as a “concern” rather than a projected revenue impact. Frame it as a drop in conversion, not a usability gripe, and the room listens.

Four Alternatives to the Blocking FAB

Move action to top bar

The most obvious fix hides in plain sight. Shove your primary action into the app bar, next to the overflow menu or as a standalone icon. I have seen teams reclaim 40 percent of screen real estate this way—no animation tricks, no SDK changes. But here is the catch: thumb-reach maps get wrecked. On a 6.7-inch phone your user must stretch to tap that top-right target, and one-handed operation becomes a two-handed chore. That sounds fine until your analytics show a 12 percent drop in the action's usage rate. The trade-off is simple—visibility versus ergonomics. You gain an unblocked content area. You lose the lazy-thumb zone. For actions people use twice a session (send, bookmark, flag), the top bar works. For fire-and-forget taps like 'add item', it can feel like a cruel game of finger Twister.

Bottom sheet replacement

A persistent bottom sheet solves the blocking problem without sacrificing thumb access. The FAB vanishes; its action lives on a draggable panel that sits 60–80 dp above the navigation bar. Users see a thin peek of the sheet's handle, swipe up, and the controls appear—context intact, content unblocked. The tricky bit is ghost taps. If your sheet floats over scrollable content, people accidentally trigger it while swiping through a feed. We fixed this by adding a 150-millisecond touch delay on the sheet's hover zone, but that introduced a stutter on lower-end devices. Not ideal. Bottom sheets shine for compound actions—think 'share with options' or 'filter + sort'—where a single FAB tap would have forced a full-screen dialog anyway. A common failure? Teams shove too many actions into one sheet. Keep it to three items max, or the cognitive load cancels the UX win.

‘We replaced a FAB with a bottom sheet and saw engagement rise 22% in two weeks. Then users complained they could not find the button at all.’

— Design lead at a travel booking app, describing the discoverability drop that followed their initial win.

Contextual toolbar

Let the toolbar change when selection happens. No FAB needed. Your user long-presses a list item, and a bar slides up from the bottom or drops from the top—carrying exactly three to five actions relevant to that selection. Delete, edit, move, share. Done. The danger here is mode blindness. People forget they're in selection mode and tap the main content area, which deselects everything and hides the toolbar. That hurts. A 2023 audit of a note-taking app showed 31 percent of contextual toolbar invocations ended in accidental dismissal within the first two seconds. The fix: a subtle background dim (alpha 0.12) that communicates 'you're in a special state now'. No animation, no sound—just a visual cue that survives accidental taps. Contextual toolbars fail hardest when your action set is inconsistent—sometimes six items, sometimes two. Users stop trusting the pattern. Keep the inventory identical across all selection contexts or don't use this pattern at all.

Odd bit about development: the dull step fails first.

Swipe gesture instead

No button at all. No toolbar. No sheet. Just a horizontal swipe on the item itself. Archive an email by dragging it left. Confirm a purchase by swiping right on the cart row. One motion, zero chrome, the full view stays unobstructed. The organic flaw is discovery—how do new users know a gesture exists? Onboarding screens rarely help; people skip them. Micro-animations at first launch (a ghost swipe that wiggles the first list item) bump recognition by about 15 percent in our tests, but that still leaves 85 percent of first-time users blind to the trick. We saw a fitness app where users rated the experience 'clean' but gave a 2.3-star average because they never found the primary action. Swipe gestures work best as secondary or tertiary paths—archive, snooze, quick-reply—not as replacements for the core action your app launches into. Wrong order: never hide 'create new' behind a swipe. That's a discovery death sentence.

How to Compare Your Options

Discoverability vs. screen space — the real tension

A bottom-sheet action that hides until you swipe? That saves real estate, sure, but you just buried your primary function behind a gesture nobody knows exists. I have watched test users stare at a blank bottom bar for six seconds, then tap a totally unrelated icon. The trade-off is brutal: every pixel you reclaim from a floating action button might cost you a conversion. Quick reality check—if your core action happens less than once per session, hiding it's probably fine. If it's the reason people open the app, you need that button visible, even if it blocks a headline. The catch is that 'visible' and 'non-blocking' often fight each other on small screens. So ask: would I rather lose 8% of users to confusion, or 12% to clutter?

Reachability for one-handed use

Phones keep growing. Thumbs keep stretching. A bottom-navigation FAB works great for right-handed users—until you realize 25% of your audience is left-handed or uses their left hand while eating. The standard bottom-right position becomes a contortion exercise. We fixed this by letting users drag the replacement button to either corner. That single setting dropped support tickets about 'button too far' by almost half. Most teams skip this: they design for the emulator, not for a hand holding a 6.7-inch slab on the subway. The alternative—placing the action in a toolbar at the top—solves reachability but kills one-handed use entirely. That hurts when your audience is commuting, cooking, or holding a toddler.

Frequency of the primary action

This is where you stop guessing and start counting. Pull your analytics: how many times per session does that blocked core feature actually get triggered? If it's three taps or fewer per visit, a persistent mini-FAB (say, 32dp) tucked into a corner is fine—it doesn't need to scream. But if that action fires ten times per session, like 'add note' in a journaling app, you need the replacement front and center. A contextual action bar that appears only when relevant works beautifully here: users learn the pattern in two sessions, and you reclaim all screen space in between. The pitfall is assuming frequency equals importance—some actions are rare but critical (e.g., 'archive chat'), and hiding them behind a long press creates rage-quits. Wrong order. Measure both frequency and impact.

'The right replacement doesn't just sit somewhere else — it changes shape, size, or position based on what the user is actually doing.'

— UX lead on a 2M-download note-taking app, after their third FAB redesign

User testing metrics to watch

Don't rely on 'feels better.' Run a 5-person hallway test with three specific signals. First: time-to-first-tap on the new element—anything above 2.5 seconds for a primary action is a red flag. Second: accidental triggers—if users hit the replacement by mistake more than once, your padding is too tight or its position clashes with system navigation. Third: exploratory hesitation—do people pause and scan before tapping? That pause means discoverability is failing. A/B test the replacement against the old FAB for one week, measuring completion rate of the blocked task. I have seen a perfectly good bottom sheet fail because it sat exactly where the keyboard close button lives. That seam blows out. Iterate fast—three rounds of testing usually converge on a winner. If they don't, the problem is not placement; it's that the action itself is ambiguous.

Trade-Offs at a Glance

Top bar: visible but far

The top bar never hides behind content — that’s its one clean win. I have watched teams ship it as a quick fix when the FAB started fighting a map or a chat input. It works. But the thumb-stretch cost is real. On a 6.5‑inch screen a one‑handed user can't reach that icon without shifting their grip — and shift means risk of a drop. The trade‑off is pure geometry: a top‑bar action is always visible but almost always out of reach. You gain discoverability; you lose ergonomics. That hurts on a commute train.

Bottom sheet: versatile but heavy

You get a persistent action plus room for three or four secondary buttons — text labels, icons, maybe a slider. Sounds ideal. The catch is weight: a bottom sheet demands careful padding, elevation handling, and a dismiss gesture. Most teams skip this: they throw in a sheet that overlaps scroll‑to‑top, or they forget to handle the keyboard. I fixed exactly that for a CRM app last year — the sheet blocked the “Save” button when the keyboard opened. The fix cost two days of re‑layout. So the trade‑off is simple — you buy modularity with complexity. Not a bad deal if you commit to QA.

Toolbar: contextual but hidden

Place actions inside a scrolling toolbar that appears only when content enters a certain state. Very Android‑native — think Gmail’s conversation toolbar. The problem: “only when…” means the user has to learn the trigger. That’s a discovery tax. Quick reality check — I have seen onboarding analytics where 40 % of users never tapped a toolbar because they didn't know it existed. The tooltip helped, but the tooltip itself felt like clutter. The trade‑off? Clean when you know it’s there. Brittle when you don’t.

Swipe: fast but undiscoverable

Swipe gestures are the fastest primary action Android has — no tap target, no button, just a flick. But discoverability is almost zero. Most users never learn swipe unless you teach them with a one‑time overlay or animation. And teaching costs attention. I have seen apps where the swipe‑to‑delete rate jumped from 12 % to 58 % after a coached onboarding — but retention dropped 7 % because the onboarding itself annoyed users. You can't win both. The trade‑off is speed versus learning friction; choose wisely based on your power‑user ratio.

‘The worst trade‑off is not picking one — it's mixing top bar, sheet, toolbar, and swipe in the same screen.’

— voiced by an Android lead after a release‑day crash caused by four overlapping gesture zones.

Field note: android plans crack at handoff.

Making the Switch — Implementation Steps

Removing the FAB from layout

Open your activity’s XML and delete the `com.google.android.material.floatingactionbutton.FloatingActionButton` node. That sounds too simple—and it's. The real work starts when you hunt down every reference to that FAB in your Kotlin or Java files. I have seen teams miss a `fab.show()` call buried inside a `BottomSheetBehavior` callback; the result was a ghost button that still occupied touch space on Lollipop devices. Remove the visibility toggle logic, the `setOnClickListener`, and any `CoordinatorLayout.Behavior` anchor rules you wrote to keep the FAB floating above your list. If you used the FAB for a primary action like “New Item,” you now have a gap—not just in the layout, but in your user’s mental model. Fill that hole deliberately.

The tricky bit is the app:layout_anchor attribute. When you rip out the FAB, the `CoordinatorLayout` may shift its remaining children unexpectedly. Run a layout inspector before you merge. Most teams skip this: they delete the XML, rebuild, and wonder why their `RecyclerView` jumps 72dp upward. You need to update any padding or margins that depended on the FAB’s presence. Quick reality check—your `BottomNavigationView` or `Toolbar` might have been compensating for that button. Reset those values to hard-coded dp or, better, to a dimension resource you can swap later without recompiling.

Adding new UI elements

So what goes in its place? Not another single button. You already know from the alternatives in this post that a bottom sheet, a contextual toolbar, or a swipe action might replace the FAB’s role. Implementation-wise, start with a stub—a static placeholder at the FAB’s old location—and wire the new element’s state to your existing ViewModel. Don't duplicate logic. If your FAB triggered a `createItem()` method, reuse that callback; don't write a new one for the bottom sheet’s “Add” button. I fixed exactly this on a travel app last year: the old FAB and the new bottom sheet each opened a different fragment because the junior dev forgot to bind the same event. That hurts. Keep a single source of truth for the action’s outcome.

A BottomSheetBehavior needs a `NestedScrollView` or `RecyclerView` as its backing view. Add it below your main content, set `app:behavior_hideable="false"` during onboarding, and toggle the state via `BottomSheetBehavior.State.EXPANDED`. For a contextual toolbar, you're essentially swapping out `Menu` items at runtime. Use `onPrepareOptionsMenu()` so the toolbar shows “Archive” only when a selection exists. Wrong order: you add the toolbar first and then try to force the FAB away. Do it the other way—kill the FAB, add the replacement, and only then adjust your layout weights.

“Every replacement we tested had at least one edge case where the FAB’s absence confused the user for three seconds. That three seconds is a win, because the FAB used to confuse them forever.”

— Josh, lead Android engineer on a productivity suite refactor

Handling animations and transitions

Your FAB probably had a `ScaleUp` or a `Shrink` animation tied to the `CoordinatorLayout`’s scroll events. Killing the button means those animations disappear too—but the scroll behavior still fires. You must unbind the `CoordinatorLayout.Behavior` from your new UI element, or weirdness ensues: the bottom sheet might twitch upward every time the user scrolls the main list. Override `onNestedScroll()` in your new layout’s behavior class and return early if the replacement element is visible. The catch is that most Material Components listeners are `@Nullable` by design, so a null check on the old behavior reference will crash if you forget to clear it in `onDestroyView()`.

For the entrance of your replacement, use a shared-element transition if the old FAB had a `FloatingActionButton.Behavior` that users associated with speed. Animating a bottom sheet’s peek height from 0 to 60dp feels slower than a FAB expanding, so add a slight `alpha` fade on the sheet’s container. Test it on a Moto G4 (Android 7.0) because the `AnimationHandler` timing differs from Pixel devices. I skipped that once, and the sheet snapped open on low-end hardware. Not yet? Then your transition will feel janky, and users will tap where the FAB used to be—an empty spot.

Testing with real users

You have code. You have a preview with four breakpoints. Now hand the build to five people who never read your product docs. Watch where they tap first—not where they should tap. A common pitfall: the new action lives in a toolbar that collapses on scroll, so the button vanishes exactly when the user wants it most. We fixed this by pinning the toolbar during scroll in the first testing cycle. Another pitfall: accessibility. TalkBack reads the old FAB’s content description even after you remove it if you left a stale `android:contentDescription` in a style XML. Run `AccessibilityScanner` on every build candidate.

The real question—should you A/B test the change? Yes, but only after you fix the three blocking bugs from your test round. Throw the replacement into a staged rollout (5 % of users for one week). Measure task-completion time for the core action, not just crash-free rate. If the median time jumps by more than 1.5 seconds, your replacement is not discoverable enough. I have seen teams re-add a small FAB-like chip after the bottom sheet failed that test. That's fine—your implementation path is not a one-way door. You can yank the sheet and try a swipe gesture on the same ViewModel without rewriting the business logic. The worst mistake is keeping broken code in production because you spent three sprints on the transition. Kill it, test it, or kill it again.

What If You Pick the Wrong Replacement?

Lower engagement on primary action

The most immediate signal that you picked the wrong replacement is a drop in the one metric you were trying to protect. I have seen teams swap a FAB for a bottom sheet trigger, only to discover that users simply stopped performing the primary action altogether. That sounds fine until you check the analytics—tap volume on that action plummets by forty percent. The catch is that bottom sheets introduce friction: one extra tap, a brief hesitation, and suddenly the habit loop breaks. What usually breaks first is the casual user, the one who would have instinctively thumbed the FAB without thinking. Now they hesitate, scroll past, and the action never happens. If your replacement buries the primary call-to-action behind an extra interaction, you haven't solved the blocking problem—you just moved it.

Reality check: name the development owner or stop.

Increased user confusion

Sometimes the replacement works too well at hiding itself. Contextual menus that appear only under certain conditions, for example, often confuse users who expect a persistent, always-visible button. I watched a team replace a FAB with an in-line action bar that appeared only when the user scrolled to a specific section of the screen. Result: support tickets asking "Where did the share button go?" spiked by thirty percent in two weeks. The mistake was assuming that users understood the logic behind the visibility rules. They don't. Most people develop muscle memory around UI placement, not conditional UI rules. That means the replacement needs to be predictable—if it shows only when content is selected, make sure the selection state is obvious. One concrete fix: add a persistent ghost indicator (a faint icon in the same spot) so the brain registers the location even when the control is hidden.

“I swapped a FAB for a contextual toolbar and lost a whole cohort of repeat users in three days.”

— UX lead, after a failed migration on a media-editing app

Accessibility pitfalls

Replacing a floating action button often breaks accessibility in ways that don't show up in automated tests. The FAB is a single, large, high-contrast target—easy to focus, easy to activate with screen readers. Swap it for a swipe gesture and suddenly TalkBack users have no idea the action exists. Swipe-based replacements are the worst offender here: no visible affordance, no focusable element, no fallback. I have fixed apps where the only way to perform the primary action was a three-finger swipe—completely invisible to assistive technology. Quick reality check—if your replacement relies on motion, orientation, or multi-touch, you need a secondary button trigger. That isn't optional; it's the law in many jurisdictions. The trade-off is that a visible fallback button defeats the minimalism you were aiming for. That said, a slightly cluttered UI that everyone can use beats a clean UI that excludes people.

Performance regressions

The sneakiest failure mode is a performance regression that feels unrelated. Some replacements—especially animated bottom sheets or gesture-driven overlays—introduce layout recalculations on every frame. I saw one case where a simple FAB-to-speed-dial migration caused a thirty-millisecond jank every time the user scrolled past a certain viewport position. Millisecond-level jank. That's not noticeable on a flagship device, but on a mid-range Android phone it translates to dropped frames, stutter, and eventually poor Play Store ratings. The fix was aggressive: pre-calculate the expanded positions, cache the layout, and avoid re-measuring child views on scroll. If you pick a replacement that triggers constant redraws, you trade a visual problem for a performance problem. Not a good swap. Before you ship, profile the replacement on a low-end device with the CPU throttled. You will catch regressions that your Pixel 8 Pro never reveals.

Frequently Asked Questions

Can I keep the FAB but move it?

You can — but moving a blocking FAB often just shifts the problem elsewhere. I have seen teams slide the button to a top corner, only to watch users miss it entirely or accidentally trigger it while reaching across the screen. The real trap: relocation doesn't fix the *decision* hierarchy. If the FAB's action is secondary (say, "share this profile" when the primary task is "edit contact details"), moving it buys you time, not clarity. Material Design 3's guidance on FAB placement assumes the action is *the* primary one — not something that competes with core navigation. Test a moved FAB for three days with real users. If taps on the core feature stay flat or rise, fine. If they don't, your problem isn't position — it's purpose.

Is a FAB always bad for core features?

Not always — but the exception is narrower than most teams assume. A FAB works for core features when that feature is a single, frequent, non-destructive action that *never* overlaps with critical content. Example: a note-taking app where the FAB starts a new note — and the note list scrolls beneath it without occlusion. That sounds fine until a list item has a long title, a swipe-to-delete gesture, or a nested submenu. The catch is that Material Design 3's large FAB variants (96dp height) block 40% more screen real estate than the old standard. So the question becomes: can your core feature survive a 96dp blind spot? Most can't. One concrete anecdote: we fixed a travel app where the FAB blocked the "book now" button for 12% of users on 5.5-inch screens. We swapped the FAB for a persistent bottom bar — bookings rose 8% in two weeks. That's the trade-off: a FAB is fast for the team to implement, slow for the user when it hides revenue.

Don't let a button you like become a blind spot your users have to guess around.

— core UX principle, after auditing 23 Android apps with FAB occlusion issues

What does Material Design 3 recommend?

Short version: use a FAB only for the highest-priority action on a screen, and keep it away from scrollable content that people need to reach. M3 introduces the extended FAB (text label + icon) for actions that need clarity, and the surface variant for cards that shouldn't float at all. The recommendation that matters most for blocking: if your FAB overlaps with text, buttons, or gesture zones by more than 8dp, reconsider the component entirely. That's a tight tolerance. What usually breaks first is the bottom navigation bar — M3 says FABs should overlay the nav bar, not sit beside it, but this creates a 128dp+ occlusion zone on 60% of phones. The official docs lean toward "don't do this" for content-heavy screens. Read the actual guidance — it's not a free pass.

How do I know users hate the FAB?

Three signals that don't require a survey. First, session replays show pausing — users hover, zoom, or scroll around the FAB area before acting. That's wasted cognitive load. Second, support tickets mention "I can't find X" or "the button covers the price" more than twice in a month. Third — and this is the one most teams skip — heatmaps show repeated taps on the FAB itself by users trying to dismiss it. Wrong order. People don't file bug reports for occlusion; they just leave. Quick reality check: pull your analytics for screens where the FAB sits over a core feature. If the bounce rate on that screen is 15%+ higher than the app average, you have your answer. Not yet convinced? Run a five-session A/B test where the FAB disappears entirely. If task completion improves without it, kill it. If not, keep it and move on. That simple.

in the end, the decision comes down to this: does the FAB earn its screen real estate every session? If it blocks, hides, or confuses — even for 5% of your users — it's costing you more than it gives. Go replace it before the next release cycle burns. Your users won't send a thank-you note, but they'll stop pausing.