Skip to main content

Material Design: Why the Floating Action Button is bad UX design

Material Design is a design language introduced by Google a year ago, and represents the company’s bold attempt at creating a unified user experience across all devices and platforms. It’s marked with bold colours, a liberal but principled use of shadows to indicate UI layers, and smooth animations that provide a pretty pretty user experience on Android (and some Google apps on iOS).

One thing about Material Design, however, has bugged me ever since it was introduced last year: Floating Action Buttons.


FABs are circular buttons that float above the UI and are “used for a promoted action,” according to Google. They act as call to action buttons, meant to represent the single action users perform the most on that particular screen.

And because of the bold visual style of Material Design, FABs are strikingly hard to ignore and stand out — and herein lies the problem.

While FABs seem to provide good UX in ideal conditions, in actual practice, widespread adoption of FABs might be detrimental to the overall UX of the app. Here are some reasons why.

They take immersive out of the experience.


FABs stand out visually — they’re literally on top of every other UI element on screen. As such, adding an FAB would automatically result in a UX that is less immersive, particularly affecting apps (or screens) that aim to provide an immersive experience.

The Photos app opens in a gallery view, with a floating search button. But the thing is, when I open a photos app, I just want to... view my photos.


The search FAB thus distracts the user from an immersive photo-browsing experience, which is the primary purpose of the app in the first place. Granted, smart photo searching is a unique function of Google’s Photos app. But does it mean it should be given a top-level, persistent FAB in the app? (I think not.)

Ironically, Google agrees with me. On its Material Design page about FABs, Google explains that “not every screen needs a floating action button.” It then goes on to add that “the primary action is to touch images in a gallery, so no button is needed.” Oops.

They stand out — and stand in the way.


This might feel like another side of the same coin, but there’s another, perhaps more important, implication of the FAB getting in the way. By taking up real estate on the screen, the FAB effectively blocks content.

But hey, the FAB is just a small circular button, right? How much content could it block?

If you look at the screenshot of the Photos app, you’ll realise that the search FAB blocks around 50% of an image thumbnail — definitely large enough to cover a face or two. That’s an additional scroll needed whenever you want to look at every 4th thumbnail of the last row on screen. And that’s not even the worst case.


User dumazy posted on Graphic Design Stack Exchange about a problem he encountered when the FAB blocked the “favourite” star as well as the time stamp on his app screen. This illustrates a problem all apps with list views face, and it becomes especially problematic when the last item on the list couldn’t be scrolled up any further.

This means that an entire column the width of the FAB has to be sacrificed (by repositioning the star button, etc.) to allow for proper usability of the screen.

Hence, while it might not seem like it, the FAB takes up way more screen real estate than its size suggests.

Promoted actions might not be used that often.


When doing UX design, it’s useful to remember the 80/20 rule, which states that users will use 20% of the features 80% of the time. In other words, most effort should be placed on designing the few elements that users will use most of the time.

The FAB actually does just that — theoretically. But what if the “promoted action” just isn’t used that often by users?

Take Google’s Gmail app for instance.

The Gmail app’s FAB is the compose button, suggesting that the primary action users perform is to create an email.


But is that true?

Multiple studies have shown that at least 50% of emails are now read on a mobile device, but little to none show the same shift in terms of composing emails. In other words, as our daily experiences would likely corroborate, most mobile users tend to use their email apps toread emails on the go.


Perhaps a handful would reply on their mobile devices, but that only happens after opening up an email (note that this means they’ll bypass the FAB). This user behaviour, likely caused by the rather imperfect input mechanism of virtual keyboards and autocorrect, means that the primary action users perform is actually reading (and replying) emails, not creating new ones.

So what does the “compose an email” FAB do? On rare occasions, it provides users with delight when they immediately want to compose an email on the go with the app. But on other times, it just takes up screen space, blocks the star button and time stamp, and is a persistent distraction painted in striking red.

Do we need FABs? Scratch that — Do we even want FABs?


Of course, not all applications of the FAB reduce the experience of using Material apps. There are some shining examples of FABs that make sense, and that therefore enhance the UX of those apps.

Maps by Google is a great example of FAB done right. The main action performed by users on Maps is to get directions, so it makes perfect sense for an FAB that does just that.

But consider that Maps is a pretty special case, where the content users are interested in almost always falls at the centre of the screen (where your blue position dot is). In most apps, however, grid or list views mean that users interact with content located everywhere on screen, including where FABs are most commonly located.

Consider also that the screenshots above only tell part of the story: in actual use, these FABs stay where they are even when users scroll (most of the time). As Google emphasised multiple times in Material Design, motion design is as important as UI design. The lack of motion — the persistence in screen space — in the context of moving content creates a higher level of distraction that screenshots can barely show.

So when examples of good FAB implementation are far and few between, it begs the question: do we need FABs?

When we look at the drawbacks of having FABs on apps, we can boil it down to a simple realisation: users don’t only perform actions on apps, they consume content as well (if not more of the time).

The design of the FAB in Material Design is based on the premise that users perform a certain action most of the time, and therefore it should be accorded an elevated status in the form of a persistent, high-level button. But in many apps, users are focused on consuming content just as much (if not more): in the Photos app, users want to view photos; in Gmail app, users want to read their emails; and in the Facebook app, users want to read their friends’ posts.

The FAB is thus a design philosophy (or at least, a design choice) that subordinates optimal content consumption to action-taking. And we need to ask ourselves: is such a trade-off needed? In fact, is such a trade-off wanted?

When FABs result in diminished UX most of the time, when it’s hard to figure out the single most-used action within an app, and when roundabout methods need to be explored (like an FAB that disappears when scrolled, or lists with differently positioned elements), I’d say the answer is a pretty resounding no.

Google’s Material Design is a pretty damn good piece of unified, principled design language, but the FAB, well, just isn’t that fab.

Comments

Popular posts from this blog

Top 15 UX/UI Designers You Should Follow to Flow Out Inspiration in 2018

As is known, design is a rather broad and hard-to-define term. There are a wealth of different responsibilities encompassed by the term designer and design-related roles which have been existing in a wide range of areas, varying from print (publications and magazine) to industrial design (furniture and cars). With new design roles emerging in the industry, job titles like UX/UI designers seem to be confusing for both experienced and uninitiated designers. Before diving deeper, let’s have a quick look on the difference between UX and UI terms. User Experience (UX) designis a concept that has many dimensions and primarily concerned with how the product will feel. To solve a specific user problem, a UX designer will explore many different approaches, as any given design problem doesn’t have one single right answer. By identifying verbal/non-verbal stumbling blocks, UX designers refine and iterate to make the “best” user experience. Here is how Laura Klein (the author of UX for Lean Start…

Professional UX Design Approaches for Building The Best Website

Building a website through UX design approaches is very much like painting or sculptural art, they all take patience, foresight, aesthetics ability, creativity and perception of details. Generally, the website you design represents your company, it needs to be stunning and breathtaking. If you look deeper into the aspects of website building, you can find some core UX features that outstanding websites share. By analyzing the top design trends, we may accurately trace out four major professional UX design methods for website building. 1. Streamlined Navigation By saying “Streamlined Navigation”, I do not only refer to the navigation bar but all others navigations on a larger scale. Not to mention the great ones, a standard website also needs to be of high usability. Besides that, the speed and accuracy of loading are of decisive significance as well. In professional UX principles, the typography should be carefully organized to ensure the best user experience. Links should be highly …

What? You Are Still Doing High-Fidelity Prototype Slowly?

Have you ever spent half a month designing a high-fidelity prototype, but it was denied within a few minutes? So much time and energy have been spent but in vain. I have met similar things so many times. However, such tragedy can be totally averted: the rapid low-fidelity prototype is a wise choice in prototype design.
1. What is a high-fidelity prototype and a low-fidelity prototype? Low-fidelity prototype: it only focuses on functions, structures and processes; it only provides the most simple frameworks and elements; it generally does not provide color, butexpresses itself in grayscale.

High-fidelity prototype: it provides more visual details; it is almost equivalent to a UI effect picture, and only needs to replace the actual data and materials in the development process.

2. Why make a low-fidelity prototype?
In product development, the goal of a prototype is to express its ideas, functions and content, in order to get feedback and improve the product. The most important challeng…