top of page

December 2020

Using Google Material for Building The Enterprise Digital Design System (EDDS)

This article will cover how we, as a team, view Material Design, explore where Material shines, where Material fails (bad patterns, accessibility), how we utilized out-of the-box-components and what lessons we’ve learned from our work.

What’s Material?

Material Design is a set of rules, guidelines, components and best practices for creating websites and apps.

“Material is a design system – backed by open-source code – that helps teams build high-quality digital experiences.”

Synopsis on Material Design homepage

Material Design was created by Google in 2014. It was was built on a mobile-first approach, which makes sense considering its original purpose was for designing Android apps. The nod to paper-based design styles differentiated it from the flat design style that was widely used at the time.

Like most design systems, Material Design was created to bring a unified user experience across various devices, platforms, and input methods. Similar to the way that Apple implemented flat design principles as their standard, Google used Material Design to ensure that, regardless of how users were accessing their products, they would have a consistent user experience.

The Material Design specification includes guidelines for everything: typography, grids, space, scale, color, and imagery. But Material Design goes a step further than just guiding designers on how to make things look. It enables designers to create intentional designs with hierarchy, meaning, and focus in their end result.

In May 2018, Google released a revised version to remedy a major problem – the original guidelines were restrictive, emphasizing function over style. Because apps created in line with these looked alike, many app makers disliked Material Design. Google had to balance Material Design’s consistency with the capacity for differentiation – to grant designers the flexibility to adapt it to brand needs. Version 2 features not only new guidelines but also a tool suite (including new icon packs and a Material Theme editor) you can use to customize your designs. Therefore, you can fine-tune aesthetics to suit your organization’s brand presence.

Why use Material?

Material Design is effectively an entire design ecosystem, rather than just a set of style guidelines. If there’s a potential design situation that exists, Material Design likely has a comprehensive set of rules for how to handle it.

Google maintains Material Design and keeps extensive documentation for how to use and implement it. This kind of support and documentation can be lacking for many other modern design systems.

Despite all this comprehensiveness and documentation, Material Design remains a fairly flexible design library. Within the guidelines, much of the specifics of how to implement the design are left entirely up to the designer.

More granular advantages for Material Design include:

  • Subtle skeuomorphism: Sets it apart from flat design and makes it more intuitive for many users

  • User feedback: Haptic feedback and subtle animations to help users understand how features function

  • Simplified sense of physics: Makes interactions more life-like and intuitive.

Material_as_a_system.png

The Enterprise Digital Design System (EDDS) is on a critical mission of building our own foundation to provide the similar robust design and engineering support to our massive design community. We often rely on Google Material for inspiration and its resources to get a jump start.

Not Perfect

While Material Design has very obvious pros, that doesn’t mean there aren’t cons that go along with using it.

Most importantly there are some usability issues in Material Design that can make websites and apps very user-unfriendly. One of the biggest issues is with the so-called “mystery meat” navigation encountered on many mobile design apps. Icons are often used in place of text, and while sometimes the icons are immediately recognizable and fairly usable, at other times they’re not.

A circle to indicate “Home” is significantly harder to identify than the house icon that was previously used in most Android interfaces. This is a prime example of placing form over function.

Android_navigation_bar.png

And it’s not just in the lower navigation bar. Material Design’s preference for including circular floating action buttons is also a usability issue. 

These circular Floating Action buttons only include space for an icon, with no assistive text included. And because icons can be so open to interpretation, in many cases, users are left questioning what these buttons actually do.

FAB.jpeg

When our Android team started to build our first components for the EDDS I was surprised when our Android developer informed me and my fellow Android designer that implementing one of the standard Material components would actually require a bunch of custom control development. Not fun for him, nor for us designers, who had to provide a bunch of extra specs to support that custom development.

Our team also discovered that the default theme doesn’t consistently pass accessibility requirements in terms of color contrast, e.g. text against background. It was surprising to learn about those issues, even though we are customizing the colors to match our brand.

Lastly we discovered that Material components are not easily “style-able”. For example, Error is technically not a style-able state, and the states for Disabled/Enabled + Focused/Unfocused often do not work out-of-the-box, and therefore there is extra development work to “tie” them to styles.

Android_states.png

We have seen Google’s tendency to favor aesthetics over function cause usability and accessibility issues in both global and component patterns. Let’s dig in.

Departing from Material: Real Life Use Cases

Text Field

When building Text Field Android component for our first release our team came across some major issues with out-of the-box implementation. Both the designers and A11y experts on our team concluded that a Text Field ‘as it is’ couldn’t be used if we wanted to meet accessibility requirements.

A Brief History on Google Minimalistic Input Fields

In the last few years, minimalism has become wildly popular among designers. This trend has been so influential that some teams have even attempted to apply it to basic data-entry fields, by replacing the traditional input box with a single line. 

Login_material_text_fields.png

This input-field style was even adopted by Google: prior to 2017, it was included in Google’s Material Design.

Google obviously has a lot of talented designers and engineers doing fantastic work, but even a talented team doesn’t guarantee that everything they try will be perfect. In this case, the switch from boxes to underlines wasn’t actually an improvement in the user experience, and, in 2017, Google changed the Material Design input-field component back to a rectangles instead of an underline. Susanna Zaraysky and Michael Gilbert shared their research results* about this design evolution publicly, explaining that after testing both usability and user preferences with hundreds of users, they concluded that “Enclosed text fields with a rectangular (box) shape performed better than those with a line affordance.”

Material didn’t ditch a single line look entirely. Instead they “fixed” the issue by adorning a line with a borderless gray color (can be a custom color) filled container. And offering an alternative: a more traditionally looking outlined box. There is still a problem with these two options – both implementations have float labels.

Our Team Text Field Implementation

What we believe sets our Design System apart from Material is that we build our platform using an accessibility-first approach. Every design solution on a basic, “atomic” level is driven by accessibility compliance. We want to make our Android app usable to as many people in our customer base as possible.

We chose an outlined input box and it was an easy decision to make.

Float labels

The float label pattern by Matt Smith is a technique that uses the label as a placeholder. The label starts inside the control, but floats above the control as the user types, hence the name. This technique is often lauded for its quirky, minimalist, and space-saving qualities.

FloatingLabel.gif

Unfortunately, there are several problems with this approach.

  • They’re hard to read, due to their poor contrast and small text. (A softer shade of color is necessary so that users have a chance to differentiate between a real value and a placeholder.)

  • The label ends up performing the job of different semantic elements, such as placeholder, label or input value depending how the user interprets it. Like placeholders, they may be mistaken for a value and could get cropped.

  • Float labels don’t actually save space. The label needs space to move into in the first place. Even if they did save space, that’s hardly a good reason to diminish the usability of forms.

“Seems like a lot of effort when you could simply put labels above inputs & get all the benefits/none of the issues.”

Luke Wroblewski, Google Product Designer, on float labels

Quirky and minimalist interfaces don’t make users feel awesome — obvious, inclusive, and robust interfaces do. Artificially reducing the height of forms like this is not only problematic, it’s counterintuitive to good user experience design.

Instead, our design and a11y team prioritized making room for an ever-present, readily available label (and hint if necessary) at the start of the design process.

Text_Fields_M_vs_EDDS.png

On a more technical side

Text Field is built from two parts where TextInputLayout is a parent and TextInputEditText is a child. Our engineering team has unified the code and it’s offered as a single Anatomy component for ease of implementation.

Multi-line Text Field out-of-the-box has accessibility issues in a keyboard navigation mode. In single-line mode, Enter performs the "done" action and takes you to the next form element. However in multi-line mode, Enter instead performs the action of "new line". Without having a "done" button, a user basically gets stuck in the input field and has no means to get out. Our engineering team built it as a single line mode that scrolls vertically to overcome the problem. It’s on our roadmap to custom build a “Done” button in UI of the component if we want to utilize a true multi-line mode and be accessible to people who use keyboard navigation.

Radio Button and Checkbox

To make our design accessible to people who use keyboard navigation we had to tweak code for all components we’ve built so far.

Material Design provides a ripple effect for interactive elements that is a highly recognizable Google style. The ripple effect appears when hovering, tapping, and focusing certain components.

Our team needed to utilize the press and focus states for form components that also met accessibility requirements. Since the ripple effect is a shape overlay with reduced opacity, we had to account for a minimum contrast ratio against the page background as well as the component. We were able to incorporate haptic feedback for users tapping a form element, like a checkbox, but needed higher contrast for a keyboard navigation experience.

The initial problem we ran into was achieving an adequate contrast ratio for all interactive states. Even in an extreme example where the page background was white and the form control was black, we couldn't achieve a ripple effect that would have good contrast when the selection control (e.g. checkbox) was enabled as well as disabled. In all cases at least one state would fail to meet requirements. Once we determined that the disabled state would need to be an exception, we landed on an ideal color and opacity level for our focus state.

The second problem we encountered happened during implementation. Our Android developer discovered that the opacity level could be adjusted but only to a certain amount and the calculation for creating the press and focus state opacities was “locked” in code. We were unable to achieve a high enough opacity to meet accessibility requirements. We had an option to either replace the ripple overlay with custom code, which meant creating custom animations, or customize a separate focus style. Due to scope, we chose the second option.

Our solution was to eliminate an overlay and created a custom outline of the checkbox / radio that wouldn’t overlay. This meant we could use a full opacity color that just needed to pass a11y requirements against the page background. We were able to apply this new focus style to other form elements so a keyboard navigation user would have an uninterrupted experience.

Battle with color contrast

Checkbox_a11y_issues.png

Our solution to meet a11y contrast ratio is an outline for a focused state

FocusOutlined.png

Exposed Dropdown Menu

The Exposed Dropdown Menu out-of-the-box component was surprisingly fragmented similar to what we encountered with a Text Field architecture. Originally Material had a Spinner control that worked great out-of-the-box, but this was replaced by Expanded Dropdown Menu. This newly introduced component is comprised of a parent TextInputLayout and a child MaterialAutoCompleteTextView. It ended up being to our advantage that we’ve already built and consolidated the Text Field component first. Now we just had to extend it to get the functionality of Exposed DropDown Menu.

We had to change the default ripple color for the menu option text in Exposed Dropdown Menu to a lighter shade to achieve a good contrast ratio and meet accessibility compliance.

Exposed_Dropdow_M_vs_EDDS.png

Conclusion

Don’t risk your UX by assuming it’s safe to follow a design pattern just because it’s used by a successful company. Aside from the fact that giant companies operate in a completely different brand context, the truth is that just because a company is successful does not mean you can assume everything about its design is well-executed. Plus, one company’s or product’s needs may not match another.

Make sure to bring up this context to explain to colleagues how industry, market, and customers’ prior experiences make each brand’s UX unique. Conduct your own research, do your own testing to ensure that a design solution works with your audience before you invest in building it.

Designers should, at the very least, familiarize themselves with the guidelines so that they can drive collaborative team consensus with different disciplines like development to determine when it’s appropriate to use Material Design, and when to build their own solutions.

Sources

*Zaraysky, S. (2019, November 1). The Evolution of Material Design’s Text Fields. Medium. https://medium.com/google-design/the-evolution-of-material-designs-text-fields-603688b3fe03

**Silver, A. (2018. October 10). Form Design Patterns Book Excerpt: A Registration Form. Smashing Magazine. https://www.smashingmagazine.com/2018/10/form-design-patterns-excerpt-a-registration-form/

bottom of page