On Material Design

Published on January 11, 2018 (↻ November 27, 2023), filed under Design (RSS feed for all categories).

More tough love for Google after this week’s AMP letter (previously). Coincidence: I had written this post some time last year and it was long due and long scheduled to be released.

When Google introduced Material Design back in 2014, I was happy; I was happy for the people on the team, of who I knew a couple, and I was happy for Google to mark another milestone on the long way of improving the aesthetics of their products and even the Web (and, in my view, to become more innovative and qualitatively better at interface design than Apple).

However, when Google introduced Material Design, I was also concerned: “Material Design” sounded more like marketing than substance; in a phase in Web Design in which we had begun to suffer from embarrassingly, ridiculously low information density and the accompanying dumbing down of interfaces, Material Design was like announcing a large shipment of coffin nails rather than defibrillators, even one.

And yet, the marketing ring is not central to my criticism of Material Design; the key is that Material Design seems to miss that much of web and application design is about information. Information—not whitespace. Information—not negative space. Information—not rationalized space.

Material Design sends the signal that most important in design were order and space.

Material Design sends the signal that high information density was a problem, as information density is basically incompatible with Material Design.

Material Design sends the signal that function had to follow form.

(Just look at it.)

Material Design still sends these signals, to me they are all the wrong signals, and I much dislike this approach to design.

As so often, it’s easier—so easy in fact that it lacks much argumentative force—just to say that something’s not okay, that something doesn’t work.

So what would have made, or what could still make Material Design a success?

Material Design would then have become a design success if it had put function first. [This is rather unclear but I decided to keep this and the following paragraph.] Design by itself is nothing (it’s decoration). Function is what is everything, and function cannot but have a design (and at times—see industrial design—this design lends itself to something strikingly beautiful).

In our case, Web Design, this would start with a much clearer message around function, for Material Design to define a vision for what made for useful and meaningful content and services, and a design philosophy around that. Alas, no matter that defining use and meaning isn’t the goal of a design system, even the attempt would be a problem, because we cannot just prescribe and foretell use and meaning.

But while we know—can know—little about a most effective design of services, we know—do know—much about the effective design of content. Content design, put in simple terms, benefits from

1. legible fonts and readable typography (including correct punctuation),
2. high information density,
3. few distractions (avoiding anything from 1 + 1 = 3 to chart junk).

Material Design delivers a little on 1) and 3), and fails noticeably on 2).

We want to remember Tufte (“clutter and confusion are failures of design, not attributes of information”) and do feel reminded of a problem around frameworks and libraries: They cannot be effective and they do not work if the needs are unknown.

Material Design is a collection of ideas and resources that poke into this unknown. That it does so in the realm of services (apps), we may forgive. But that it does in the realm of content design, where we look back at centuries of craft (typography, layout) and clearly benefit from showing the money (the content), that, at this point in time, makes Material Design shallow, undesirable—and also somewhat harmful.

That is my view, based on how I’ve come to understand and observe Material Design.

I do like the Google Design newsletter.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)