Google's material design, which I've written about a number of times, has generally been received well by designers, developers, and press alike. We've seen numerous apps adopt it, developers explain and evangelize it, and users react positively to it.
Still, there have been nagging questions about the new design philosophy. A big one, and one that could potentially be a stumbling block for adoption, is the question of branding. Some voice concerns that material design may overshadow existing brands if implemented to Google's spec, or that it's too difficult to brand a "material design app."
Someone recently asked me what I thought about the relationship between branding opportunities and material design, and while I was able to come up with a short version of the answer, there are a few different things packed into this issue that are worth exploring. In this (opinion) post, I hope to take a look at a few of those things in a way that explains a position I'll always advocate: your brand can survive a material redesign.
What is material design, really?
Before answering this question, why are we starting here? I think the question of what the phrase "material design" really means is an important one, as those inside and outside the Android community have packed it with meanings that overlap, intersect, or contradict one another. To some, it means hamburgers and FABs, to others it means a rather non-specific cleanliness and use of white space, and still to others it could mean something entirely different. Can one quantify material design? Is there a scale that goes from zero to material, and if so what are the steps in between?
Ultimately, the answer is simple: material design is a design methodology that focuses on creating and reflecting a predictable set of physical rules for interaction with paper- and ink-like materials on a display. That's it.
Material design, in my mind, has less to do with hamburgers and FABs, and more to do with the actual material metaphor. That's what it's named after, after all.
Where the meaning (and perceived meaning) gets tangled up is with the items I just listed above. Floating Action Buttons, hamburger menus, typography, white space, and the rest are all paradigms of the aesthetic, individual words in the design language. It's up to developers and designers to choose the arrangement and intonation of those words to tell their users a meaningful story. Part of this storytelling is knowing when to lean on the design guidelines.
Google's material design guidelines are quite exhaustive. A living document, the guidelines provide up-to-the-minute guidance for developers and designers wondering how to best portray certain interface elements and basic interactions. But there's danger in taking the guidelines as hard rules.
The best approach is to consider the guidelines as a playbook rather than a rulebook. They're a set of best-practices, recipes, and examples of individual components and interactions you might run into while designing an interface. Fyza Hashim, the designer behind Trello's material revolution, explains a few instances where Trello thought outside the guidelines to retain the app's existing identity:
Not everything outlined in the Material guidelines fit the way Trello works:
- Cards in a list are a no-no
- But, that’s uh, kind of how Trello functions
- The Floating Action Button (FAB) doesn’t always fit certain situations
- Having one in a board would be too confusing, although we really did try
- The colors provided in the Material guidelines, while vibrant and playful, didn’t mesh with our brand
- We stuck with the colors specified in our branding guide. While it might not seem like a big deal, staying on-brand really helped emphasize the Trello-ness. This will also help with consistency in the future when working on other platforms such as iOS.
Hashim says Trello "... used Material’s principles as a guide rather than strict rules that must be followed to the letter," and that's perfect. The guidelines are jumping-off points for design decisions, heuristics for keeping things like navigation menus and tab bars consistent and familiar for your users, not an iron-clad set of absolute rules.
If we can stretch the "design language" metaphor past its breaking point for a minute, the guidelines are like Google's dictionary or thesaurus - great for looking up pronunciation or better ways to say something, but not great for copying verbatim. Making a story with the same 10 words over and over is asking for a poor experience.
So to reach guideline harmony, refer to the guidelines without relying on them for your entire experience. If you want to know whether a FAB fits on a specific activity, go check out the handy section about button usage. But don't jam a FAB into every possible spot just because it exists in the guidelines. Need an icon for an interaction that isn't immediately prescribed in Google's system icon set? Easy, just consult the guidelines to figure out how to make a new icon of your own that matches stylistically with the platform.
Remember: playbook, not rulebook.
So what's the hangup with branding?
Branding can be a divisive topic in UI design. There's friction (in many cases) between the belief that an interface should work to primarily represent the brand and the attitude that it should represent the product with the brand following after. Friction also comes from a place of confusion regarding design guidelines and what they really mean in relation to your product, which we've covered above.
Downloading and opening your company's app is not an accident.
First, let's talk appropriate branding. Using an app's product icon in the toolbar used to be a popular practice in the days of holo. In this writer's opinion, that was kind of a cop-out. Putting a full-color graphic in the toolbar next to monochrome icons, when the full-color focus should be inside the app's main interface area (between the toolbar and the nav bar) was asking for distraction.
My statement on this would be that logos don't really have a place in mobile interfaces, except serving as an element in the product icon. The only example I can think of off hand where a brand logo works inside an interface is Instagram, but that's a special case: Instagram doesn't have a hamburger menu, the toolbar is otherwise only occupied by one action icon, and the logo they use in the interface is the Instagram logoface, not the stylized Instamatic seen elsewhere. So in other words, you can include a logo in your interface if the above criteria are met, but it's still not really necessary.
I would argue that a company logo is primarily meant to support brand awareness, public recognition, and corporate identity. So before putting a logo in an interface, I would want to consider the following rhetorical questions:
- How was the user first exposed to the app?
- How did the user get the app?
- How did the user open the app?
The answers here should be obvious. The common thread here is that downloading and perhaps even moreso opening your company's app is not an accident. To get into an interface, a user must be exposed to your app (either through an app store or elsewhere), choose to download the app, and then open the app on their device. On purpose. So by the time the user is in your app, there's probably very little chance they'll forget where they are.
I would also make the argument that brand typefaces aren't really necessary in a mobile UI. Many brands, as part of their branding guidelines, have typefaces that should accompany certain kinds of materials. Communications, products, and interfaces may all have their own rules about typography. So that's another type of friction: the friction between wanting to use brand assets everywhere across all media, and wanting to be thoughtful of the platform you're entering and the users who already live there. Keeping basic fundamentals like typography consistent is important for user experience.
Things get weird really fast with custom fonts
iOS and Android both have preferred type families for interface design. They're typefaces that are already used throughout the respective system and stock apps, and they feel comfortable to users (however invisible the font may be). The user experience is enhanced by maintaining that familiarity and comfort, so there's not really a clear need to add Avenir Next or VAG Rounded to your Android UI.
So if logos and typefaces are out, what can you use to brand the app? Three pillars of branding a mobile interface come to mind: the product icon, your brand colors, and the product itself.
1. The product icon
The product icon is the user's first touchpoint with your app. They'll see it on their home screen or in the app drawer (on Android), so it's logical that the app name and product icon would convey your brand. That said, it should also fit with the overall style of the platform. So while a square with broad corners and a neon gradient won't look at home on Android, an icon comprised of your logo or other uniquely silhouetted imagery with tinted and shaded edges won't work for iOS. And this is fine. Even when crafting your product icon from paper, it's generally not difficult to maintain your brand identity. Even if it's just putting a single-color logo on top of a base shape and adding the edges and lighting Google recommends, your logo can peacefully exist in a material world.
2. Brand colors
Google provides a material palette (and a material expanded palette) in its guidelines to give some color options to those who need some palette guidance. This doesn't mean, however, that your app shouldn't use brand colors in the interface.
If your goal is to brand the experience, thoughtful use of related colors throughout the interface is a powerful but subtle way to add your brand's presence into the interface without using a logo.
No matter how extensive or restrained your brand's palette, it shouldn't be difficult to pull out at least primary and accent colors. Finding a brand color that works as the interface's primary or accent color is so easy, in fact, that most apps already do it. Facebook and Twitter have their respective blues, Google's Drive apps come in their signature green, blue, and yellow variants, Groupon goes for a pleasing lime green, Yelp relies on its red, white, and black palette, and Soundcloud makes use of its orange hue to highlight important elements.
Using brand colors in an app interface seems almost too obvious, but I think the impact of this choice is also underrated in discussions of branding an interface. We've already established that when a user opens your app, they know where they are, so reinforcing this familiarity by using a consistent brand palette does have an impact.
If you're looking for a way to make your app feel familiar with brand colors but also with material design, take it from Google. The guidelines provide tips on fitting in, like using colors in large fields of the UI, saving your accent color for action buttons, toggles, and other controls, and even how to adjust your color palette without losing the palette's integrity if it doesn't quite work on the first try.
3. The actual experience
This one has softer edges than the previous two points - your actual product or service should be reflected in the interface. Again, without a logo, without custom typefaces, and without stylistic freakiness. So what does this mean? It could be taken to include a few things.
Probably one of the most illustrative examples of the experience reflecting the product is Google's Inbox. It helps that the product is named after an actual feature of the product, but beyond that look at the interface. There's not a single trace of a Google logo, nor really an Inbox logo (unless you're on iOS, where a splash screen greets users briefly before opening the app, a feature that could be debated in an entirely separate post). What we do see is a brand-aware color palette and an interface designed with material and product in mind.
Of course as an email tool it does emaily things like send messages, save attachments, etc. But it's also recognizable for its features like snooze, done, and an overall task-based mentality toward managing email. Inbox has bent material design to its will by introducing innovative paradigms like layering messages on the z-axis. If a user taps a bundle, it becomes a new layer on top of the previous interface in a very visual way. A message, once tapped, becomes yet a third layer, and users can swipe these layers back to where they belong just as easily. So, when building your experience, think of the key takeaway experiences your users or customers already know from your product, what they'll want and need in a mobile app, and translate those into the actual interface, embracing material design as a tool for interface innovation rather than a limiting factor.
Why should I care?
So now that we've taken a high-level look at some reasons why material design can coexist in harmony with your brand on Android, let's ask an obvious question: why should you care?
Why should a developer, designer, or product manager think twice about what Google has cooking for the Android design aesthetic or the larger design community?
You should care because users care. On some level, every segment of the user population wants a good experience in an app. That's undeniable. No one actively wants to use an app that feels wrong, or is unnecessarily difficult to use, or doesn't fit with their understanding of how an app is supposed to work.
How users perceive that experience - whether it's a keen-eyed Android Police reader examining the virtues of the hamburger menu or someone totally new to Android who's just figuring out swipe-to-refresh - will differ. Some users instantly recognize good interface and experience and appreciate it on its own virtues. Some users simply feel like an app is good or bad but can't pinpoint the UI/UX reasons for that opinion.
I'm not the first to say this (and hopefully I'm not the last), but whatever the case and whoever the user, being aware of the platform you're producing for is important. Consulting the design guidelines playbook Google has provided, making informed choices about iconography, color, typography, and functionality all foster a "good" feeling among those who use your app, and that should be the goal.