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.


Popular posts from this blog

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…

User Experience Model: Measuring And Understanding Behavior of Users

A good user experience is one of the key success factors for digital business models: How do the users discover the website or application? Do they abandon or leave? Do they use them regularly or even recommend to others? These are about the question of the user experience (UX), which can be measured with specific user experience model. Now, let me show you how to do it.
The performance of digital media can be traditionally controlled by technical metrics such as page impressions, retention time, or conversion rates. They can indicate the behavior of the users on the site, but they don’t predict its cross-platform behavior as well as its behavior outside the product. Either good or bad UX will influence not only the direct use of the product usage, it also has an impact on the brand perception and the customer's behavior. It is, therefore, worthwhile to use the canon of the key performance indicators (KPI) and to raise them regularly. In order to understand the causes and the eff…

UI Designer Salary Research of 2017 in the United States

In recent years due to the rise of mobile internet, it has led the popularization of UI design. Nowadays big internet companies are increasingly focused on interaction design and user experience, and several internet behemoths have established UI design departments one after another. As people expect more on user experience of internet products, UI has increasingly become the core concern of products. UI design will certainly become more and more popular, and UI designers will certainly have a bright future. This article makes a detailed analysis of the report of UI designer salary research in United states.
1. How much does an user interface designer in the United States make?
The average user interface designer salary in the United States is approximately $89,106. This UI designer salary research obtains its information from 10,591 data points collected directly from employees, users, designers from top design communities, and job advertisements on Indeed in the past 12 months.