A little critique of Google's Material Design and its associated websites
Tags: discuss, webdev, ux, materialdesign
Published: 2018-05-07 06:44:06

---
title: A little critique of Google's Material Design and its associated websites
published: true
tags: [discuss, webdev, ux, material-design]
canonical_url: https://lobotuerto.com/blog/a-little-critique-of-google-material-design-and-its-associated-websites/
cover_image: https://thepracticaldev.s3.amazonaws.com/i/p8ivsxihczueqth3hozr.png
---

***

You can check the latest updated version of this article at [lobotuerto's notes - A little critique of Google's Material Design and its associated websites.](https://lobotuerto.com/blog/a-little-critique-of-google-material-design-and-its-associated-websites/)

***

I have a couple of opinions to state regarding the spec —which by the way I think is a **great** design specification— and its accompanying websites:

- [material.io/guidelines](https://material.io/guidelines/)
- [material.io/icons](https://material.io/icons/)

# Guidelines on toggle functionality

I think regarding toggles, you should pick one way to get your point across to the user.  
And be consistent about it, do not send mixed signals.

Here is a couple of examples that shows —in my view— incongruent behaviour:

## Expansion panels

For [expansion panels](https://material.io/guidelines/components/expansion-panels.html) —or lists, the icon (`arrow_drop_up`/`arrow_drop_down`) doesn’t represent the state of the panel, but the intent of the user —what will happen if I press on it?

![Components Expansion Panels](https://lobotuerto.com/blog/a-little-critique-of-google-material-design-and-its-associated-websites/components-expansion-panels.png)

By the guidelines examples:

- When **closed,** you should show an arrow down, signaling the user that if they press on it it’ll expand.
- When **opened,** you should show an arrow up, signaling the user that pressing on it will close the expanded panel.

Here, the visual cue ( **the arrow** ) represents **intent** , not state.

## Password redaction

On [password redaction](https://material.io/guidelines/components/text-fields.html#text-fields-input-types) it’s the other way around:

![Shown password](https://lobotuerto.com/blog/a-little-critique-of-google-material-design-and-its-associated-websites/password1.png)

![Hidden password](https://lobotuerto.com/blog/a-little-critique-of-google-material-design-and-its-associated-websites/password2.png)

By the guidelines examples:

- When the eye is **open** the password is shown. This is only showing the state of the thing in cuestion.
- When the eye is **closed** the password is “hidden”. Again, this is showing the state of the component, instead of intent.

Here, the visual cue ( **the eye** ) represents **state** , not intent.

## Switch buttons

On the other hand, switches are great toggling controls because what they do is show **state** and **intent** towards whatever label they have associated.

So here, it’s really up to the developer to find great labels for a great UX.

Example:

```
<o--> Crushing it! (this is off, meaning we are not crushing it)
<--o> Crushing it! (this is on, meaning we are crushing it now)
```

(Pardon my ASCII art…)

It helps a great deal that the switch makes use of the spec and clearly signals the user when it’s **on.**

## Intent vs state

Design languages or specifications should be coherent as a whole.  
Some questions that arose from the observations above:

- Should icons show **state** or **intent**?
- Should stuff like this be clearly documented in the spec?

For the second question I think the answer should be **yes**.  
As for the first one, **Material Design** should go one way or the other, not both, nor keep it undefined.

### My resolution

In my view, taking in consideration the spec’s spirit, the way to go would be for icons to signal **intent.**

Another less subjective reason to go this way is that showing **intent** allows
for a series of actions to be chained using one changing icon —whether you should be doing this or not is debatable, the points is that you can— since you are always letting the user know what comes next if they click on it.

You can’t convey this information using icons to show **state,** since the next state can’t be known by looking at the icon alone, you can only know what the present state is.

Nonetheless, using _non-actionable_ icons to present state is OK.

In the end what I mean is:

Keep the **expansion panels** the way they are now, and change how the **password redaction** icons work (just swap the icons out).  
**Switch** buttons are good as they are.

* * *

I know this subject is a tough one. It’s been discussed for ages:

**Jef Raskin** was writing about this issue quite a few years ago in[The Humane Interface: New Directions for Designing Interactive Systems](https://www.amazon.com/Humane-Interface-Directions-Designing-Interactive/dp/0201379376), an **Addison-Wesley Professional** publication from April 8th, 2000.

**Alan Cooper** also discusses this in his book[About Face: The Essentials of Interaction Design](https://www.amazon.com/About-Face-Essentials-Interaction-Design/dp/1118766571)published by **Wiley** on September 2nd, 2014 (looks like the firs edition is from August 25th, 1995):

> Flip-flop button controls are very efficient. They save space by controlling two mutually exclusive options with a single control. The problem with flip-flop controls is that they fail to fulfill the second duty of every control - to inform the user of their current state. If the button says ON when the state is off, it is unclear what the setting is. If it is OFF when the state is off, however, where is the ON button? Don’t use them. Not on buttons and no on menus!

There is a good amount of discussion about this subject [here](https://ux.stackexchange.com/questions/1318/should-a-toggle-button-show-its-current-state-or-the-state-to-which-it-will-chan) and [here](https://ux.stackexchange.com/questions/20713/toggle-buttons-turn-on-vs-enable) on [StackExchange UX](https://ux.stackexchange.com/).

# Websites

Now let’s talk about a couple of websites related to **Material Design,** and some annoyances —_bad_ UX; AKA UX _opportunity areas_— I’ve found while using them.

## Material Design guidelines

Pages on the [Material Design guidelines](https://material.io/guidelines/) should include anchors on section headers for easy linking. It’s so annoying that they don’t!

A good solution would be to have anchors show when hovering section headers, subheaders or titles.

Trying to be too **Material Design** at the cost of good **UX** —or convenience— is not good.

Case in point: I couldn’t link to the **password redaction** section, because there is no anchor for it!

## Material Design icons

I find a little frustrating that icons that are basically the same as others, don’t show their aliases.

For example, these are the same icons but you have to find out for yourself:

- `color_lens`, `palette`
- `create`, `mode_edit`
- `block`, `do_not_disturb_alt`
- And more...

I get that it must be in the interest of semantics, but believe me, users —like me— end up using icons that look like _what we need,_ not _what they are named as._ We use names to search for them.

If I need a fricking circle icon for displaying a user status be sure I’ll end up using a fricking`fiber_manual_record` icon!

I find really irritating that `CTRL + F` doesn’t work because icons are dynamically loaded into the page. So you have to use the website’s own search bar for that.

If [FontAwesome](https://fontawesome.com/) is doing just fine showing all their [2,791 icons](https://fontawesome.com/icons) I think you’ll do just fine showing 900+.

***

# Conclusion

I think my biggest criticism is that sometimes it looks like **Material Design** principles are applied at the expense of good **UX,** when it should be the other way around: **UX** should come in first, maybe at the expense of **Material Design.**

* * *

Ideally, **Material Design** should reach a point where this trade-off should never come to be.



# 2018/05/08 update

**Google** has just updated its **Material Design spec,** and some of the links and commentary I provided above don't apply anymore. Nonetheless, I'll leave them there for history's sake.

Check out the set of improvements and new guidelines they provide on their site: [material.io/design](https://material.io/design/).

Another good thing is that we have a usable **Material Design icons** site now!
Go, check it out: [material.io/icons](https://material.io/tools/icons/)